RFC4867 日本語訳
4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) AudioCodecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. April 2007. (Format: TXT=139584 bytes) (Obsoletes RFC3267) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Sjoberg
Request for Comments: 4867 M. Westerlund
Obsoletes: 3267 Ericsson
Category: Standards Track A. Lakaniemi
Nokia
Q. Xie
Motorola
April 2007
コメントを求めるワーキンググループJ.シェーベリの要求をネットワークでつないでください: 4867M.Westerlundは以下を時代遅れにします。 3267年のエリクソンカテゴリ: 標準化過程A.LakaniemiノキアQ.シェモトローラ2007年4月
RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB)
Audio Codecs
適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)オーディオコーデックのための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) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi- Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267.
このドキュメントはAdaptive Multi-レート(AMR)に使用されるためにレアル-時間Transportプロトコル(RTP)ペイロード形式を指定します、そして、Adaptive MultiレートWideband(AMR-WB)はスピーチ信号をコード化しました。 ペイロード形式は、AMRとAMR-WB輸送が非IPネットワークでフォーマットする存在で共同利用できるように設計されています。 さらに、ファイル形式はメールなどの格納モードアプリケーションにおけるAMRとAMR-WBスピーチデータの輸送に指定されます。 2つの別々のメディアが含まれていた登録証明書、AMRのためのもの、およびAMR-WBのための1つをタイプします、RTPペイロード形式と格納形式の両方の使用を指定して。 このドキュメントはRFC3267を時代遅れにします。
Sjoberg, et al. Standards Track [Page 1] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[1ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions and Acronyms ........................................4
3. Background on AMR/AMR-WB and Design Principles ..................5
3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6
3.3. Multi-Rate Encoding and Mode Adaptation ....................6
3.4. Voice Activity Detection and Discontinuous Transmission ....7
3.5. Support for Multi-Channel Session ..........................7
3.6. Unequal Bit-Error Detection and Protection .................8
3.6.1. Applying UEP and UED in an IP Network ...............8
3.7. Robustness against Packet Loss ............................10
3.7.1. Use of Forward Error Correction (FEC) ..............10
3.7.2. Use of Frame Interleaving ..........................12
3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12
3.9. AMR or AMR-WB Speech over IP Scenarios ....................13
4. AMR and AMR-WB RTP Payload Formats .............................15
4.1. RTP Header Usage ..........................................15
4.2. Payload Structure .........................................17
4.3. Bandwidth-Efficient Mode ..................................17
4.3.1. The Payload Header .................................17
4.3.2. The Payload Table of Contents ......................18
4.3.3. Speech Data ........................................20
4.3.4. Algorithm for Forming the Payload ..................21
4.3.5. Payload Examples ...................................21
4.3.5.1. Single-Channel Payload Carrying a
Single Frame ..............................21
4.3.5.2. Single-Channel Payload Carrying
Multiple Frames ...........................22
4.3.5.3. Multi-Channel Payload Carrying
Multiple Frames ...........................23
4.4. Octet-Aligned Mode ........................................25
4.4.1. The Payload Header .................................25
4.4.2. The Payload Table of Contents and Frame CRCs .......26
4.4.2.1. Use of Frame CRC for UED over IP ..........28
4.4.3. Speech Data ........................................30
4.4.4. Methods for Forming the Payload ....................31
4.4.5. Payload Examples ...................................32
4.4.5.1. Basic Single-Channel Payload
Carrying Multiple Frames ..................32
4.4.5.2. Two-Channel Payload with CRC,
Interleaving, and Robust Sorting ..........32
4.5. Implementation Considerations .............................33
4.5.1. Decoding Validation ................................34
5. AMR and AMR-WB Storage Format ..................................35
5.1. Single-Channel Header .....................................35
5.2. Multi-Channel Header ......................................36
1. 序論…4 2. コンベンションと頭文字語…4 3. AMR/AMR-WBの上のバックグラウンドと設計原則…5 3.1. 適応型のマルチレート(AMR)スピーチコーデック…5 3.2. 適応型のマルチレート広帯域(AMR-WB)スピーチコーデック…6 3.3. マルチレートコード化とモード適合…6 3.4. アクティビティ検出と不連続なトランスミッションを声に出してください…7 3.5. マルチチャンネルセッションのために、支持します。7 3.6. 不平等なビット誤り検出と保護…8 3.6.1. IPネットワークでUEPとUEDを適用します…8 3.7. パケット損失に対する丈夫さ…10 3.7.1. 前進型誤信号訂正(FEC)の使用…10 3.7.2. フレームインターリービングの使用…12 3.8. 帯域幅効率的であるか八重奏で並べられたモード…12 3.9. IPシナリオの上のAMRかAMR-WBスピーチ…13 4. AMRとAMR-WB RTP有効搭載量形式…15 4.1. RTPヘッダー用法…15 4.2. 有効搭載量構造…17 4.3. 帯域幅効率的なモード…17 4.3.1. 有効搭載量ヘッダー…17 4.3.2. 有効搭載量目次…18 4.3.3. スピーチデータ…20 4.3.4. 有効搭載量を形成するためのアルゴリズム…21 4.3.5. 有効搭載量の例…21 4.3.5.1. シングルフレームを運ぶ単独のチャンネル有効搭載量…21 4.3.5.2. 複数のフレームを運ぶ単独のチャンネル有効搭載量…22 4.3.5.3. 複数のフレームを運ぶマルチチャンネル有効搭載量…23 4.4. 八重奏で並べられたモード…25 4.4.1. 有効搭載量ヘッダー…25 4.4.2. 有効搭載量目次とフレームCRCs…26 4.4.2.1. フレームCRCのIPの上のUEDの使用…28 4.4.3. スピーチデータ…30 4.4.4. 有効搭載量を形成するための方法…31 4.4.5. 有効搭載量の例…32 4.4.5.1. 複数のフレームを運ぶ基本的な単独のチャンネル有効搭載量…32 4.4.5.2. CRC、インターリービング、および体力を要しているソーティングがある2チャンネルの有効搭載量…32 4.5. 実現問題…33 4.5.1. 合法化を解読します…34 5. AMRとAMR-WB格納形式…35 5.1. 単独のチャンネルヘッダー…35 5.2. マルチチャンネルヘッダー…36
Sjoberg, et al. Standards Track [Page 2] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[2ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
5.3. Speech Frames .............................................37
6. Congestion Control .............................................38
7. Security Considerations ........................................38
7.1. Confidentiality ...........................................39
7.2. Authentication and Integrity ..............................39
8. Payload Format Parameters ......................................39
8.1. AMR Media Type Registration ...............................40
8.2. AMR-WB Media Type Registration ............................44
8.3. Mapping Media Type Parameters into SDP ....................47
8.3.1. Offer-Answer Model Considerations ..................48
8.3.2. Usage of Declarative SDP ...........................50
8.3.3. Examples ...........................................51
9. IANA Considerations ............................................53
10. Changes from RFC 3267 .........................................53
11. Acknowledgements ..............................................55
12. References ....................................................55
12.1. Normative References .....................................55
12.2. Informative References ...................................56
5.3. スピーチフレーム…37 6. 混雑コントロール…38 7. セキュリティ問題…38 7.1. 秘密性…39 7.2. 認証と保全…39 8. 有効搭載量形式パラメタ…39 8.1. AMRメディアは登録をタイプします…40 8.2. AMR-WBメディアは登録をタイプします…44 8.3. マッピングメディアはSDPにパラメタをタイプします…47 8.3.1. 申し出答えモデル問題…48 8.3.2. 叙述的なSDPの使用法…50 8.3.3. 例…51 9. IANA問題…53 10. RFC3267からの変化…53 11. 承認…55 12. 参照…55 12.1. 標準の参照…55 12.2. 有益な参照…56
Sjoberg, et al. Standards Track [Page 3] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[3ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
1. Introduction
1. 序論
This document obsoletes RFC 3267 and extends that specification with offer/answer rules. See Section 10 for the changes made to this format in relation to RFC 3267.
このドキュメントは、申し出/答え規則でRFC3267を時代遅れにして、その仕様を広げています。 RFC3267と関連してこの形式にされた変更のためにセクション10を見てください。
This document specifies the payload format for packetization of AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8]. The payload format supports transmission of multiple channels, multiple frames per payload, the use of fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks, as described in Section 3.
このドキュメントはコード化されたスピーチがレアル-時間Transportプロトコル(RTP)[8]に示すAMRとAMR-WBのpacketizationにペイロード形式を指定します。 ペイロード形式はAMRとAMR-WB輸送が非IPネットワークでフォーマットする存在によるビットの複数のチャンネル、複数の1ペイロードあたりのフレーム、速いコーデックモード適合の使用、パケット損失に対する丈夫さ、誤り、およびinteroperationのトランスミッションを支持します、セクション3で説明されるように。
The payload format itself is specified in Section 4. A related file format is specified in Section 5 for transport of AMR and AMR-WB speech data in storage mode applications such as email. In Section 8, two separate media type registrations are provided, one for AMR and one for AMR-WB.
ペイロード形式自体はセクション4で指定されます。 関連するファイル形式はセクション5でメールなどの格納モードアプリケーションにおけるAMRとAMR-WBスピーチデータの輸送に指定されます。 セクション8、twoでは、登録証明書が提供されるメディアタイプ、AMRのためのもの、およびAMR-WBのための1つを切り離してください。
Even though this RTP payload format definition supports the transport of both AMR and AMR-WB speech, it is important to remember that AMR and AMR-WB are two different codecs and they are always handled as different payload types in RTP.
このRTPペイロード形式定義はAMRとAMR-WBスピーチの両方の輸送を支持しますが、AMRとAMR-WBが2つの異なったコーデックであり、異なったペイロードがRTPをタイプするときそれらがいつも扱われたのを覚えているのは重要です。
2. Conventions and Acronyms
2. コンベンションと頭文字語
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 [5].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
The following acronyms are used in this document:
以下の頭文字語は本書では使用されます:
3GPP - the Third Generation Partnership Project
AMR - Adaptive Multi-Rate (Codec)
AMR-WB - Adaptive Multi-Rate Wideband (Codec)
CMR - Codec Mode Request
CN - Comfort Noise
DTX - Discontinuous Transmission
ETSI - European Telecommunications Standards Institute
FEC - Forward Error Correction
SCR - Source Controlled Rate Operation
SID - Silence Indicator (the frames containing only CN
parameters)
VAD - Voice Activity Detection
UED - Unequal Error Detection
UEP - Unequal Error Protection
3GPP--Third Generation Partnership Project AMR--Adaptive Multi-レート(コーデック)AMR-WB--Adaptive Multi-レートWideband(コーデック)CMR--コーデックMode Request CN--安らぎNoise DTX--不連続なTransmission ETSI--ヨーロッパのTelecommunications Standards Institute FEC--前進のError Correction SCR--ソースControlled Rate Operation SID--沈黙Indicator(CNパラメタだけを含むフレーム)VAD--声のActivity Detection UED--不平等なError Detection UEP--不平等なError Protection
Sjoberg, et al. Standards Track [Page 4] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[4ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
The term "frame-block" is used in this document to describe the time-synchronized set of speech frames in a multi-channel AMR or AMR-WB session. In particular, in an N-channel session, a frame- block will contain N speech frames, one from each of the channels, and all N speech frames represents exactly the same time period.
「フレームブロック」という用語はマルチチャンネルAMRで時間で連動しているセットのスピーチフレームについて説明するこのドキュメントかAMR-WBセッションのときに使用されます。 N-チャンネルセッションのときに特に、フレームブロックはNスピーチフレームを含むでしょう、チャンネル各人からの1、Nスピーチが縁どるすべてがまさに同じ期間を表します。
The byte order used in this document is network byte order, i.e., the most significant byte first. The bit order is also the most significant bit first. This is presented in all figures as having the most significant bit leftmost on a line and with the lowest number. Some bit fields may wrap over multiple lines in which cases the bits on the first line are more significant than the bits on the next line.
最初に、本書では使用されるバイトオーダーはネットワークバイトオーダー、すなわち、最も重要なバイトです。 また、最初に、噛み付いているオーダーは最も重要なビットです。 これは線と最も下位の数と共に一番左に最も重要なビットを持っているとしてすべての数字に示されます。 分野が倍数の上で包装するかもしれない何らかのビットが最初の線のビットがどの場合であるかに次の線のビットより重要な状態で立ち並んでいます。
3. Background on AMR/AMR-WB and Design Principles
3. AMR/AMR-WBの上のバックグラウンドと設計原理
AMR and AMR-WB were originally designed for circuit-switched mobile radio systems. Due to their flexibility and robustness, they are also suitable for other real-time speech communication services over packet-switched networks such as the Internet.
AMRとAMR-WBは元々、サーキットで切り換えられた移動無線システムのために設計されました。自己の柔軟性と丈夫さのために、また、それらもインターネットなどのパケット交換網の上の他のリアルタイムのスピーチ・コミュニケーションサービスに適しています。
Because of the flexibility of these codecs, the behavior in a particular application is controlled by several parameters that select options or specify the acceptable values for a variable. These options and variables are described in general terms at appropriate points in the text of this specification as parameters to be established through out-of-band means. In Section 8, all of the parameters are specified in the form of media subtype registrations for the AMR and AMR-WB encodings. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 8.3 provides a mapping of the parameters into the Session Description Protocol (SDP) [11] for those applications that use SDP.
これらのコーデックの柔軟性のために、特定用途における振舞いは変数にオプションを選択するか、または許容値を指定するいくつかのパラメタによって制御されます。 これらのオプションと変数は、バンドの外を通した確立した手段になるようにこの仕様のテキストであいまいな言葉で適切なポイントでパラメタと説明されます。 セクション8では、パラメタのすべてがメディア「副-タイプ」登録証明書の形でAMRとAMR-WB encodingsに指定されます。 セッションセットアップでこれらのパラメタを示唆するか、または関係者の事前同意をアレンジするのに使用される方法はこのドキュメントの範囲を超えています。 しかしながら、セクション8.3はSDPを使用するそれらのアプリケーションのためのSession記述プロトコル(SDP)[11]にパラメタに関するマッピングを提供します。
3.1. The Adaptive Multi-Rate (AMR) Speech Codec
3.1. 適応型のマルチレート(AMR)スピーチコーデック
The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It is now chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems [1].
AMRコーデックは、GSMセルラ方式のためにヨーロッパのTelecommunications Standards Institute(ETSI)によって元々、開発されて、標準化されました。それは現在、第三世代(3G)セルラ方式[1]のための義務的なコーデックとしてThird Generation Partnership Project(3GPP)によって選ばれています。
The AMR codec is a multi-mode codec that supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency used in AMR is 8000 Hz and the speech encoding is performed on 20 ms speech frames. Therefore, each encoded AMR speech frame represents 160 samples of the original speech.
AMRコーデックはビット伝送速度4.75〜12.2キロビット毎秒で8つの狭周波数帯音声符号化モードを支持するマルチモードコーデックです。 AMRで使用されるサンプリング周波数は8000Hzです、そして、音声符号化は20個のmsスピーチフレームに実行されます。 したがって、それぞれのコード化されたAMRスピーチフレームはオリジナルのスピーチの160個のサンプルを表します。
Sjoberg, et al. Standards Track [Page 5] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[5ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Among the eight AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA [17], and the 12.2 kbps mode as GSM-EFR [16].
モードをコード化する8AMRにおける3は別々にそれら自身の規格として既に採用されます。 特に、6.7キロビット毎秒モードはPDC-EFR[18]として採用されます、7.4キロビット毎秒モード、-641である、コーデック、TDMA[17]、およびGSM-EFR[16]としての12.2キロビット毎秒モードで。
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec
3.2. 適応型のマルチレート広帯域(AMR-WB)スピーチコーデック
The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G cellular systems.
Adaptive Multi-レートWideband(AMR-WB)スピーチコーデック[3]は、元々、GSMと3Gセルラ方式で使用されるために3GPPによって開発されました。
Similar to AMR, the AMR-WB codec is also a multi-mode speech codec. AMR-WB supports nine wide band speech coding modes with respective bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in AMR-WB is 16000 Hz and the speech processing is performed on 20 ms frames. This means that each AMR-WB encoded frame represents 320 speech samples.
AMRと同様です、また、AMR-WBコーデックはマルチモードスピーチコーデックです。それぞれのビット伝送速度が6.6〜23.85キロビット毎秒から変化している状態で、AMR-WBは9つの広いバンド音声符号化モードを支持します。 AMR-WBで使用されるサンプリング周波数は16000Hzです、そして、スピーチ処理は20個のmsフレームに実行されます。 これは、各AMR-WBがフレームをコード化したことを意味します。320個のスピーチのサンプルを表します。
3.3. Multi-Rate Encoding and Mode Adaptation
3.3. マルチレートコード化とモード適合
The multi-rate encoding (i.e., multi-mode) capability of AMR and AMR-WB is designed for preserving high speech quality under a wide range of transmission conditions.
AMRとAMR-WBの(すなわち、マルチモード)の能力をコード化するマルチレートは、さまざまなトランスミッション条件のもとで高いスピーチ品質を保存するように設計されています。
With AMR or AMR-WB, mobile radio systems are able to use available bandwidth as effectively as possible. For example, in GSM it is possible to dynamically adjust the speech encoding rate during a session so as to continuously adapt to the varying transmission conditions by dividing the fixed overall bandwidth between speech data and error protective coding. This enables the best possible trade-off between speech compression rate and error tolerance. To perform mode adaptation, the decoder (speech receiver) needs to signal the encoder (speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request or CMR.
AMRかAMR-WBと共に、移動無線システムは利用可能な帯域幅をできるだけ有効に使用できます。 例えば、GSMでは、セッションの間、ダイナミックに音声符号化レートを調整するのは、スピーチデータと誤りの保護的なコード化の間の固定総合的な帯域幅を分割することによって絶え間なく異なったトランスミッション状態に順応するために可能です。 これはスピーチ圧縮率と誤り寛容の間の可能な限り良いトレードオフを可能にします。 働くのに、モード適合、デコーダ(スピーチ受信機)は、エンコーダに合図する必要があります。それが好む(スピーチ送付者)新型。 このモード変更信号はCodec Mode RequestかCMRと呼ばれます。
Since in most sessions speech is sent in both directions between the two ends, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames in the reverse direction. In other words, there is no out-of-band signaling needed for sending CMRs.
大部分で2つの終わりの間の両方の方向にセッションスピーチを送るので、片端のデコーダからもう一方の端のエンコーダまでのモード要求はスピーチフレームの上に反対の方向に背負われます。 言い換えれば、バンドのすぎ外に、送付CMRsに必要であるシグナリングがあります。
Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec and must be able to handle mode switching to any of the modes at any time. However, some transport systems may impose limitations in the number of modes supported and how often the mode can change due to bandwidth
あらゆるAMRかAMR-WBコーデック実現が、コーデックで定義されたすべてのそれぞれの音声符号化モードを支持するのが必要であり、いつでもモードのいずれにも切り替わるモードを扱うことができなければなりません。 しかしながら、いくつかの輸送システムが支持されたモードの数における制限を課すかもしれません、そして、モードがどれくらいの頻度で変えることができるかは帯域幅のため変化します。
Sjoberg, et al. Standards Track [Page 6] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[6ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode or a subset of the defined modes for the session using out-of-band means.
制限か他の規制。 この理由で、デコーダは、バンドの外で手段を使用することで特定のモードの承認かセッションのための定義されたモードの部分集合を示すことができます。
For example, the GSM radio link can only use a subset of at most four different modes in a given session. This subset can be any combination of the eight AMR modes for an AMR session or any combination of the nine AMR-WB modes for an AMR-WB session.
例えば、GSMラジオリンクは与えられたセッションのときに高々4つの異なったモードの部分集合を使用できるだけです。 この部分集合は、AMRセッションのための8つのAMRモードのどんな組み合わせかAMR-WBセッションのための9つのAMR-WBモードのどんな組み合わせであるかもしれません。
Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes and to limit the mode change among neighboring modes only.
そのうえ、ゲートウェイを通してGSMがあるより良い相互運用性において、デコーダはバンドの外で2回のモード変更の間のフレームの最小の数を設定して、隣接しているモードだけの中でモード変更を制限する手段を使用できます。
Section 8 specifies a set of media type parameters that may be used to signal these mode adaptation controls at session setup.
セクション8はセッションセットアップでこれらのモード適合コントロールを示唆するのに使用されるかもしれない1セットのメディア型引数を指定します。
3.4. Voice Activity Detection and Discontinuous Transmission
3.4. 声のアクティビティ検出と不連続なトランスミッション
Both codecs support voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR or AMR-WB frames containing CN parameters are called Silence Indicator (SID) frames. See more details about VAD and DTX functionality in [9] and [10].
両方のコーデックは沈黙の期間、安らぎ雑音(CN)パラメタの声のアクティビティ検出(VAD)と世代を支持します。 したがって、コーデックには、沈黙の期間、伝えられたビットとパケットの数を最小限まで減少させるオプションがあります。 通常、一定の間隔を置いて沈黙の期間、パラメタをCNに送る操作は不連続なトランスミッション(DTX)かソース統制相場(SCR)操作と呼ばれます。 CNパラメタを含むAMRかAMR-WBフレームがSilence Indicator(SID)フレームと呼ばれます。 [9]と[10]でVADに関するその他の詳細とDTXの機能性を見てください。
3.5. Support for Multi-Channel Session
3.5. マルチチャンネルセッションのサポート
Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session).
RTPペイロード形式と格納形式の両方が本書ではサポートマルチチャンネルオーディオ内容(例えば、ステレオのスピーチセッション)を定義しました。
Although AMR and AMR-WB codecs themselves do not support encoding of multi-channel audio content into a single bit stream, they can be used to separately encode and decode each of the individual channels.
AMRとAMR-WBコーデック自体は、マルチチャンネルオーディオ内容がただ一つのビットストリームにコード化されるのを支持しませんが、別々に独特のチャンネル各人をコード化して、解読するのにそれらを使用できます。
To transport (or store) the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block.
別々にコード化された(または、店)マルチチャンネル内容を輸送するために、同じ20回のmsの期間、罪に陥れられて、コード化されるオール・チャンネルのためのスピーチフレームはフレームブロックに論理的に集められます。
At the session setup, out-of-band signaling must be used to indicate the number of channels in the session, and the order of the speech frames from different channels in each frame-block. When using SDP for signaling, the number of channels is specified in the rtpmap attribute and the order of channels carried in each frame-block is
セッションセットアップのときに、バンドの外では、それぞれのフレームブロックの異なったチャンネルからセッションにおける、チャンネルの数、およびスピーチフレームの注文を示すのにシグナリングを使用しなければなりません。 シグナリングにSDPを使用して、チャンネルの数がrtpmap属性で指定されて、それぞれのフレームブロックで運ばれたチャンネルの注文が指定されるとき
Sjoberg, et al. Standards Track [Page 7] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[7ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
implied by the number of channels as specified in Section 4.1 in [12].
指定されるとしてのセクション4.1のチャンネルの数で、[12]で含意されます。
3.6. Unequal Bit-Error Detection and Protection
3.6. 不平等なビット誤り検出と保護
The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. This property has been exploited in cellular systems to achieve better voice quality by using unequal error protection and detection (UEP and UED) mechanisms.
それぞれのAMRかAMR-WBフレームでコード化されたスピーチビットは異なった知覚の感度を噛み付いている誤りに持っています。 この特性は、不平等な誤り保護と検出(UEPとUED)メカニズムを使用することによって、より良い音声の品質を達成するのにセルラ方式で利用されました。
The UEP/UED mechanisms focus the protection and detection of corrupted bits to the perceptually most sensitive bits in an AMR or AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where bits in class A are the most sensitive and bits in class C the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if there are bit errors found in the most sensitive bits, i.e., the class A bits. On the other hand, it is acceptable to have some bit errors in the other bits, i.e., class B and C bits.
UEP/UEDメカニズムはほとんどの敏感なビットAMRかAMR-WBフレームで崩壊したビットの保護と検出の知覚のに焦点を合わせます。 特に、AMRかAMR-WBフレームのスピーチビットはクラスA、B、およびCに分割されます。そこでは、クラスCでビットが最も敏感ではありません中でクラスAにおけるビットがものである最も敏感である(AMRのための以下のTable1とAMR-WBのための[4]を見てください)。 最も敏感なビット(すなわち、クラスAビット)で見つけられた誤りが噛み付かれる場合にだけ、AMRかAMR-WBフレームが破損していると申告されます。 他方では、他のビットにおける誤り、すなわち、クラスBとCビットを何らかのビット持っているのは許容できます。
Class A Total speech
Index Mode bits bits
----------------------------------------
0 AMR 4.75 42 95
1 AMR 5.15 49 103
2 AMR 5.9 55 118
3 AMR 6.7 58 134
4 AMR 7.4 61 148
5 AMR 7.95 75 159
6 AMR 10.2 65 204
7 AMR 12.2 81 244
8 AMR SID 39 39
クラスA TotalスピーチIndex Modeビットビット---------------------------------------- 0 AMR4.75 42 95 1AMR5.15 49 103 2AMR5.9 55 118 3AMR6.7 58 134 4AMR7.4 61 148 5AMR7.95 75 159 6AMR10.2 65 204 7AMR12.2 81 244 8AMRシド39 39
Table 1. The number of class A bits for the AMR codec
1を見送ってください。 AMRコーデックのためのクラスAビットの数
Moreover, a damaged frame is still useful for error concealment at the decoder since some of the less sensitive bits can still be used. This approach can improve the speech quality compared to discarding the damaged frame.
そのうえ、破損しているフレームは、まだそれほど敏感でない数ビットを使用できるので、まだデコーダの誤り補正の役に立っています。 破損しているフレームを捨てると比べて、このアプローチはスピーチ品質を改良できます。
3.6.1. Applying UEP and UED in an IP Network
3.6.1. IPネットワークでUEPとUEDを適用します。
To take full advantage of the bit-error robustness of the AMR and AMR-WB codec, the RTP payload format is designed to facilitate UEP/UED in an IP network. It should be noted however that the utilization of UEP and UED discussed below is OPTIONAL.
AMRとAMR-WBコーデックのビット誤り丈夫さを最大限に利用するなら、RTPペイロード形式は、IPネットワークでUEP/UEDを容易にするように設計されます。 しかしながら、以下で議論したUEPとUEDの利用がOPTIONALであることに注意されるべきです。
Sjoberg, et al. Standards Track [Page 8] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[8ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
UEP/UED in an IP network can be achieved by detecting bit errors in class A bits and tolerating bit errors in class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload.
クラスAビットに噛み付いている誤りを検出して、それぞれのRTPペイロードのAMRかAMR-WBフレームのクラスB/Cビットに噛み付いている誤りを許容することによって、IPネットワークにおけるUEP/UEDを達成できます。
Link-layer protocols exist that do not discard packets containing bit errors, e.g., SLIP and some wireless links. With the Internet traffic pattern shifting towards a more multimedia-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums (for example, those supported by UDP-Lite [19]), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in UDP-Lite specification [19].
噛み付いている誤り、例えばSLIPを含むパケットといくつかの無線のリンクを捨てないリンク層プロトコルが存在しています。 インターネットトラフィックパターンが、よりマルチメディア中心のものに向かって移行している状態で、より多くのリンクレイヤのそのような本質は将来、現れるかもしれません。 輸送で、部分的なチェックサムのサポートは層にされています。(例えば、UDP-Lite[19])、ビットの誤りの許容性があるAMR、およびAMR-WB交通で支持されたものはこれらのタイプのリンクの上により良い性能を達成できました。 トランスポート層のUDP-Liteの部分的なチェックサムとリンクレイヤフレームによって提供されたチェックサム適用範囲との関係はUDP-Lite仕様[19]で説明されます。
There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks:
噛み付いている誤り許容性があるIPネットワークの上までAMRとAMR-WB交通を運ぶための少なくとも2つの基本的なアプローチがあります:
a) Utilizing a partial checksum to cover the IP, transport protocol
(e.g., UDP-Lite), RTP and payload headers, and the most important
speech bits of the payload. The IP, UDP and RTP headers need to
be protected, and it is recommended that at least all class A bits
are covered by the checksum.
a) ペイロードのIP、トランスポート・プロトコル(例えば、UDP-Lite)、RTP、ペイロードヘッダー、および最も重要なスピーチビットを含むのに部分的なチェックサムを利用します。 IP、UDP、およびRTPヘッダーは、保護される必要があります、そして、少なくともすべてのクラスAビットがチェックサムでカバーされているのは、お勧めです。
b) Utilizing a partial checksum to only cover the IP, transport
protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC
to cover the class A bits of each speech frame in the RTP payload.
b) IPとトランスポート・プロトコルとRTPとペイロードヘッダー、しかし、AMRをカバーするだけである部分的なチェックサムを利用するか、AMR-WBが、RTPペイロードのそれぞれのスピーチフレームのクラスAビットをカバーするためにCRCを縁どっています。
In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved.
アプローチでは、少なくともビットがエラーチェックとこのようにして噛み付いている誤り寛容なしで残されるクラスB/Cの一部が達成されます。
Note, it is still important that the network designer pays
attention to the class B and C residual bit error rate. Though
less sensitive to errors than class A bits, class B and C bits are
not insignificant, and undetected errors in these bits cause
degradation in speech quality. An example of residual error rates
considered acceptable for AMR in the Universal Mobile
Telecommunications System (UMTS) can be found in [24] and for
AMR-WB in [25].
注意、ネットワーク設計者がクラスBとC残差ビット誤り率に注意を向けるのは、まだ重要です。 クラスAビットほど誤りに敏感ではありません、クラスBとCビットはわずかではありません、そして、これらのビットにおける非検出された誤りはスピーチ品質における退行を引き起こしますが。 [24]と[25]のAMR-WBに関してUniversalのモバイルTelecommunications System(UMTS)でAMRにおいて許容できると考えられた見逃し誤りレートに関する例を見つけることができます。
The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol.
UEP/UEDトランスポート・プロトコル(例えば、UDP-Lite)へのアプリケーション・インターフェースはリンク誤り率の少しのコントロールも提供しないかもしれません、特にゲートウェイシナリオで。 したがって、ノードのデザイナーでは、このタイプのリンクインタフェースで、UEP/UEDトランスポート・プロトコルのパケットを伝えるとき、AMRコード化などのアプリケーションを支持できるくらい低い残りのビット誤り率を選ぶのは義務です。
Sjoberg, et al. Standards Track [Page 9] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[9ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Approach 1 is bit efficient, flexible and simple, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple AMR or AMR-WB frames in a RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded.
アプローチ1は、ビット効率的で、フレキシブルで簡単ですが、2回の損失と共に来ます、そして、すなわち、保護されたスピーチビットにおけるa)の噛み付いている誤りでペイロードを捨てるでしょう、そして、複数のAMRかAMR-WBを輸送するとき、b)はRTPペイロードで縁どられます、そして、保護されたビットにおけるただ一つの噛み付いている誤りですべてのフレームを捨てる可能性があります。
These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. For b), when transporting multiple frames in a payload, the CRCs remove the possibility that a single bit error in a class A bit will cause all the frames to be discarded. Avoiding that improves the speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors.
フレーム的なCRC(アプローチ2)の形で何らかのオーバーヘッドで必要であるなら、これらの損失を避けることができます。 問題a)では、CRCはスピーチ品質でクラスAビットに噛み付いている誤りを検出して、誤り補正にフレームを使用するのを可能にします。(誤り補正は小さい改良を与えます)。 ペイロードの複数のフレームを輸送するとき、b)に関しては、CRCsはクラスAビットにおけるただ一つの噛み付いている誤りですべてのフレームを捨てる可能性を取り除きます。 リンクの上に噛み付いている誤りを条件として複数のAMRかAMR-WBフレームを輸送するとき、それを避けると、スピーチ品質は改良されます。
The choice between the above two approaches must be made based on the available bandwidth, and the desired tolerance to bit errors. Neither solution is appropriate for all cases. Section 8 defines parameters that may be used at session setup to choose between these approaches.
利用可能な帯域幅、および必要な寛容に基づいて上の2つのアプローチの選択を噛み付いている誤りにしなければなりません。 すべてのケースには、どちらの解決策も適切ではありません。 セクション8はこれらのアプローチを選ぶのにセッションセットアップに使用されるかもしれないパラメタを定義します。
3.7. Robustness against Packet Loss
3.7. パケット損失に対する丈夫さ
The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss.
ペイロード形式はパケット損失に対して丈夫さを増加させるように前進型誤信号訂正(FEC)とフレームインターリービングを含むいくつかの手段を支持します。
3.7.1. Use of Forward Error Correction (FEC)
3.7.1. 前進型誤信号訂正の使用(FEC)
The simple scheme of repetition of previously sent data is one way of achieving FEC. Another possible scheme which is more bandwidth efficient is to use payload-external FEC, e.g., RFC 2733 [23], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is also a work in progress on a generic version of such a scheme [22] that can be applied to AMR or AMR-WB payload transport.
以前に送られたデータの反復の簡単な計画はFECを達成することにおいて一方通行です。 別の、より多くの帯域幅効率的な可能な計画はペイロード外部のFEC、例えば、RFC2733[23]を使用することです。([23]は修理データを含む余分なパケットを発生させます)。 また、UEPを使用することで外部のFEC計画を支持する感度命令で全体のペイロードを分類できます。 また、AMRに適用できるそのような計画[22]かAMR-WBペイロード輸送の一般的なバージョンの進行中の仕事があります。
With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of a frame using either the same mode or another mode, e.g., one with lower bandwidth. We describe such a scheme next.
AMRかAMR-WBでは、コーデックが同じモードかモードのどちらかを別使用することでフレームの余分なコピーを送るマルチレート能力を使用するのは可能です、例えば、下側の帯域幅がある1。 私たちは次に、そのような計画について説明します。
Sjoberg, et al. Standards Track [Page 10] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[10ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
This involves the simple retransmission of previously transmitted frame-blocks together with the current frame-block(s). This is done by using a sliding window to group the speech frame-blocks to send in each payload. Figure 1 below shows us an example.
これは現在のフレームブロックと共に以前に伝えられたフレームブロックの簡単な「再-トランスミッション」にかかわります。 各ペイロードを送るためにスピーチフレームブロックを分類するのに引窓を使用することによって、これをします。 以下の図1は例を私たちに示しています。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
--+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2)| f(n-1)| f(n)| f(n+1)| f(n+2)| f(n+3)| f(n+4)| --+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
<。---- p(n-1)----><。----- p(n)-----><。---- p(n+1)----><。---- p(n+2)----><。---- p(n+3)----><。---- p(n+4)---->。
Figure 1: An example of redundant transmission
図1: 余分なトランスミッションに関する例
In this example each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets.
この例では、それぞれのフレームブロックはあるとき、以下のRTPペイロードパケットで再送されます。 ここ、f(n-2)。f(n+4)はスピーチフレームブロック、およびp(n-1)の系列を指示します。ペイロードパケットのp(n+4)a系列。
The use of this approach does not require signaling at the session setup. However, a parameter for providing a maximum delay in transmitting any redundant frame is defined in Section 8. In other words, the speech sender can choose to use this scheme without consulting the receiver. This is because a packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions (encoded with different modes) of a frame for a certain timestamp if no packet is lost. If multiple versions of the same speech frame are received, it is recommended that the mode with the highest rate be used by the speech decoder.
このアプローチの使用は、セッションセットアップのときに合図するのを必要としません。 しかしながら、どんな余分なフレームも伝える最大の遅れを提供するためのパラメタはセクション8で定義されます。 言い換えれば、スピーチ送付者は、受信機に相談しないでこの計画を使用するのを選ぶことができます。余分なフレームを含むパケットが新しいフレームだけについてパケットと異なるように見えないので、これはそうです。 どんなパケットも無くならないなら、受信機はあるタイムスタンプのために、フレームの複本かバージョン(異なったモードで、コード化される)を受けるかもしれません。 同じスピーチフレームの複数のバージョンが受け取られているなら、最も高いレートがあるモードがスピーチデコーダによって使用されるのは、お勧めです。
This redundancy scheme provides the same functionality as the one described in RFC 2198, "RTP Payload for Redundant Audio Data" [27]. In most cases the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198 in addition. There are two situations in which use of RFC 2198 is indicated: if the spread in time required between the primary and redundant encodings is larger than the duration of 5 frames, the bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec is desired for the redundant encoding, the AMR payload format won't be able to carry it.
この冗長計画はRFC2198(「余分なオーディオデータのためのRTP有効搭載量」[27])で説明されたものと同じ機能性を提供します。 多くの場合、このペイロード形式のメカニズムは、さらに、RFC2198を支持するために両方の終点を必要とするよりさらに効率的であって、簡単です。 RFC2198の使用が示される2つの状況があります: 時間内に第一の、そして、余分なencodingsの間で必要であった普及が5個のフレームの持続時間より大きいなら、RFC2198の帯域幅オーバーヘッドは低いでしょう。 または、非AMRコーデックが余分なコード化のために望まれていると、AMRペイロード形式はそれを運ぶことができないでしょう。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g., in RTCP
送付者はチャンネル、例えば、RTCPでのフィードバックに基づく適切な量の冗長を選択するのに責任があります。
Sjoberg, et al. Standards Track [Page 11] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[11ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information, e.g., radio link performance measures. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 6 for more details).
受信機は報告します。 送付者のFECの選択はCMRに基づいているべきではありません、このパラメタが非IP情報に基づいて最もたぶん設定されたとき、例えば、ラジオリンク性能測定。 また、送付者も混雑を避けるのに責任があります(その他の詳細に関してセクション6を見てください)。(混雑は冗長によって悪化させられるかもしれません)。
3.7.2. Use of Frame Interleaving
3.7.2. フレームインターリービングの使用
To decrease protocol overhead, the payload design allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that packet loss can cause loss of several consecutive speech frame-blocks, which usually causes clearly audible distortion in the reconstructed speech. Interleaving of frame-blocks can improve the speech quality in such cases by distributing the consecutive losses into a series of single frame- block losses. However, interleaving and bundling several frame- blocks per payload will also increase end-to-end delay and is therefore not appropriate for all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions.
プロトコルオーバーヘッドを下げるために、ペイロードデザインは、いくつかのスピーチフレームブロックが単一のRTPパケットに要約されるのを許容します。 そのようなアプローチの欠点の1つはパケット損失が通常、再建されたスピーチで明確に聞きとれるひずみを引き起こすいくつかの連続したスピーチフレームブロックの損失をもたらすことができるということです。 フレームブロックのインターリービングは、そのような場合一連の単一のフレームブロックの損失に連敗を広げることによって、スピーチ品質を改良できます。 しかしながら、いくつかの1ペイロードあたりのフレームブロックをはさみ込んで、束ねるのは、また、終わりから終わりへの遅れを増加させて、すべてのタイプのアプリケーションには、したがって、適切ではありません。 ストリーミング・アプリケーションは、損失性トランスミッション状態のスピーチ品質を改良するのにたぶんインターリービングを利用できるでしょう。
This payload design supports the use of frame interleaving as an option. For the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) needs to indicate its support via out-of-band means (see Section 8).
このペイロードデザインはオプションとしてフレームインターリービングの使用を支持します。 エンコーダ(スピーチ送付者)が当然のことのセッションに外国行きのRTPパケットでフレームインターリービングを使用するように、デコーダ(スピーチ受信機)は、バンドで出ている手段でサポートを示す必要があります(セクション8を見てください)。
3.8. Bandwidth-Efficient or Octet-Aligned Mode
3.8. 帯域幅効率的であるか八重奏で並べられたモード
For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means.
当然のことのセッションのために、ペイロード形式が帯域幅効率的である場合がありますか、または八重奏は並びました、セッションのためにバンドで出ている手段で確立される運転モードによって。
In the octet-aligned format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added.
八重奏で並べられた形式では、ペイロードヘッダー、目次エントリー、およびスピーチフレーム自体を含むペイロードのすべての分野が、実現を効率的にするように個別に八重奏境界に並べられます。 帯域幅効率的な形式では、完全な唯一のペイロードは並べられるのでビットが加えられるためにそっと歩いていない八重奏です。
Note, octet alignment of a field or payload means that the last
octet is padded with zeroes in the least significant bits to fill
the octet. Also note that this padding is separate from padding
indicated by the P bit in the RTP header.
注意、分野かペイロードの八重奏整列は最後の八重奏がゼロで最下位ビットで水増しされて、八重奏をいっぱいにすることを意味します。 また、この詰め物がRTPヘッダーでPビットによって示された詰め物から別々であることに注意してください。
Between the two operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors.
2つのオペレーションモードの間では、八重奏で並べられたモードだけがスピーチをパケット損失により体力を要している輸送と噛み付いている誤りにする体力を要しているソーティングを使用する能力、インターリービング、およびフレームCRCを持っています。
Sjoberg, et al. Standards Track [Page 12] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[12ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
3.9. AMR or AMR-WB Speech over IP Scenarios
3.9. IPシナリオの上のAMRかAMR-WBスピーチ
The primary scenario for this payload format is IP end-to-end between two terminals, as shown in Figure 2. This payload format is expected to be useful for both conversational and streaming services.
このペイロード形式のための第一のシナリオは、図2に示されるように2台の端末の間のIPの終わりから終わりです。 このペイロード形式が会話の、そして、ストリーミングの両方のサービスの役に立つと予想されます。
+----------+ +----------+
| | IP/UDP/RTP/AMR or | |
| TERMINAL |<----------------------->| TERMINAL |
| | IP/UDP/RTP/AMR-WB | |
+----------+ +----------+
+----------+ +----------+ | | またはIP/UDP/RTP/AMR。| | | 端末| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 端末| | | IP/UDP/RTP/AMR-Wb| | +----------+ +----------+
Figure 2: IP terminal to IP terminal scenario
図2: IPの端末のシナリオへのIP端末
A conversational service puts requirements on the payload format. Low delay is one very important factor, i.e., few speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses low bandwidth links, especially as the frequency of packets will be high. For low bandwidth links, it is also an advantage to support UED, which allows a link provider to reduce delay and packet loss, or to reduce the utilization of link resources.
会話のサービスはペイロード形式に要件を置きます。 ペイロードパケットあたり低い遅れは1つの非常に重要な要素、すなわち、スピーチフレーム数ブロックです。 また、ペイロード形式が低い帯域幅リンクを横断するとき、低いオーバーヘッドが必要です、特にパケットの頻度が高くなるように。 低い帯域幅リンクに関しては、また、それはリンクプロバイダーに遅れとパケット損失を抑えさせるUEDを支持するか、またはリンクリソースの利用を抑える利点です。
A streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than a conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect that packet loss will have on speech quality. A streaming server handling a large number of clients also needs a payload format that requires as few resources as possible when doing packetization. The octet-aligned and interleaving modes require the least amount of resources, while CRC, robust sorting, and bandwidth-efficient modes have higher demands.
ストリーミングのサービスは、会話のサービスよりそれほど厳しくないリアルタイムの要件を持って、したがって、より多くの1パケットあたりのフレームブロックを使用できます。 これはIP、UDP、およびRTPヘッダーからオーバーヘッドを下げます。 しかしながら、いくつかの1パケットあたりのフレームブロックを含んでいるのにトランスミッションがパケット損失により傷つきやすくなるので、インターリービングはパケット損失がスピーチ品質に持っている効果を減少させるのに使用されるかもしれません。 また、多くのクライアントを扱うストリーミングサーバはpacketizationをするときできるだけわずかなリソースを必要とするペイロード形式を必要とします。 八重奏で並べられるのとインターリービングモードはリソースの最小量を必要とします、CRC、体力を要しているソーティング、および帯域幅効率的なモードには、より高い要求がありますが。
Another scenario is when AMR or AMR-WB encoded speech is transmitted from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
別のシナリオはAMRかAMR-WBがいつスピーチをコード化したかが非IPシステム(例えば、GSMか3GPP UMTSネットワーク)からIP/UDP/RTP VoIP端末まで送られて、逆もまた同様ですということです、図3に表現されるように。
Sjoberg, et al. Standards Track [Page 13] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[13ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
AMR or AMR-WB
over
I.366.{2,3} or +------+ +----------+
3G Iu or | | IP/UDP/RTP/AMR or | |
<------------->| GW |<---------------------->| TERMINAL |
GSM Abis | | IP/UDP/RTP/AMR-WB | |
etc. +------+ +----------+
|
GSM/ | IP network
3GPP UMTS network |
AMRかAMR-WB、終わっている、I.366 2、3、+------+ +----------または+ 3G Iu。| | またはIP/UDP/RTP/AMR。| | <、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 端末| GSM Abis| | IP/UDP/RTP/AMR-Wb| | など +------+ +----------+ | GSM/| IPネットワーク3GPP UMTSネットワーク|
Figure 3: GW to VoIP terminal scenario
図3: VoIPの端末のシナリオへのGW
In such a case, it is likely that the AMR or AMR-WB frame is packetized in a different way in the non-IP network and will need to be re-packetized into RTP at the gateway. Also, speech frames from the non-IP network may come with some UEP/UED information (e.g., a frame quality indicator) that will need to be preserved and forwarded on to the decoder along with the speech bits. This is specified in Section 4.3.2.
このような場合には、AMRかAMR-WBフレームが、非IPネットワークにおける異なった方法でpacketizedされて、ゲートウェイのRTPに再packetizedされる必要がありそうでしょう。 また、非IPネットワークからのスピーチフレームはスピーチビットに伴うデコーダに保存されて、送られる必要がある何らかのUEP/UED情報(例えば、フレーム質のインディケータ)と共に、来るかもしれません。 これはセクション4.3.2で指定されます。
AMR's capability to do fast mode switching is exploited in some non- IP networks to optimize speech quality. To preserve this functionality in scenarios including a gateway to an IP network, a codec mode request (CMR) field is needed. The gateway will be responsible for forwarding the CMR between the non-IP and IP parts in both directions. The IP terminal should follow the CMR forwarded by the gateway to optimize speech quality going to the non-IP decoder. The mode control algorithm in the gateway must accommodate the delay imposed by the IP network on the IP terminal's response to CMR.
速いモードの切り換えをするAMRの能力は、スピーチ品質を最適化するためにいくつかの非IPのネットワークで開発されます。 IPネットワークへのゲートウェイを含んでいて、シナリオにこの機能性を保存するために、コーデックモード要求(CMR)分野が必要です。 ゲートウェイは両方の指示で非IPとIPの部品の間にCMRを送るのに原因となるようになるでしょう。 IP端末はゲートウェイによって進められた、非IPデコーダに行くスピーチ品質を最適化したCMRに続くはずです。 ゲートウェイのモードコントロールアルゴリズムはIPネットワークによってCMRへのIP端末の応答に課された遅れを収容しなければなりません。
The IP terminal should not set the CMR (see Section 4.3.1), but the gateway can set the CMR value on frames going toward the encoder in the non-IP part to optimize speech quality from that encoder to the gateway. The gateway can alternatively set a lower CMR value, if desired, as one means to control congestion on the IP network.
IP端末はCMRを設定するはずがありませんが(セクション4.3.1を見てください)、ゲートウェイは、非IP部分のエンコーダに向かって行くフレームのCMR値にそのエンコーダからゲートウェイまでスピーチ品質を最適化するように設定できます。 あるいはまた、ゲートウェイは下側のCMR値を設定できます、望まれているなら、人が、IPネットワークで混雑を制御するのを意図するように。
A third likely scenario is that IP/UDP/RTP is used as transport between two non-IP systems, i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 4 below.
3番目のありそうなシナリオはIP/UDP/RTPが2台の非IPシステムの間の輸送として使用されて、すなわち、IPがIP輸送の両側のゲートウェイで溯源されて、終えられるということです、以下の図4で例証されるように。
Sjoberg, et al. Standards Track [Page 14] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[14ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
AMR or AMR-WB AMR or AMR-WB
over over
I.366.{2,3} or +------+ +------+ I.366.{2,3} or
3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or
<------------->| GW |<------------------->| GW |<------------->
GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis
etc. +------+ +------+ etc.
| |
GSM/ | IP network | GSM/
3GPP UMTS network | | 3GPP UMTS network
I.366の上のAMR、AMR-WB AMRまたはAMR-WB、2、3、+------+ +------または+ I.366 2、3、3G Iu。| | またはIP/UDP/RTP/AMR。| | 3G Iuか<。------------->| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-->GSM Abis| | IP/UDP/RTP/AMR-Wb| | GSM Abisなど +------+ +------+ など | | GSM/| IPネットワーク| GSM/ 3GPP UMTSネットワーク| | 3GPP UMTSネットワーク
Figure 4: GW to GW scenario
図4: GWシナリオへのGW
This scenario requires the same mechanisms for preserving UED/UEP and CMR information as in the single gateway scenario. In addition, the CMR value may be set in packets received by the gateways on the IP network side. The gateway should forward to the non-IP side a CMR value that is the minimum of three values:
このシナリオは、ただ一つのゲートウェイシナリオのようにUED/UEPとCMR情報を保存するために同じメカニズムを必要とします。 さらに、CMR値はIPネットワーク側の上のゲートウェイによって受け取られたパケットに設定されるかもしれません。 ゲートウェイは3つの値の最小限であるCMR値を非IP側に送るはずです:
- the CMR value it receives on the IP side;
- それがIP側で受けるCMR値。
- the CMR value it calculates based on its reception quality on
the non-IP side; and
- それが非IP側のレセプション品質に基づいて計算するCMR値。 そして
- a CMR value it may choose for congestion control of
transmission on the IP side.
- それがIP側におけるトランスミッションの輻輳制御に選ぶかもしれないCMR値。
The details of the control algorithm are left to the implementation.
コントロールアルゴリズムの詳細は実現に残されます。
4. AMR and AMR-WB RTP Payload Formats
4. AMRとAMR-WB RTP有効搭載量形式
The AMR and AMR-WB payload formats have identical structure, so they are specified together. The only differences are in the types of codec frames contained in the payload. The payload format consists of the RTP header, payload header, and payload data.
AMRとAMR-WBペイロード形式には同じ構造があるので、それらは一緒に指定されます。 唯一の違いがペイロードに含まれたコーデックフレームのタイプであります。 ペイロードヘッダー、ペイロード形式がRTPヘッダーから成る、そして、ペイロードデータ。
4.1. RTP Header Usage
4.1. RTPヘッダー用法
The format of the RTP header is specified in [8]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[8]で指定されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the sampling frequency, so the timestamp unit is in samples.
RTPタイムスタンプはパケットにおける最初のフレームブロックにコード化された最初のサンプルの標本抽出の瞬間に対応しています。 タイムスタンプクロック周波数がサンプリング周波数と同じであるので、タイムスタンプユニットがサンプルにあります。
Sjoberg, et al. Standards Track [Page 15] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[15ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
The duration of one speech frame-block is 20 ms for both AMR and AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame from each channel. For AMR-WB, the sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame-block.
1つのスピーチフレームブロックの持続時間はAMRとAMR-WBの両方のための20msです。 AMRに関しては、サンプリング周波数が8kHzである、160に対応するのは各チャンネルから1フレームあたりのスピーチのサンプルをコード化しました。 AMR-WBに関しては、サンプリング周波数は各チャンネルから1フレームあたり320個のサンプルに対応する16kHzです。 したがって、タイムスタンプはそれぞれの連続したフレームブロックにAMRのための160、そしてAMR-WBのための320増加します。
A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is employed, the frame- blocks encapsulated into a payload are picked according to the interleaving rules as defined in Section 4.4.1. Otherwise, each packet covers a period of one or more contiguous 20 ms frame-block intervals. In case the data from all the channels for a particular frame-block in the period is missing (for example, at a gateway from some other transport format), it is possible to indicate that no data is present for that frame-block rather than breaking a multi-frame- block packet into two, as explained in Section 4.3.2.
パケットは複数のフレームブロックのコード化されたスピーチか安らぎ雑音パラメタを含むかもしれません。 インターリービングが採用しているなら、インターリービング規則に従って、ペイロードに要約されたフレームブロックはセクション4.4.1で定義されるように選ばれます。 さもなければ、各パケットは1か20回のより隣接のmsフレームブロック間隔の期間をカバーしています。 期間の特定のフレームブロックすべてのチャンネルからのデータがなくなるといけないので(例えばある他の輸送形式からのゲートウェイで)、どんなデータもマルチフレームのブロックしているパケットを2に細かく分けるよりむしろそのフレームブロックに存在していないのを示すのは可能です、セクション4.3.2で説明されるように。
To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times, in exact duplicates, in different AMR rate modes, or with data present in one packet and not present in another. If multiple versions of the same speech frame are received, it is RECOMMENDED that the mode with the highest rate be used by the speech decoder. A given frame MUST NOT be encoded as speech in one packet and comfort noise parameters in another.
余分なトランスミッションで誤りの弾性を考慮するために、複数のパケットでカバーされた期間は時間内に、重なるかもしれません。 複数の回あらゆるスピーチフレームを受け取るように受信機を準備しなければなりません、異なったAMRレートモード、または1つのパケットで現在の、そして、別のものの現在でないデータがある正確な写しで。 同じスピーチフレームの複数のバージョンが受け取られているなら、最も高いレートがあるモードがスピーチデコーダによって使用されるのは、RECOMMENDEDです。 1つのパケットのスピーチと安らぎ雑音パラメタとして別のもので与えられたフレームをコード化してはいけません。
The payload length is always made an integral number of octets by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP in the header may be set and padding appended as specified in [8].
ペイロード長はいつも作られています。必要なら、ゼロ・ビットでそっと歩くのによる整数の八重奏。 追加詰め物が八重奏の、より大きい倍数かある他の目的にペイロード長をもたらすのに必要であるなら、ヘッダーのRTPのPビットは、[8]で指定されるように追加されたセットと詰め物であるかもしれません。
The RTP header marker bit (M) SHALL be set to 1 if the first frame- block carried in the packet contains a speech frame which is the first in a talkspurt. For all other packets the marker bit SHALL be set to zero (M=0).
RTPヘッダーマーカーは(M) SHALLに噛み付きました。パケットで運ばれた最初フレームのブロックがtalkspurtで1番目であるスピーチフレームを含むなら、1に用意ができてください。 他のすべてのパケットに関しては、マーカーはゼロへのセットが(M=0)であったならSHALLに噛み付きました。
The assignment of an RTP payload type for this new 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 encoding or specify that the payload type is to be bound dynamically.
この新しいパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 このペイロード形式が使用されているRTPプロフィールが、このコード化のためのペイロードタイプを選任するか、またはペイロードタイプによってダイナミックに制限されていることになっていると指定すると予想されます。
Sjoberg, et al. Standards Track [Page 16] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[16ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
4.2. Payload Structure
4.2. 有効搭載量構造
The complete payload consists of a payload header, a payload table of contents, and speech data representing one or more speech frame- blocks. The following diagram shows the general payload format layout:
完全なペイロードはペイロードヘッダーから成ります、ペイロード目次、そして、1つ以上のスピーチを表すスピーチデータがブロックを縁どっています。 以下のダイヤグラムは一般的なペイロード形式レイアウトを示しています:
+----------------+-------------------+---------------- | payload header | table of contents | speech data ... +----------------+-------------------+----------------
+----------------+-------------------+---------------- | ペイロードヘッダー| 目次| スピーチデータ… +----------------+-------------------+----------------
Payloads containing more than one speech frame-block are called compound payloads.
1つ以上のスピーチフレームブロック以上を含む有効搭載量は合成ペイロードと呼ばれます。
The following sections describe the variations taken by the payload format depending on whether the AMR session is set up to use the bandwidth-efficient mode or octet-aligned mode and any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet- aligned operation to increase interoperability.
以下のセクションはAMRセッションが体力を要しているソーティング、インターリービング、およびフレームCRCsに帯域幅効率的なモードか八重奏で並べられたモードとOPTIONAL機能のどれかを使用するためにセットアップされるかどうかに依存するペイロード形式によって取られた変化について説明します。 実現SHOULDは帯域幅効率的な状態で両方を支持します、そして、八重奏は相互運用性を増加させるように操作を並べました。
4.3. Bandwidth-Efficient Mode
4.3. 帯域幅効率的なモード
4.3.1. The Payload Header
4.3.1. 有効搭載量ヘッダー
In bandwidth-efficient mode, the payload header simply consists of a 4-bit codec mode request:
帯域幅効率的なモードで、ペイロードヘッダーは4ビットのコーデックモード要求から単に成ります:
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+
0 1 2 3 +-+-+-+-+ | CMR| +-+-+-+-+
CMR (4 bits): Indicates a codec mode request sent to the speech
encoder at the site of the receiver of this payload. The value of
the CMR field is set to the frame type index of the corresponding
speech mode being requested. The frame type index may be 0-7 for
AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined
in Table 1a in [4]. CMR value 15 indicates that no mode request
is present, and other values are for future use.
CMR(4ビット): コーデックモード要求がこのペイロードの受信機のサイトのスピーチエンコーダに発信したのを示します。 CMR分野の値は要求されている対応するスピーチモードのフレームタイプインデックスに設定されます。 フレームタイプインデックスはAMR、AMR-WBのために[2]、または0-8でTable 1aで定義されるように0-7であるかもしれません、[4]でTable 1aで定義されるように。 CMR値15はどんなモード要求も存在していなくて、他の値が今後の使用のためのものであることを示します。
The codec mode request received in the CMR field is valid until the next codec mode request is received, i.e., a newly received CMR value corresponding to a speech mode, or NO_DATA overrides the previously received CMR value corresponding to a speech mode or NO_DATA. Therefore, if a terminal continuously wishes to receive frames in the
次のコーデックモード要求が受信されるまでCMR分野に受け取られたコーデックモード要求が有効である、すなわち、スピーチモード、またはいいえ_DATAに対応する新たに受け取られたCMR値はスピーチモードに対応する以前に容認されたCMR値かいいえ_DATAをくつがえします。 したがって、端末は中で絶え間なくフレーム搬入したがっています。
Sjoberg, et al. Standards Track [Page 17] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[17ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
same mode X, it needs to set CMR=X for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads.
同じモードX、すべての外国行きのペイロードと端末がどのモードを受けたらよいかでどちらでもよいかどうかCMR=Xを設定するのが必要であり、すべての外国行きのペイロードのSHOULDセットCMR=15です。
If receiving a payload with a CMR value that is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver.
ペイロードを受けるなら、スピーチモードでないCMR値かいいえ_DATA、CMR MUSTと共に、受信機によって無視されてください。
In a multi-channel session, the codec mode request SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session.
マルチチャンネルセッションのときに、コーデックモードは、SHOULDがセッションのときにすべてのチャンネルに、必要なコード化モードとしてペイロードの受信機によって解釈されるよう要求します。
An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, for several reasons:
コーデックモード要求がパケット損失に基礎づけたIPエンドポイントSHOULD NOTセットかいくつかの理由のための他の混雑指摘:
- The other end of the IP path may be a gateway to a non-IP
network (such as a radio link) that needs to set the CMR field
to optimize performance on that network.
- IP経路のもう一方の端はCMR分野にそのネットワークに関する性能を最適化するように設定する必要がある非IPネットワーク(ラジオリンクなどの)へのゲートウェイであるかもしれません。
- Congestion on the IP network is managed by the IP sender, in
this case, at the other end of the IP path. Feedback about
congestion SHOULD be provided to that IP sender through RTCP or
other means, and then the sender can choose to avoid congestion
using the most appropriate mechanism. That may include
adjusting the codec mode, but also includes adjusting the level
of redundancy or number of frames per packet.
- IPネットワークにおける混雑はIP送付者によって管理されます、この場合、IP経路のもう一方の端で。 フィードバック、混雑SHOULDに関して、RTCPか他の手段でそのIP送付者に前提とされてください。そうすれば、次に、送付者は、最も適切なメカニズムを使用することで混雑を避けるのを選ぶことができます。 それは、コーデックモードを調整するのを含むかもしれませんが、冗長のレベルか1パケットあたりのフレームの数を調整するのをまた含んでいます。
The encoder SHOULD follow a received codec mode request, but MAY change to a lower-numbered mode if it so chooses, for example, to control congestion.
エンコーダSHOULDは受信されたコーデックモード要求に続きますが、したがって、例えば、それが、混雑を制御するのを選ぶかどうかをより低く番号付のモードに変えるかもしれません。
The CMR field MUST be set to 15 for packets sent to a multicast group. The encoder in the speech sender SHOULD ignore codec mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a codec mode change is needed.
マルチキャストグループに送られたパケットのためにCMR分野を15に設定しなければなりません。 コーデックモード変更がマルチキャストセッションにスピーチを送るときヒントとしてRTCPフィードバック情報を使用するかもしれないのを除いて、モードが要求するコーデックですが、必要であることで、送付者SHOULDが無視するスピーチにおけるエンコーダ。
The codec mode selection MAY be restricted by a session parameter to a subset of the available modes. If so, the requested mode MUST be among the signalled subset (see Section 8). If the received CMR value is outside the signalled subset of modes, it MUST be ignored.
コーデックモード選択はセッションパラメタによって利用可能なモードの部分集合に制限されるかもしれません。 そうだとすれば、合図された部分集合の中に要求されたモードがあるに違いありません(セクション8を見てください)。 モードの合図された部分集合の外で容認されたCMR値があるなら、それを無視しなければなりません。
4.3.2. The Payload Table of Contents
4.3.2. 有効搭載量目次
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
それぞれスピーチフレームを表して、目次(ToC)はToCエントリーのリストから成ります。
Sjoberg, et al. Standards Track [Page 18] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[18ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
In bandwidth-efficient mode, a ToC entry takes the following format:
帯域幅効率的なモードで、ToCエントリーは以下の形式を取ります:
0 1 2 3 4 5
+-+-+-+-+-+-+
|F| FT |Q|
+-+-+-+-+-+-+
0 1 2 3 4 5 +-+-+-+-+-+-+ |F| フィート|Q| +-+-+-+-+-+-+
F (1 bit): If set to 1, indicates that this frame is followed by
another speech frame in this payload; if set to 0, indicates that
this frame is the last frame in this payload.
F(1ビット): 1にセットして、別のスピーチフレームがこのペイロードでこのフレームを支えるのを示します。 0にセットして、このフレームがこのペイロードは最後のフレームであることを示します。
FT (4 bits): Frame type index, indicating either the AMR or AMR-WB
speech coding mode or comfort noise (SID) mode of the
corresponding frame carried in this payload.
FT(4ビット): フレームタイプは索引をつけます、モードをコード化するAMRかAMR-WBスピーチかこのペイロードで運ばれた対応するフレームの安らぎ雑音(SID)モードのどちらかを示して。
The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively.
FTの値はAMR-WBのための[4]でAMRのための[2]とTable 1aのTable 1aで定義されます。 FT=14(単にAMR-WBに利用可能なSPEECH_LOST)とFT=15(いいえ_DATA)は、なくされているか、またはこのペイロードでそれぞれ伝えられていないフレームを示すのに使用されます。
NO_DATA (FT=15) frame could mean either that no data for that frame has been produced by the speech encoder or that no data for that frame is transmitted in the current payload (i.e., valid data for that frame could be sent in either an earlier or later packet).
どんな_DATA(FT=15)フレームも意味できなかった、そのノー、データ、そのフレームがスピーチエンコーダによって生産されたか、またはそれのためのデータが縁どるそのノーが現在のペイロードで伝えられるので(より初期の、または、より遅いパケットでそのフレームのためのすなわち、有効データを送ることができました)。
If receiving a ToC entry with a FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a huge degradation in speech quality.
AMR-WB、全体のパケットSHOULDのためのFT値がAMRか10-13のための範囲9-14にある状態でToCエントリーを受けるのは捨てられます。 これは、depacketizationの過程における、データ同期の損失を避けるためのものです。(過程は、スピーチ品質における巨大な退行をもたらすことができます)。
Note that packets containing only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7].
_DATAフレームだけがないSHOULD NOTを含むパケットがインターリービングに関するケース以外のどんなペイロード形式構成でも伝えられることに注意してください。 また、パケットの端に_DATAフレームだけを全く含まないフレームブロックSHOULD NOTがどんなペイロード形式構成でも伝えられて、インターリービングの場合で除いてください。 AMR SCR/DTXは[7]で[6]とAMR-WB SCR/DTXで説明されます。
The extra comfort noise frame types specified in table 1a in [2] (i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format because the standardized AMR codec is only required to implement the general AMR SID frame type and not those that are native to the incorporated encodings.
一層の安らぎ雑音フレームタイプが[2]でテーブル1aで指定した、(すなわち、GSM-EFR CN、-641である、CN、PDC-EFR CN) 標準化されたAMRコーデックが法人組織のencodingsのネイティブであるものではなく、一般的なAMR SIDフレームタイプを実行するだけでよいので、このペイロード形式に使用されてはいけません。
Q (1 bit): Frame quality indicator. If set to 0, indicates the
corresponding frame is severely damaged, and the receiver should
set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD
depending on the frame type (FT).
Q(1ビット): 質のインディケータを縁どってください。 対応するフレームはひどく傷つけられています、そして、受信機はRX_TYPEを設定するはずです。0に設定されるなら表示、(フレームへのSPEECH_BADかSID_BAD依存のどちらかへの[6])が(FT)をタイプするのを見てください。
Sjoberg, et al. Standards Track [Page 19] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[19ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], as well as other transport formats. The frame quality indicator enables damaged frames to be forwarded to the speech decoder for error concealment. This can improve the speech quality more than dropping the damaged frames. See Section 4.4.2.1 for more details.
フレーム質のインディケータはATMペイロード形式がITU-T I.366.2で説明されている相互運用性のために含まれています、UMTS Iuインタフェース[20]、他の輸送形式と同様に。 フレーム質のインディケータは、破損しているフレームが誤り補正のためのスピーチデコーダに送られるのを可能にします。 これは破損しているフレームを落とすよりスピーチ品質を改良できます。 セクション4.4を見てください。.2 .1 その他の詳細のために。
For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order as defined in Section 4.1 in [12]. When multiple frame-blocks are present in a packet in bandwidth-efficient mode, they will be placed in the packet in order of their creation time.
マルチチャンネルセッションのために、フレームブロックからのすべてのフレームのToCエントリーは[12]でセクション4.1で定義されるように連続したオーダーにToCに置かれます。 複数のフレームブロックが帯域幅効率的なモードによるパケットに存在しているとき、それらは彼らの創造時間の順にパケットに置かれるでしょう。
Therefore, with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC, and the first N entries will be from the first frame-block, the second N entries will be from the second frame-block, and so on.
したがって、NチャンネルとKスピーチフレームブロックがパケットにある状態で、エントリーがToCにN*Kあるに違いありません、そして、最初のNエントリーが最初のフレームブロックからあるでしょう、Nエントリーが2番目のフレームブロックなどからある秒に。
The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode.
以下の図は、帯域幅効率的なモードを使用することで単独のチャンネルセッションにおける3つのエントリーのToCに関する例を示しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT |Q|1| FT |Q|0| FT |Q|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| フィート|Q|1| フィート|Q|0| フィート|Q| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is an example of how the ToC entries will appear in the ToC of a packet carrying three consecutive frame-blocks in a session with two channels (L and R).
以下に、ToCエントリーが2個のチャンネル(LとR)とのセッションのときに3つの連続したフレームブロックを運びながらパケットのToCにどう現れるかに関する例があります。
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 2 Block 3
+----+----+----+----+----+----+ | 1L| 1R| 2L| 2R| 3L| 3R| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレーム2つのブロック1ブロックブロック3
4.3.3. Speech Data
4.3.3. スピーチデータ
Speech data of a payload contains zero or more speech frames or comfort noise frames, as described in the ToC of the payload.
ペイロードに関するスピーチデータはゼロか、より多くのスピーチフレームか安らぎ雑音フレームを含んでいます、ペイロードのToCで説明されるように。
Note, for ToC entries with FT=14 or 15, there will be no
corresponding speech frame present in the speech data.
FT=14か15があるToCエントリーによって、スピーチデータの現在のどんな対応するスピーチフレームもないことに注意してください。
Sjoberg, et al. Standards Track [Page 20] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[20ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1).
それぞれのスピーチフレームはモードが対応するToCエントリーのFT分野で示されている状態でコード化されたスピーチの20msを表します。 スピーチフレームの長さはFT分野で示されたモードでそれとなく定義されます。 ビットの注文と付番記法がAMRのための[2]とAMR-WBのための[4]のInterface Format1(IF1)に指定されるようにあります。 そこで指定されるように、感度を減少させることの順にスピーチフレームのビットを再配列してあります、安らぎ雑音フレームのビットがエンコーダによって作り出されたオーダーにありますが。 長さのKビットのフレームへの結果として起こる噛み付いている系列は指示されたd(0)、d(1)です…, d(K-1)。
4.3.4. Algorithm for Forming the Payload
4.3.4. 有効搭載量を形成するためのアルゴリズム
The complete RTP payload in bandwidth-efficient mode is formed by packing bits from the payload header, table of contents, and speech frames in order (as defined by their corresponding ToC entries in the ToC list), and to bring the payload to octet alignment, 0 to 7 padding bits. Padding bits MUST be set to zero and MUST be ignored on reception. They are packed contiguously into octets beginning with the most significant bits of the fields and the octets.
帯域幅効率的なモードによる完全なRTPペイロードがペイロードヘッダー、目次、およびスピーチフレームから整然とした状態でビットを梱包することによって形成される、(ToCリストで彼らの対応するToCエントリーで定義されるように)八重奏整列(0〜7詰め物ビット)にペイロードを持って来ます。 ビットを水増しするのをゼロに設定しなければならなくて、レセプションで無視しなければなりません。 それらは分野と八重奏の最も重要なビットで始まる八重奏に近接して詰め込みます。
To be precise, the four-bit payload header is packed into the first octet of the payload with bit 0 of the payload header in the most significant bit of the octet. The four most significant bits (numbered 0-3) of the first ToC entry are packed into the least significant bits of the octet, ending with bit 3 in the least significant bit. Packing continues in the second octet with bit 4 of the first ToC entry in the most significant bit of the octet. If more than one frame is contained in the payload, then packing continues with the second and successive ToC entries. Bit 0 of the first data frame follows immediately after the last ToC bit, proceeding through all the bits of the frame in numerical order. Bits from any successive frames follow contiguously in numerical order for each frame and in consecutive order of the frames.
正確に言うと、ペイロードヘッダーのビット0が八重奏の最も重要なビットにある状態で、4ビットのペイロードヘッダーはペイロードの最初の八重奏に詰め込まれます。 最初のToCエントリーの4つの最上位ビット(0-3に付番される)が八重奏の最下位ビットに詰め込まれます、ビット3で最下位ビットに終わって。 最初のToCエントリーのビット4が八重奏の最も重要なビットにある状態で、パッキングは2番目の八重奏で続きます。 1個以上のフレームがペイロードに含まれているなら、パッキングは2番目の、そして、連続したToCエントリーを続行します。 最初のデータフレームのビット0は最後のToCビット直後続きます、フレームのすべてのビットを通して番号順に続いて。 どんな連続したフレームからのビットも番号順に各フレームとフレームの連続した注文で近接して続きます。
If speech data is missing for one or more speech frame within the sequence, because of, for example, DTX, a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each of the missing frames, but no data bits are included in the payload for the missing frame (see Section 4.3.5.2 for an example).
それぞれのなくなったフレームを含んでいますが、どんなデータ・ビットもなくなったフレームへのペイロードに含まれていなくて、1つ以上のスピーチにおいて、スピーチデータがなくなるなら例えば、DTX、FTセットがToCでいいえ_DATA SHALLに含められているToCエントリーのために系列の中で縁どってください、(セクション4.3.5を見てください、例のための.2)
4.3.5. Payload Examples
4.3.5. 有効搭載量の例
4.3.5.1. Single-Channel Payload Carrying a Single Frame
4.3.5.1. シングルフレームを運ぶ単独のチャンネル有効搭載量
The following diagram shows a bandwidth-efficient AMR payload from a single-channel session carrying a single speech frame-block.
以下のダイヤグラムは1つのスピーチフレームブロックを運ぶ単独のチャンネルセッションから帯域幅効率的なAMRペイロードを示しています。
Sjoberg, et al. Standards Track [Page 21] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[21ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
In the payload, no specific mode is requested (CMR=15), the speech frame is not damaged at the IP origin (Q=1), and the coding mode is AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are arranged in descending sensitivity order according to [2]. Finally, two padding bits (P) are added to the end as padding to make the payload octet aligned.
ペイロードでは、どんな特定のモードも要求されていません、そして、(CMR=15)スピーチフレームはIPの起源(Q=1)で破損しません、そして、コード化モードはAMR7.4キロビット毎秒(FT=4)です。 コード化されたスピーチビット(d(147)へのd(0))は[2]に応じて感度オーダーを滑降させる際にアレンジされます。 最終的に、2詰め物ビット(P)はペイロード八重奏を並べさせるためにそっと歩くとして終わりに加えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=15|0| FT=4 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(147)|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|0| フィート=4|1|d(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(147)|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.5.2. Single-Channel Payload Carrying Multiple Frames
4.3.5.2. 複数のフレームを運ぶ単独のチャンネル有効搭載量
The following diagram shows a single-channel, bandwidth-efficient compound AMR-WB payload that contains four frames, of which one has no speech data. The first frame is a speech frame at 6.6 kbps mode (FT=0) that is composed of speech bits d(0) to d(131). The second frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to g(39). The third frame is a NO_DATA frame and does not carry any speech information, it is represented in the payload by its ToC entry. The fourth frame in the payload is a speech frame at 8.85 kbps mode (FT=1), it consists of speech bits h(0) to h(176).
以下のダイヤグラムはどれにスピーチデータが全くないかに関する4個のフレームを含む単独のチャンネルの、そして、帯域幅効率的な合成AMR-WBペイロードを示しています。 最初のフレームはd(131)にスピーチビットd(0)で構成される6.6キロビット毎秒モード(FT=0)でスピーチフレームです。 2番目のフレームはg(39)にビットg(0)から成るAMR-WB SIDフレーム(FT=9)です。 3番目のフレームは、いいえ_DATAフレームであり、少しの音声情報も運ばないで、それはペイロードにToCエントリーで表されます。 ペイロードにおける4番目のフレームが8.85キロビット毎秒モード(FT=1)でスピーチフレームである、それはh(176)にスピーチビットh(0)から成ります。
As shown below, the payload carries a mode request for the encoder on the receiver's side to change its future coding mode to AMR-WB 8.85 kbps (CMR=1). None of the frames are damaged at IP origin (Q=1). The encoded speech and SID bits, d(0) to d(131), g(0) to g(39), and h(0) to h(176), are arranged in the payload in descending sensitivity order according to [4]. (Note, no speech bits are present for the third frame.) Finally, seven zero bits are padded to the end to make the payload octet aligned.
以下に示すように、ペイロードは受信機の側の上のエンコーダが将来のコード化モードをAMR-WB8.85キロビット毎秒(CMR=1)に変えるというモード要求を運びます。 フレームのいずれもIPの起源(Q=1)で破損しません。 コード化されたスピーチとSIDビット(g(0)からgへのd(131)へのd(0)、(39)、およびh(176)へのh(0))は、[4]に応じて感度オーダーを滑降させる際にペイロードでアレンジされます。 (注意、どんなスピーチビットも3番目のフレームに存在していません。) 最終的に、7ゼロ・ビットが、ペイロード八重奏を並べさせるために終わりまで水増しされます。
Sjoberg, et al. Standards Track [Page 22] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[22ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(131)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|g(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g(39)|h(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h(176)|P|P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=1|1| フィート=0|1|1| フィート=9|1|1| フィート=15|1|0| フィート=1|1|d(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(131)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |g(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g(39)|h(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h(176)|P|P|P|P|P|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.5.3. Multi-Channel Payload Carrying Multiple Frames
4.3.5.3. 複数のフレームを運ぶマルチチャンネル有効搭載量
The following diagram shows a two-channel payload carrying 3 frame- blocks, i.e., the payload will contain 6 speech frames.
以下のダイヤグラムは、2チャンネルのペイロードが3つのフレームブロックを運ぶのを示します、すなわち、ペイロードは6個のスピーチフレームを含むでしょう。
In the payload, all speech frames contain the same mode 7.4 kbps (FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e., no specific mode is requested. The two channels are defined as left (L) and right (R) in that order. The encoded speech bits is designated dXY(0).. dXY(K-1), where X = block number, Y = channel, and K is the number of speech bits for that mode. Exemplifying this, for frame-block 1 of the left channel, the encoded bits are designated as d1L(0) to d1L(147).
ペイロードでは、すべてのスピーチフレームが、同じモード7.4キロビット毎秒(FT=4)を含んでいて、IPの起源で破損するというわけではありません。 CMRは15に用意ができています、すなわち、どんな特定のモードも要求されていません。 2個のチャンネルがそのオーダーで左の(L)と正しい(R)と定義されます。 コード化されたスピーチビットはdXY(0).. dXY(K-1)に指定されます。そこでは、X=街区番号、Y=チャンネル、およびKはそのモードのためのスピーチビットの数です。 左のチャンネルのフレームブロック1つのためにこれを例示して、コード化されたビットはd1L(0)としてd1L(147)に指定されます。
Sjoberg, et al. Standards Track [Page 23] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[23ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4|1|0|3R FT=4|1|d1L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1L(147)|d1R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1R(147)|d2L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d2L(147|d2R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d2R(147)|d3L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3L(147)|d3R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|1|1Lフィート=4|1|1|1Rフィート=4|1|1|2Lフィート=4|1|1|2Rフィート=4|1|1|3Lフィート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4|1|0|3Rフィート=4|1|d1L(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1L(147)|d1R(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1R(147)|d2L(0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |d2L(147|d2R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d2R(147)|d3L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3L(147)|d3R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3R(147)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sjoberg, et al. Standards Track [Page 24] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[24ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
4.4. Octet-Aligned Mode
4.4. 八重奏で並べられたモード
4.4.1. The Payload Header
4.4.1. 有効搭載量ヘッダー
In octet-aligned mode, the payload header consists of a 4-bit CMR, 4 reserved bits, and optionally, an 8-bit interleaving header, as shown below:
八重奏で並べられたモードで、ペイロードヘッダーは4ビットからCMR、予約された4ビットに、任意に成ります、8ビットのインターリービングヘッダー、以下に示すように:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+- - - - - - - - | CMR|R|R|R|R| 病気| ILP| +-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): same as defined in Section 4.3.1.
CMR(4ビット): セクション4.3.1で定義されるのと同じです。
R: is a reserved bit that MUST be set to zero. All R bits MUST be
ignored by the receiver.
R: 設定しなければならない予約されたビットはゼロですか? 受信機ですべてのRビットを無視しなければなりません。
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is
present only if interleaving is signalled out-of-band for the
session. ILL=L indicates to the receiver that the interleaving
length is L+1, in number of frame-blocks.
ILL(4ビット、符号のない整数): これはインターリービングがセッションのためにバンドの外で合図される場合にだけ存在しているOPTIONAL分野です。 ILL=Lは、インターリービングの長さがフレームブロックの数がL+1であることを受信機に示します。
ILP (4 bits, unsigned integer): This is an OPTIONAL field that is
present only if interleaving is signalled. ILP MUST take a value
between 0 and ILL, inclusive, indicating the interleaving index
for frame-blocks in this payload in the interleaving group. If
the value of ILP is found greater than ILL, the payload SHOULD be
discarded.
ILP(4ビット、符号のない整数): これはインターリービングが合図される場合にだけ存在しているOPTIONAL分野です。 ILP MUSTは0とILLの間に値を取ります、包括的です、インターリービンググループでインターリービングインデックスをこのペイロードでのフレームブロック示して。 ILPの値がILL、ペイロードSHOULDよりすばらしいのがわかるなら、捨てられてください。
ILL and ILP fields MUST be present in each packet in a session if interleaving is signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., NOT on a frame basis) in a multi-channel session.
インターリービングがセッションのために合図されるなら、ILLとILP分野はセッションにおける各パケットに存在していなければなりません。 マルチチャンネルセッションのときにフレームブロックベース(すなわち、フレームベースでないところの)にインターリービングを実行しなければなりません。
The following example illustrates the arrangement of speech frame- blocks in an interleaving group during an interleaving session. Here we assume ILL=L for the interleaving group that starts at speech frame-block n. We also assume that the first payload packet of the interleaving group is s, and the number of speech frame-blocks carried in each payload is N. Then we will have:
以下の例はインターリービングにおけるブロックがインターリービングセッションの間に分類するスピーチフレームのアレンジメントを例証します。 ここで、私たちはスピーチフレームブロックnで始まるインターリービンググループのためにILL=Lを仮定します。 また、私たちは、インターリービンググループの最初のペイロードパケットがsであると思います、そして、各ペイロードで運ばれたスピーチフレームブロックの数は私たちが望んでいるN.Thenが以下を持っているということです。
Sjoberg, et al. Standards Track [Page 25] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[25ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Payload s (the first packet of this interleaving group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
有効搭載量s(このインターリービンググループの最初のパケット): ILL=L、ILP=0、Carryフレームブロック: n、n+(L+1)、n+2*(L+1)…, n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleaving group):
ILL=L, ILP=1,
frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)
...
有効搭載量s+1(このインターリービンググループの2番目のパケット): ILL=L、ILP=1、フレームブロック: n+1、n+1+(L+1)、n+1+2*(L+1)…, n+1+(N-1)*(L+1)…
Payload s+L (the last packet of this interleaving group):
ILL=L, ILP=L,
frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)
有効搭載量s+L(このインターリービンググループの最後のパケット): ILL=L、ILP=L、フレームブロック: n+L、n+L+(L+1)、n+L+2*(L+1)…, n+L+(N-1)*(L+1)
The next interleaving group will start at frame-block n+N*(L+1).
次のインターリービンググループはフレームブロックn+N*(L+1)で始まるでしょう。
There will be no interleaving effect unless the number of frame- blocks per packet (N) is at least 2. Moreover, the number of frame- blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks.
インターリービング効果が全くパケット(N)あたりのフレームブロックの数が少なくとも2でないならないでしょう。 そのうえ、フレームブロックのペイロード(N)とILL MUST NOTの値あたりの数にインターリービンググループで変えてください。 言い換えれば、インターリービンググループにおけるすべてのペイロードが、同じILLを持たなければならなくて、同じ数のスピーチフレームブロックを含まなければなりません。
The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses media type parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
受信機がバンドで出ている手段による使用に合図したなら、ペイロードの送付者はインターリービングを適用するだけでよいです。 インターリービングが受信機で要件をバッファリングしながら増加するので、受信機はインターリービンググループでIに許されたフレームブロックの最大数を設定するのに「インターリービング=私」というメディア型引数を使用します。
When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleaving group is less or equal to I, that is, N*(L+1)<=I.
インターリービングを実行するとき、送付者が適切な数のペイロード(N)あたりのフレームブロックとILLを使用しなければならないので、インターリービンググループの結果として起こるサイズはすなわち、私、N*(L+1)<の以下か同輩=私です。
4.4.2. The Payload Table of Contents and Frame CRCs
4.4.2. 有効搭載量目次とフレームCRCs
The table of contents (ToC) in octet-aligned mode consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload and, optionally, a list of speech frame CRCs. That is, the ToC is as follows:
八重奏で並べられたモードによる目次(ToC)は各エントリーがペイロードで運ばれたスピーチフレームに対応するToCエントリーのリストと任意にスピーチフレームCRCsのリストから成ります。 すなわち、ToCは以下の通りです:
+---------------------+
| list of ToC entries |
+---------------------+
| list of frame CRCs | (optional)
- - - - - - - - - - -
+---------------------+ | ToCエントリーのリスト| +---------------------+ | フレームCRCsのリスト| (任意)です。 - - - - - - - - - - -
Note, for ToC entries with FT=14 or 15, there will be no
corresponding speech frame or frame CRC present in the payload.
FT=14か15があるToCエントリーによって、ペイロードの現在のどんな対応するスピーチフレームもフレームCRCもないことに注意してください。
Sjoberg, et al. Standards Track [Page 26] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[26ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with the following exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutively in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1.
同様に、ToCエントリーのリストが帯域幅効率的なモードのために中で説明されるように組織化される、4.3、.2、以下の例外で: インターリービングが時間内に使用されているとき、ToCでのフレームブロックはほとんど連続して置かれないでしょう。 代わりに、パケットでのフレームブロックの存在と注文が中で説明されたパターンに従う、4.4、.1
The following example shows the ToC of three consecutive packets, each carrying three frame-blocks, in an interleaved two-channel session. Here, the two channels are left (L) and right (R) with L coming before R, and the interleaving length is 3 (i.e., ILL=2). This results in the interleaving group size of 9 frame-blocks.
はさみ込まれた2チャンネルのセッションのときにそれぞれ3つのフレームブロックを運んで、以下の例は3つの連続したパケットのToCを示しています。 ここに、LがRに優先であっているので、2個のチャンネルが(L)と正しい(R)に残されます、そして、インターリービングの長さは3(すなわち、ILL=2)です。 これは9つのフレームブロックのインターリービンググループサイズをもたらします。
Packet #1 ---------
パケット#1---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 4 Block 7
病気の=2、ILP=0: +----+----+----+----+----+----+ | 1L| 1R| 4L| 4R| 7L| 7R| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレーム4つのブロック1ブロックブロック7
Packet #2 ---------
パケット#2---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8
病気の=2、ILP=1: +----+----+----+----+----+----+ | 2L| 2R| 5L| 5R| 8L| 8R| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレーム5つのブロック2ブロックブロック8
Packet #3 ---------
パケット#3---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 3 Block 6 Block 9
病気の=2、ILP=2: +----+----+----+----+----+----+ | 3L| 3R| 6L| 6R| 9L| 9R| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレーム6つのブロック3ブロックブロック9
Sjoberg, et al. Standards Track [Page 27] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[27ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
A ToC entry takes the following format in octet-aligned mode:
ToCエントリーは八重奏で並べられたモードによる以下の形式を取ります:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| フィート|Q|P|P| +-+-+-+-+-+-+-+-+
F (1 bit): see definition in Section 4.3.2.
F(1ビット): セクション4.3.2との定義を見てください。
FT (4 bits, unsigned integer): see definition in Section 4.3.2.
FT(4ビット、符号のない整数): セクション4.3.2との定義を見てください。
Q (1 bit): see definition in Section 4.3.2.
Q(1ビット): セクション4.3.2との定義を見てください。
P bits: padding bits, MUST be set to zero, and MUST be ignored on
reception.
Pビット: ビットを水増しして、ゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bits long and corresponds to a speech frame (NOT a frame- block) carried in the payload. Calculation and use of the CRC is specified in the next section.
CRCsのリストはOPTIONALです。 CRCの使用がセッションのためにバンドの外で合図される場合にだけ、それは存在しています。 存在しているとき、リストの各CRCは長さ8ビットであり、ペイロードで運ばれたスピーチフレーム(フレームブロックでない)に対応しています。 CRCの計算と使用は次のセクションで指定されます。
4.4.2.1. Use of Frame CRC for UED over IP
4.4.2.1. フレームCRCのIPの上のUEDの使用
The general concept of UED/UEP over IP is discussed in Section 3.6. This section provides more details on how to use the frame CRC in the octet-aligned payload header together with a partial transport layer checksum to achieve UED.
セクション3.6でIPの上のUED/UEPに関する一般概念について議論します。 このセクションはUEDを達成するのに部分的なトランスポート層チェックサムと共に八重奏で並べられたペイロードヘッダーでフレームCRCをどう使用するかに関するその他の詳細を提供します。
To achieve UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum.
UEDを達成するのに、1SHOULDがトランスポート層チェックサムを使用します。(例えば、ものはIP、トランスポート・プロトコル(例えば、UDP-Lite)、およびRTPヘッダーを保護するためにUDP-Liteで[19])を定義しました、ペイロードヘッダーとペイロードの目次と同様に。 使用されると、AMRかAMR-WBフレームでフレームCRCについてすべてのクラスAビットの上だけ計算しなければなりません。 AMRかAMR-WBフレームのクラスBとCビットはそうであるはずがありません。CRC計算とSHOULD NOTに含まれていて、輸送チェックサムで覆われてください。
Note, the number of class A bits for various coding modes in AMR
codec is specified as informative in [2] and is therefore copied
into Table 1 in Section 3.6 to make it normative for this payload
format. The number of class A bits for various coding modes in
AMR-WB codec is specified as normative in Table 2 in [4], and the
SID frame (FT=9) has 40 class A bits. These definitions of class
A bits MUST be used for this payload format.
注意、AMRコーデックの様々なコード化モードのためのクラスAビットの数は、[2]で有益であるとして指定されて、したがって、それをこのペイロード形式に規範的にするようにセクション3.6にTable1にコピーされます。 AMR-WBコーデックの様々なコード化モードのためのクラスAビットの数は[4]のTable2の標準として指定されます、そして、SIDフレーム(FT=9)には、40クラスAビットがあります。 このペイロード形式にクラスAビットのこれらの定義を使用しなければなりません。
Sjoberg, et al. Standards Track [Page 28] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[28ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded as defined by UDP-Lite [19].
トランスポート層チェックサムかリンクレイヤチェックサムが何か保護された(敏感な)部分の中の誤りを検出するなら、UDP-Lite[19]によって定義されるように完全なパケットが捨てられると思われます。
The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] more details.
ペイロードSHOULDの受信機は、CRCについて容認されたクラスAビットの上再計算して、容認されたペイロードヘッダーで見つけられた値に結果をたとえることによって、容認されたクラスAビットのデータ保全を調べます。 2がミスマッチ、SHALLが、受信機フレームのクラスAビットが破損したと考える受信機を評価して、Q旗からフレームを取り除かなければならないなら(すなわち、0にそれを設定してください)。 これで、フレームのFTが0歳であるなら次に、SPEECH_BADとしてフレームをマークするでしょう。7 AMRか0のために。AMR-WBのための8、またはフレームのFTがAMRのための8かAMR-WBのための9歳である、それの前のSID_BADがそうです。スピーチデコーダに通過されます。 [7] [6]とその他の詳細を見てください。
The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15):
以下の例は単独のチャンネルセッションからペイロードのためのCRCリストが3個のスピーチフレームを入れてあている八重奏で並べられたToCを示しています(FTsのいずれも仮定しないのは14か15と等しいです):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| フィート#1|Q|P|P|1| フィート#2|Q|P|P|0| フィート#3|Q|P|P| CRC#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC#2| CRC#3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the CRCs takes 8 bits
それぞれのCRCsは8ビット取ります。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
(MSB) (LSB)
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | c0| c1| c2| c3| c4| c5| c6| c7| +---+---+---+---+---+---+---+---+ (MSB)(LSB)
and is calculated by the cyclic generator polynomial,
そして、周期的なジェネレータ多項式によって計算されます。
C(x) = 1 + x^2 + x^3 + x^4 + x^8
C(x)は1+x^2+x^3+x^4+x^8と等しいです。
where ^ is the exponentiation operator.
^が指数演算子であるところ。
In binary form, the polynomial appears as follows: 101110001 (MSB..LSB).
二部形式では、多項式は以下の通りに見えます: 101110001 (MSB..LSB。)
The actual calculation of the CRC is made as follows: First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost (LSB) bit of the CRC register and the bit. The CRC
CRCの実際の計算を以下の通りにします: まず最初に、8ビットのCRCレジスタはゼロにリセットされます: 00000000. CRCが計算されるものとする各ビットにおいて、XOR操作をCRCレジスタの一番右の(LSB)ビットとビットの間します。 CRC
Sjoberg, et al. Standards Track [Page 29] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[29ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
register is then right-shifted one step (each bit's significance is reduced by one), inputting a "0" as the leftmost bit (MSB). If the result of the XOR operation mentioned above is a "1", then "10111000" is bit-wise XOR-ed into the CRC register. This operation is repeated for each bit that the CRC should cover. In this case, the first bit would be d(0) for the speech frame for which the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRCs.
レジスタは次に、まさしく移行しているワンステップ(各ビットの意味は1つ減少する)です、「一番左ビット(MSB)としての0インチ」を入力して。 前記のようにXOR操作の結果による「そして、「10111000」はCRCレジスタへの何1インチもビット的なXOR-エドである」なら。 CRCがそうするべきである各ビットのために繰り返されて、スピーチフレームへのCRCがそうするべきであるd(0)がカバーであったなら. この場合最初のビットをカバーしてください。この操作が最後のビットであるときに、(例えば、セクション3.6におけるTable1に従ったAMR5.9のためのd(54))がこのCRC計算に使用されたということである、CRCレジスタのコンテンツは単にCRCsのリストの対応する分野にコピーされるべきです。
Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm.
汎用CPUにおけるCRCの速い計算は、テーブル駆動のアルゴリズムを使用することで可能です。
4.4.3. Speech Data
4.4.3. スピーチデータ
In octet-aligned mode, speech data is carried in a similar way to that in the bandwidth-efficient mode as discussed in Section 4.3.3, with the following exceptions:
八重奏で並べられたモードで、スピーチデータはセクション4.3.3で議論するようにそれへの同様の方法で帯域幅効率的なモードで運ばれます、以下の例外で:
- The last octet of each speech frame MUST be padded with zero
bits at the end if all bits in the octet are not used. The
padding bits MUST be ignored on reception. In other words,
each speech frame MUST be octet-aligned.
- 八重奏におけるすべてのビットが使用されているというわけではないなら、終わりにゼロ・ビットでそれぞれのスピーチフレームの最後の八重奏を水増ししなければなりません。 レセプションで詰め物ビットを無視しなければなりません。 言い換えれば、それぞれのスピーチフレームは八重奏で並べなければなりません。
- When multiple speech frames are present in the speech data
(i.e., compound payload), the speech frames are arranged either
one whole frame after another as usual, or with the octets of
all frames interleaved together at the octet level, depending
on the media type parameters negotiated for the payload type.
Since the bits within each frame are ordered with the most
error-sensitive bits first, interleaving the octets collects
those sensitive bits from all frames to be nearer the beginning
of the packet. This is called "robust sorting order" which
allows the application of UED (such as UDP-Lite [19]) or UEP
(such as the ULP [22]) mechanisms to the payload data. The
details of assembling the payload are given in the next
section.
- 複数のスピーチフレームであるときに、ペイロードタイプのために交渉されたメディア型引数によって、スピーチデータ(すなわち、合成ペイロード)でのプレゼント、アレンジされたスピーチフレームはいつものようか、すべてのフレームの八重奏が八重奏レベルで一緒にはさみ込まれている別のものの後の1個の全体のフレームですか? 各フレームの中のビットが最初に最も多くの誤り敏感なビットで配置されるので、八重奏をはさみ込むと、それらの敏感なビットはパケットのより多くの始まり頃に、あるようにすべてのフレームから集まります。 これがUEDのアプリケーションを許容する「体力を要しているソーティング命令」と呼ばれる、(UDP-Lite[19])かUEP、(ペイロードデータへのULP[22])メカニズムなどのように。 ペイロードを組み立てることの詳細は次のセクションで明らかにされます。
The use of robust sorting order for a payload type MUST be agreed via out-of-band means. Section 8 specifies a media type parameter for this purpose.
ペイロードタイプの体力を要しているソーティング命令の使用はバンドで出ている手段で同意しなければなりません。 セクション8はこのためにメディア型引数を指定します。
Note, robust sorting order MUST only be performed on the frame level and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved payload types.
注意、体力を要しているソーティング命令は、フレーム・レベルに実行するだけでよくて、その結果、インターリービングから独立しています、セクション4.4.1で説明されるように。(インターリービングがフレームブロックレベルにあります)。 言い換えれば、非はさみ込まれたかはさみ込まれたペイロードタイプに体力を要しているソーティングを適用できます。
Sjoberg, et al. Standards Track [Page 30] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[30ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
4.4.4. Methods for Forming the Payload
4.4.4. 有効搭載量を形成するための方法
Two different packetization methods, namely, normal order and robust sorting order, exist for forming a payload in octet-aligned mode. In both cases, the payload header and table of contents are packed into the payload the same way; the difference is in the packing of the speech frames.
すなわち、通常の注文と体力を要しているソーティングは、2つの異なったpacketization方法が八重奏で並べられたモードでペイロードを形成するために存在するよう命令します。 どちらの場合も、同じようにペイロードヘッダーと目次はペイロードに詰め込まれます。 違いはスピーチフレームのパッキング中です。
The payload begins with the payload header of one octet, or two octets if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries. If frame CRCs are to be included, they follow the table of contents with one 8-bit CRC filling each octet. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no CRC present.
フレームインターリービングが始まるなら、ペイロードは1つの八重奏、または2つの八重奏のペイロードヘッダーと共に始まります。選択にされる。 1八重奏のToCエントリーのリストから成る目次はペイロードヘッダーのあとに続いています。 フレームCRCsが含まれるつもりであるなら、彼らは、1 8ビットのCRCと共に各八重奏をいっぱいにしながら、目次に従います。 与えられたフレームにFT=14か15があるToCエントリーがあると、どんな存在しているCRCもないことに注意してください。
The speech data follows the table of contents, or the CRCs if present. For packetization in the normal order, all of the octets comprising a speech frame are appended to the payload as a unit. The speech frames are packed in the same order as their corresponding ToC entries are arranged in the ToC list, with the exception that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame.
存在しているなら、スピーチデータは目次、またはCRCsに従います。 通常のオーダーにおけるpacketizationに関しては、スピーチフレームを包括する八重奏のすべてをペイロードに一体にして追加します。 彼らの対応するToCエントリーがToCリストに配置されるとき、スピーチフレームは同次で梱包されます、与えられたフレームがそこにFT=14か15があるToCエントリーを持っているならそのフレームへの現在のどんなデータ八重奏にもならない例外で。
For packetization in robust sorting order, the octets of all speech frames are interleaved together at the octet level. That is, the data portion of the payload begins with the first octet of the first frame, followed by the first octet of the second frame, then the first octet of the third frame, and so on. After the first octet of the last frame has been appended, the cycle repeats with the second octet of each frame. The process continues for as many octets as are present in the longest frame. If the frames are not all the same octet length, a shorter frame is skipped once all octets in it have been appended. The order of the frames in the cycle will be sequential if frame interleaving is not in use, or according to the interleave pattern specified in the payload header if frame interleaving is in use. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame, so it is skipped in the robust sorting cycle.
体力を要しているソーティング命令におけるpacketizationに関しては、すべてのスピーチフレームの八重奏は八重奏レベルで一緒にはさみ込まれます。 すなわち、ペイロードのデータ部は2番目のフレームの最初の八重奏、次に、3番目のフレームの最初の八重奏などがあとに続いた最初のフレームの最初の八重奏で始まります。 最後のフレームの最初の八重奏を追加した後に、サイクルはそれぞれのフレームの2番目の八重奏で繰り返されます。 過程は存在しているのと同じくらい多くの八重奏のために最も長いフレームで持続します。 いったんそれのすべての八重奏を追加して、フレームがちょうど同じ八重奏の長さでないなら、より短いフレームをスキップします。 使用中であるフレームインターリービングが使用中であるならペイロードヘッダーで指定されたインタリーブパターンによると、フレームインターリービングがないと、サイクルのフレームの注文は連続するでしょう。 それが強健なソーティングサイクルにスキップされるために与えられたフレームにFT=14か15があるToCエントリーがあると、そのフレームへの現在のどんなデータ八重奏もないことに注意してください。
The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload. Exactly how many octets need to be covered depends on the network and application. If CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP. The means for communicating the number of octets to be covered to other layers performing UED/UEP is beyond the scope of this specification.
UED、そして/または、UEPは分類されたペイロードの少なくともRTPヘッダー、ペイロードヘッダー、目次、およびクラスAビットを含むRECOMMENDEDです。 ちょうどいくつの八重奏が、覆われている必要であるかネットワークとアプリケーションに頼っています。 CRCsが使用されているなら、体力を要しているソーティング、RTPヘッダー、ペイロードヘッダー、およびToC SHOULDだけと共に、UED/UEPで覆われてください。 UED/UEPを実行する他の層に覆われているために八重奏の数を伝えるための手段はこの仕様の範囲を超えています。
Sjoberg, et al. Standards Track [Page 31] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[31ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
4.4.5. Payload Examples
4.4.5. 有効搭載量の例
4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames
4.4.5.1. 複数のフレームを運ぶ基本的な単独のチャンネル有効搭載量
The following diagram shows an octet aligned payload from a single channel payload type that carries two AMR frames of 7.95 kbps coding mode (FT=5). In the payload, a codec mode request is sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. No frame CRC, interleaving, or robust sorting is in use.
以下のダイヤグラムは、単独のチャンネルから7.95キロビット毎秒の2個のAMRフレームを運ぶペイロードタイプがモード(FT=5)をコード化するのを八重奏の並べられたペイロードに示します。 ペイロードでは、(CMR=6)をコーデックモード要求に送ります、AMR10.2キロビット毎秒コード化モードを使用するよう受信機の側のエンコーダに要求して。 フレームCRC、インターリービング、またはどんな体力を要しているソーティングも使用中ではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f1(152..158) |P| f2(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(8..15) | f2(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f2(152..158) |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6|R|R|R|R|1|フィート#1=5|Q|P|P|0|フィート#2=5|Q|P|P| f1(0 .7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(8 .15)| f1(16 .23)| .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f1(152 .158)|P| f2(0 .7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(8 .15)| f2(16 .23)| .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f2(152 .158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in the above example, the last octet in both speech frames is padded with one zero bit to make it octet-aligned.
上記の例の両方のスピーチフレームにおける最後の八重奏が1ゼロ・ビットで水増しされて、それを作るというメモは八重奏で並びました。
4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting
4.4.5.2. CRC、インターリービング、および体力を要しているソーティングがある2チャンネルの有効搭載量
This example shows an octet aligned payload from a two-channel payload type. Two frame-blocks, each containing two speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload.
この例は2チャンネルのペイロードタイプから八重奏の並べられたペイロードを示しています。 それぞれ7.95キロビット毎秒コード化モード(FT=5)の2個のスピーチフレームを含んでいて、2つのフレームブロックがこのペイロードで運ばれます。
The two channels are left (L) and right (R) with L coming before R. In the payload, a codec mode request is also sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode.
また、(CMR=6)がR.Inに送られるペイロード、コーデックモードが、要求する前にLが来ていて、2個のチャンネルが(L)と正しい(R)に残されます、AMR10.2キロビット毎秒コード化モードを使用するよう受信機の側のエンコーダに要求して。
Moreover, frame CRC, robust sorting, and frame-block interleaving are all enabled for the payload type. The interleaving length is 2 (ILL=1), and this payload is the first one in an interleaving group (ILP=0).
そのうえ、フレームCRC、体力を要しているソーティング、およびフレームブロックインターリービングはペイロードタイプのためにすべて有効にされます。 インターリービングの長さは2(ILL=1)です、そして、このペイロードはインターリービンググループ(ILP=0)で最初のものです。
Sjoberg, et al. Standards Track [Page 32] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[32ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
The first two frames in the payload are the L and R channel speech frames of frame-block #1, consisting of bits f1L(0..158) and f1R(0..158), respectively. The next two frames are the L and R channel frames of frame-block #3, consisting of bits f3L(0..158) and f3R(0..158), respectively, due to interleaving. For each of the four speech frames, a CRC is calculated as CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is robust sorted.
ペイロードの最初の2個のフレームが、フレームブロック#1のLとRチャンネルスピーチフレームです、ビットのf1L(0 .158)とf1R(0 .158)からそれぞれ成って。 隣の2個のフレームが、フレームブロック#3のLとRチャンネルフレームです、インターリービングのためビットのf3L(0 .158)とf3R(0 .158)からそれぞれ成って。 それぞれの4個のスピーチフレームに関しては、CRCはCRC1L(0 .7)、CRC1R(0 .7)、CRC3L(0 .7)、およびCRC3R(0 .7)としてそれぞれ計算されます。 最終的に、ペイロードは分類されていた状態で強健です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC3L | CRC3R | f1L(0..7) | f1R(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|f3L(152..158)|P|f3R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6|R|R|R|R| 病気の=1| ILP=0|1|フィート#1L=5|Q|P|P|1|フィート#1R=5|Q|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|フィート#3L=5|Q|P|P|0|フィート#3R=5|Q|P|P| CRC1L| CRC1R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC3L| CRC3R| f1L(0 .7)| f1R(0 .7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(0 .7)| f3R(0 .7)| f1L(8 .15)| f1R(8 .15)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(8 .15)| f3R(8 .15)| f1L(16 .23)| f1R(16 .23)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(144 .151)| f3R(144 .151)|f1L(152 .158)|P|f1R(152 .158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f3L(152 .158)|P|f3R(152 .158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in the above example, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned.
上記の例のすべての4個のスピーチフレームにおける最後の八重奏が1ゼロ・ビットで水増しされて、それを作るというメモは八重奏で並びました。
4.5. Implementation Considerations
4.5. 実現問題
An application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling used. For example, if an application uses SDP, all the SDP and media type parameters in this document MUST be understood. This requirement ensures that an implementation always can decide if it is capable or not of communicating.
このペイロード形式を実行するアプリケーションはシグナリングが使用したバンドのアウトですべてのペイロードパラメタを理解しなければなりません。 例えば、アプリケーションがSDPを使用するなら、本書ではすべてのSDPとメディア型引数を理解しなければなりません。 この要件は、実現が、いつもそれが交信できるかどうか決めることができるのを確実にします。
No operating mode of the payload format is mandatory to implement. The requirements of the application using the payload format should be used to determine what to implement. To achieve basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio
ペイロード形式のどんなオペレーティング・モードも、実行するために義務的ではありません。 ペイロード形式を使用するアプリケーションの要件は、何を実行したらよいかを決定するのに使用されるべきです。 基本的な相互運用性、実現を達成するために、SHOULDはただ一つのオーディオのために帯域幅効率的なものと同様に八重奏で並べられたモードを少なくとも実行します。
Sjoberg, et al. Standards Track [Page 33] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[33ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
channel. The other operating modes: interleaving, robust sorting, and frame-wise CRC (in both single and multi-channel) are OPTIONAL to implement.
精神を集中してください。 他のオペレーティング・モード: インターリービング、体力を要しているソーティング、およびフレーム的なCRC(シングルとマルチチャンネルの両方の)は道具へのOPTIONALです。
The mode-change-period, mode-change-capability, and mode-change- neighbor parameters are intended for signaling with GSM endpoints. When interoperability with GSM is desired, encoders SHOULD only perform codec mode changes to neighboring modes and in integer multiples of 40 ms (two frame-blocks), but decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block. The encoder may arbitrarily select the initial phase (odd or even frame- block) where codec mode changes are performed, but then SHOULD stick to that phase as far as possible. However, in rare cases, handovers or other events (e.g., call forwarding) may change this phase and may also cause mode changes to non-neighboring modes. The decoder SHALL therefore be prepared to accept changes also in the other phase and to other modes. Section 8 specifies the usage of the parameters mode-change-period and mode-change-capability to indicate the desired behavior in applications.
モード変化の期間、モード変化能力、およびモード変化隣人パラメタは、GSM終点で合図するために意図します。 GSMがある相互運用性が望まれているとき、エンコーダSHOULDは隣接しているモードと40ms(2つのフレームブロック)の整数倍数におけるコーデックモード変更を実行するだけですが、デコーダSHOULDはいつでもコーデックモード変更を受け入れます、すなわち、あらゆるフレームブロックに。 エンコーダは任意に、コーデックモード変更が実行されますが、SHOULDがそのフェーズにできるだけ執着する初期位相(変であるか同等のフレームブロック)を選択するかもしれません。 しかしながら、身柄の引き渡しか他の出来事(例えば、自動転送)が、たまには、このフェーズを変えて、また、非隣接しているモードへのモード変更を引き起こすかもしれません。 デコーダSHALL、したがって、また、他のフェーズと他のモードに変化を受け入れるように用意してください。 セクション8はパラメタモード変化の期間とアプリケーションにおける望まれた行動を示すモード変化能力の用法を指定します。
See 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks. In gateway scenarios, encoders can be requested through the "mode-set" parameter to use a limited mode-set that is supported by the link beyond the gateway. Further, to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information.
GSMと3GPP UMTSネットワークで都合のよいAMRのための3GPP TS26.103[28]と操作のためのAMR-WB構成を見てください。 ゲートウェイシナリオでは、「モードセット」パラメタを通してエンコーダがゲートウェイを超えたリンクによって支えられる限られたモードセットを使用するよう要求できます。 さらに、そのリンクの上に混雑を避けるために、エンコーダSHOULDはセッションのための初期のコーデックモードを低いモードに制限します、レート制御情報で少なくとも1つのフレームブロックを受け取るまで。
4.5.1. Decoding Validation
4.5.1. 合法化を解読します。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information for the payload type and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality.
ペイロードヘッダーフィールドで見つけられたペイロードタイプと値のための情報に基づく計算されたペイロード長がする受信機掘り出し物が容認されたパケットのサイズに合っていないなら容認されたペイロードパケットを処理するとき、受信機SHOULDはパケットを捨てます。 これは長さの分野に誤りを持っているパケットを解読するとスピーチ品質が厳しく下げられるかもしれないからです。
Sjoberg, et al. Standards Track [Page 34] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[34ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
5. AMR and AMR-WB Storage Format
5. AMRとAMR-WB格納形式
The storage format is used for storing AMR or AMR-WB speech frames in a file or as an email attachment. Multiple channel content is supported.
格納形式は、ファイルかメール付属としてAMRかAMR-WBスピーチフレームを格納するのに使用されます。 複数のチャンネル内容が支持されます。
In general, an AMR or AMR-WB file has the following structure:
一般に、AMRかAMR-WBファイルには、以下の構造があります:
+------------------+ | Header | +------------------+ | Speech frame 1 | +------------------+ : ... : +------------------+ | Speech frame n | +------------------+
+------------------+ | ヘッダー| +------------------+ | スピーチフレーム1| +------------------+ : ... : +------------------+ | スピーチフレームn| +------------------+
Note, to preserve interoperability with already deployed implementations, single-channel content uses a file header format different from that of multi-channel content.
単独のチャンネル内容がマルチチャンネル内容のものと異なったファイルヘッダー形式を使用することに既に配備された実現がある保護区相互運用性に注意してください。
There also exists another storage format for AMR and AMR-WB that is suitable for applications with more advanced demands on the storage format, like random access or synchronization with video. This format is the 3GPP-specified ISO-based multimedia file format 3GP [31]. Its media type is specified by RFC 3839 [32].
また、AMRとAMR-WBのための別の、より高度な要求が格納形式にある状態でビデオによってランダムアクセスや同期のようにアプリケーションに適した格納形式は存在しています。 この形式は3GPPによって指定されたISOベースのマルチメディアファイル形式3GP[31]です。 メディアタイプはRFC3839[32]によって指定されます。
5.1. Single-Channel Header
5.1. 単独のチャンネルヘッダー
A single-channel AMR or AMR-WB file header contains only a magic number. Different magic numbers are defined to distinguish AMR from AMR-WB.
単独のチャンネルAMRかAMR-WBファイルヘッダーがマジックナンバーだけを含んでいます。 異なったマジックナンバーは、AMR-WBとAMRを区別するために定義されます。
The magic number for single-channel AMR files MUST consist of ASCII character string:
単独のチャンネルAMRファイルのためのマジックナンバーはASCII文字列から成らなければなりません:
"#!AMR\n"
(or 0x2321414d520a in hexadecimal).
「#!AMR\n。」(または、16進の0x2321414d520a)
The magic number for single-channel AMR-WB files MUST consist of ASCII character string:
単独のチャンネルAMR-WBファイルのためのマジックナンバーはASCII文字列から成らなければなりません:
"#!AMR-WB\n"
(or 0x2321414d522d57420a in hexadecimal).
「#!AMR-WB\n。」(または、16進の0x2321414d522d57420a)
Sjoberg, et al. Standards Track [Page 35] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[35ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Note, the "\n" is an important part of the magic numbers and MUST be included in the comparison, since, otherwise, the single-channel magic numbers above will become indistinguishable from those of the multi-channel files defined in the next section.
「注意、」 \n」をマジックナンバーの重要な部分であり、比較に含まなければなりません、さもなければ、上の単独のチャンネルマジックナンバーが次のセクションで定義されたマルチチャンネルファイルのものから区別がつかなくなるので。
5.2. Multi-Channel Header
5.2. マルチチャンネルヘッダー
The multi-channel header consists of a magic number followed by a 32-bit channel description field, giving the multi-channel header the following structure:
マルチチャンネルヘッダーは32ビットのチャンネル記述分野があとに続いたマジックナンバーから成ります、以下の構造をマルチチャンネルヘッダーに与えて:
+------------------+ | magic number | +------------------+ | chan-desc field | +------------------+
+------------------+ | マジックナンバー| +------------------+ | chan-desc分野| +------------------+
The magic number for multi-channel AMR files MUST consist of the ASCII character string:
マルチチャンネルAMRファイルのためのマジックナンバーはASCII文字列から成らなければなりません:
"#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal).
「#!AMR_MC1.0\n。」(または、16進の0x2321414d525F4D43312E300a)
The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string:
マルチチャンネルAMR-WBファイルのためのマジックナンバーはASCII文字列から成らなければなりません:
"#!AMR-WB_MC1.0\n"
(or 0x2321414d522d57425F4D43312E300a in hexadecimal).
「#!AMR-WB_MC1.0\n。」(または、16進の0x2321414d522d57425F4D43312E300a)
The version number in the magic numbers refers to the version of the file format.
マジックナンバーにおけるバージョン番号はファイル形式のバージョンを示します。
The 32 bit channel description field is defined as:
32ビットのチャンネル記述分野は以下と定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されたビット| チェン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits: MUST be set to 0 when written, and a reader MUST
ignore them.
予約されたビット: 書かれると0に設定しなければならなくて、読者はそれらを無視しなければなりません。
CHAN (4 bits, unsigned integer): Indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12].
チェン(4ビット、符号のない整数): この格納ファイルに含まれた音声チャンネルの数を示します。 [12]でセクション4.1でフレームブロックの中のチャンネルの有効値と注文を指定します。
Sjoberg, et al. Standards Track [Page 36] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[36ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
5.3. Speech Frames
5.3. スピーチフレーム
After the file header, speech frame-blocks consecutive in time are stored in the file. Each frame-block contains a number of octet- aligned speech frames equal to the number of channels, and stored in increasing order, starting with channel 1.
ファイルヘッダーの後に、時間内に連続したスピーチフレームブロックはファイルに格納されます。 それぞれのフレームブロックはチャンネルの数と等しくて、増加に格納されたフレームが注文する多くの八重奏の並べられたスピーチを含んでいます、チャンネル1から始めて。
Each stored speech frame starts with a one-octet frame header with the following format:
それぞれが1八重奏のフレームヘッダーと共に以下の形式でスピーチフレーム始めを格納しました:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| フィート|Q|P|P| +-+-+-+-+-+-+-+-+
The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0, and MUST be ignored.
同様に、FT野原とQビットはセクション4.3.2で定義づけられます。 Pビットをそっと歩いていて、0に設定しなければならなくて、無視しなければなりません。
Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment.
この1個の八重奏ヘッダーに続いて、来てください、4.4で.3に定義されるスピーチビット 八重奏整列を達成するのに必要であるなら、それぞれのフレームの最後の八重奏はゼロで水増しされます。
The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format.
以下の例は、5.9キロビット毎秒におけるAMRフレームが格納形式でモード(118スピーチビットがある)をコード化するのを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| フィート=2|Q|P|P| | +-+-+-+-+-+-+-+-+ + | | + フレームブロックn、チャンネルk+のためのスピーチビット| | + +-+-+ | |P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Non-received speech frames or frame-blocks between SID updates during non-speech periods MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media.
どんな_DATAフレームとしてもSIDの間のフレームかフレームブロックが非スピーチの期間、アップデートする非受け取られていているスピーチを格納してはいけません。(フレームは15をタイプします、[2]と[4])で定義されるように。 オリジナルのメディアとの同期を保つために_DATAフレームかどんなSPEECH_LOST(タイプ14を罪に陥れてください、単にAMR-WBに、利用可能である)としても完全なフレームブロックにフレームかトランスミッションで失われたフレームブロックを格納してはいけません。
Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format.
安らぎ雑音はAMR SID(FT=8)(すなわち、AMRのためのフレームタイプ9、10、および11)SHALL NOT以外のタイプにAMRファイル形式で使用されていた状態で縁どられます。
Sjoberg, et al. Standards Track [Page 37] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[37ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
6. Congestion Control
6. 輻輳制御
The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP as well. However, the multi-rate capability of AMR and AMR-WB speech coding may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different coding mode.
RTPデータを輸送するための一般的な輻輳制御問題はまた、RTPの上のAMRかAMR-WBスピーチに適用されます。 しかしながら、AMRとAMR-WB音声符号化のマルチレート能力は異なったコード化モードを選択することによって帯域幅要求を調整できるので混雑を制御するのに他のペイロード形式より利点を提供するかもしれません。
Another parameter that may impact the bandwidth demand for AMR and AMR-WB is the number of frame-blocks that are encapsulated in each RTP payload. Packing more frame-blocks in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay.
AMRとAMR-WBの帯域幅需要に影響を与えるかもしれない別のパラメタはそれぞれのRTPペイロードで要約されるフレームブロックの数です。 それぞれのRTPペイロードでの、より多くのフレームブロックを梱包すると、IP/UDP/RTPヘッダーから送られたパケットの数としたがって、オーバーヘッドを下げることができます、増加する遅れを犠牲にして。
If forward error correction (FEC) is used to combat packet loss, the amount of redundancy added by FEC will need to be regulated so that the use of FEC itself does not cause a congestion problem.
前進型誤信号訂正(FEC)がパケット損失と戦うのに使用されると、FECによって加えられた冗長の量が、規制される必要があるので、FEC自身の使用は混雑問題を引き起こしません。
It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified but should be suitable for real- time flows, possibly "TCP Friendly Rate Control" [21].
このペイロード形式雇用混雑を使用するAMRかAMR-WBアプリケーションが制御されるのは、RECOMMENDEDです。 輻輳制御のための実際のメカニズムは、指定されませんが、本当の時間流れ(ことによると「TCPの好意的な速度制御」[21])に適しているべきです。
7. Security Considerations
7. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26].
この仕様に基づき定義されたペイロード書式を使用するRTPパケットは[8]とどんな中古のプロフィールでも議論した総合証券問題を受けることがあります、AVP[12]やSAVP[26]のように。
As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and the payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist.
この形式がコード化されたスピーチを輸送するとき、主な安全保障問題はスピーチ自体の秘密性、認証、および保全を含んでいます。 ペイロード形式自体には、どんな内蔵のセキュリティーメカニズムもありません。SRTP[26]などの外部のメカニズムは、この機能性に使用される必要があります。 このメモに従って、RTPとペイロードにセキュリティを供給する適切な手段が異なるかもしれないことに注意してください。 それはアプリケーション、輸送、および使われたシグナリングプロトコルに依存しています。 したがって、適当であるなら、SRTP[26]の使用法はRECOMMENDEDですが、ただ一つのメカニズムは十分ではありません。 使用されるかもしれない他の知られているメカニズムは、IPsec[33]とTLS[34]です(TCPの上のRTP)が、また、他の代替手段は存在するかもしれません。
This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing, and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data.
このペイロード形式は、パケット処理のために受信機サイド計算量で少しの重要な非の一様性も示さないで、その結果、病理学的なデータの領収書のためサービスの否定の脅威を引き起こしそうにはありません。
Sjoberg, et al. Standards Track [Page 38] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[38ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
7.1. Confidentiality
7.1. 秘密性
To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted. There is less of a need to encrypt the payload header or the table of contents due to a) that they only carry information about the requested speech mode, frame type, and frame quality, and b) that this information could be useful to some third party, e.g., quality monitoring.
コード化されたAMRかAMR-WBスピーチの秘密性を達成するために、すべてのスピーチデータ・ビットが、コード化される必要があるでしょう。 この情報が要求されたスピーチモード、フレームタイプ、フレーム品質、およびb)の情報であるかもしれませんが、彼らが運ぶだけであるa)のためペイロードヘッダーか目次をコード化する必要性の以下が第三者、例えば、上質のモニターの役に立った状態であります。
The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation.
終点だけでAMRとAMR-WBペイロードのpacketizationとunpacketizationをします。 したがって、暗号化はパケットカプセル化の後に実行されるべきです、そして、復号化はパケット被膜剥離術の前に実行されるべきです。
Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver.
暗号化はインターリービングに影響するかもしれません。 明確に、キーの変化はインターリービンググループの間の境界に起こるはずです。 両方の終点のその境界でそれをしないと、どんな受信機のためにも完全なインターリービンググループの間、スピーチ品質を下げるでしょう。
The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted.
暗号化メカニズムはエラー修正メカニズムの丈夫さに影響を与えるかもしれません。 SRTP[26]のセクション9.5でこれについて議論します。 これから、体力を要しているソーティングに基づくUED/UEPはペイロードデータがコード化されているとき、適用するのが難しいかもしれません。
7.2. Authentication and Integrity
7.2. 認証と保全
To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms because any bit errors will cause the integrity check to fail.
送付者を認証して、トランジットでRTPパケットの保全を保護するために、外部のメカニズムは使用されなければなりません。 以前述べられるように、SRTP[26]が一般的な相互運用性に使用されるのは、RECOMMENDEDです。 UED/UEPの使用は誤りが保全チェックがどんなビット失敗されるのでもいくつかの保全保護メカニズムに結合するのが難しいかもしれないことに注意してください。
Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired.
中央の男性攻撃者にいじられるデータはスピーチ品質を下げるか、または難解なコミュニケーションを作り出すことができた誤ったdepacketization/解読をもたらすかもしれません。 CMR分野をいじると、望まれているのと異なったスピーチ品質はもたらされるかもしれません。
8. Payload Format Parameters
8. 有効搭載量形式パラメタ
This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14].
このセクションはAMRとAMR-WBペイロード形式に関するオプション機能を選択するのに使用されるかもしれないパラメタを定義します。 パラメタはここでAMRとAMR-WBスピーチコーデックのためのメディアタイプ登録証明書の一部と定義されます。 登録証明書はRFC4855[15]とメディア登録規則[14]に従い終わっています。
Sjoberg, et al. Standards Track [Page 39] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[39ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use media types or SDP.
また、Session記述プロトコル(SDP)[11]へのパラメタに関するマッピングをSDPを使用するそれらのアプリケーションに提供します。 同等なパラメタは使用のためのほかの場所でメディアタイプかSDPを使用しない制御プロトコルで定義されるかもしれません。
Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type.
2は登録証明書が作られているメディアタイプ、AMRのためのもの、およびAMR-WBのための1つを切り離します、それらがそれら自身のメディアタイプが区別しなければならない異なったencodingsであるので。
Data formats are specified for both real-time transport in RTP and for storage type applications such as email attachments.
データ形式はRTPのともにリアルタイムの輸送とメール付属などの格納タイプアプリケーションに指定されます。
8.1. AMR Media Type Registration
8.1. AMRメディアは登録をタイプします。
The media type for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
メディアは(AMR)コーデックがAMRが一般に、広く使用されたスピーチコーデックであるのでIETF木から割り当てられるAdaptive Multi-レートVoIPとメッセージングアプリケーションのためにタイプされます。 このメディアタイプ登録は格納されたファイルでRTPを通したリアルタイムの転送と非リアルタイムの転送の両方を覆っています。
Note, any unspecified parameter MUST be ignored by the receiver.
受信機で注意、どんな不特定のパラメタも無視しなければなりません。
Media Type name: audio
メディアTypeは以下を命名します。 オーディオ
Media subtype name: AMR
メディア「副-タイプ」は以下を命名します。 AMR
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
These parameters apply to RTP transfer only.
これらのパラメタはRTP転送だけに適用されます。
octet-align: Permissible values are 0 and 1. If 1, octet-aligned
operation SHALL be used. If 0 or if not present,
bandwidth-efficient operation is employed.
八重奏で並んでください: 許容値は、0と1です。 1、八重奏で並べられた操作SHALLは使用されています。 0、またはまして、現在の、そして、帯域幅効率的な操作が採用しているなら。
mode-set: Restricts the active codec mode set to a subset of all
modes, for example, to be able to support transport
channels such as GSM networks in gateway use cases.
Possible values are a comma separated list of modes from
the set: 0,...,7 (see Table 1a [2]). The SID frame type
8 and NO_DATA (frame type 15) are never included in the
mode set, but can always be used. If mode-set is
specified, it MUST be abided, and frames encoded with
modes outside of the subset MUST NOT be sent in any RTP
payload or used in codec mode requests. If not present,
all codec modes are allowed for the payload type.
モードセット: 例えば、中のゲートウェイ使用がケースに入れるGSMネットワークなどの輸送チャンネルを支えることができるように活動的なコーデックモードセットをすべてのモードの部分集合に制限します。 可能な値はセットからのモードのコンマの切り離されたリストです: 0,...7 (テーブルの1a[2])を見てください。 SIDフレームタイプ8といいえ_DATA(フレームタイプ15)をモードセットに決して含まれていませんが、いつも使用できます。 モードセットが指定されるなら、それをabidedしなければならなくて、モードが部分集合の外にある状態でコード化されたフレームを、どんなRTPペイロードにも送られてはいけないか、コーデックモード要求で使用してはいけません。 プレゼントでないなら、すべてのコーデックモードがペイロードタイプのために許容されています。
Sjoberg, et al. Standards Track [Page 40] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[40ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
mode-change-period: Specifies a number of frame-blocks, N (1 or
2), that is the frame-block period at which codec mode
changes are allowed for the sender. The initial phase of
the interval is arbitrary, but changes must be separated
by a period of N frame-blocks, i.e., a value of 2
allows the sender to change mode every second frame-
block. The value of N SHALL be either 1 or 2. If this
parameter is not present, mode changes are allowed at
any time during the session, i.e., N=1.
モード変化の期間: 多くのフレームブロック、N(1か2)、すなわち、コーデックモード変更が送付者のために許容されているフレームブロックの期間を指定します。 Nフレームブロックの期間までに変化を切り離さなければなりません、そして、間隔の初期位相は任意ですが、すなわち、2の値は変化モードへの2番目のフレームブロック毎を送付者に許します。 N SHALLの値はそうです。1か2。 このパラメタが存在していないなら、モード変更はいつでも、すなわち、セッション、N=1の間、許容されています。
mode-change-capability: Specifies if the client is capable to
transmit with a restricted mode change period. The
parameter may take value of 1 or 2. A value of 1
indicates that the client is not capable of restricting
the mode change period to 2, and that the codec mode may
be changed at any point. A value of 2 indicates that the
client has the capability to restrict the mode change
period to 2, and thus that the client can correctly
interoperate with a receiver requiring a mode-change-
period=2. If this parameter is not present, the mode-
change restriction capability is not supported, i.e.
mode-change-capability=1. To be able to interoperate
fully with gateways to circuit switched networks (for
example, GSM networks), transmissions with restricted
mode changes (mode-change-capability=2) are required.
Thus, clients RECOMMENDED to have the capability to
support transmission according to
mode-change-capability=2.
モード変化能力: クライアントが制限されたモード変更の期間で伝わることができるかどうか指定します。 パラメタは1か2の値を取るかもしれません。 1の値は、クライアントがモード変更の期間を2に制限できないで、コーデックモードが任意な点で変えられるかもしれないのを示します。 2の値は、クライアントにはモード変更の期間を2に制限する能力があって、その結果、受信機がモード変化期間=2を必要とすることでクライアントが正しく共同利用できるのを示します。 このパラメタが存在していないなら、モード変化制限能力は支持されないで、すなわち、モード変化能力は=1です。 サーキット交換網(例えば、GSMネットワーク)へのゲートウェイで完全に共同利用できるように、制限されたモード変更(モード変化能力=2)に伴うトランスミッションが必要です。 その結果、モード変化能力=2に従ってトランスミッションを支持する能力を持つクライアントRECOMMENDED。
mode-change-neighbor: Permissible values are 0 and 1. If 1, the
sender SHOULD only perform mode changes to the
neighboring modes in the active codec mode set.
モード変化隣人: 許容値は、0と1です。 1であるなら、送付者SHOULDは活動的なコーデックモードセットで隣接しているモードへのモード変更を実行するだけです。
Neighboring modes are the ones closest in bit rate to
the current mode, either the next higher or next lower
rate. If 0 or if not present, change between any two
modes in the active codec mode set is allowed.
モードを近所付き合いさせて、ものが次の現在のモードへのビット伝送速度、より高いかまたは次の低料金における最も近くにありますか? 0かまして、プレゼントであるなら、活動的なコーデックモードセットにおけるどんな2つのモードの間の変化は許容されています。
maxptime: The maximum amount of media which can be encapsulated
in a payload packet, expressed as time in milliseconds.
The time is calculated as the sum of the time that the
media present in the packet represents. The time SHOULD
be an integer multiple of the frame size. If this
parameter is not present, the sender MAY encapsulate any
number of speech frames into one RTP packet.
maxptime: 時間としてミリセカンドで言い表されたペイロードパケットで要約できる最大の量のメディア。 時間はパケットでのメディアプレゼントが表す現代の合計として計算されます。 フレームの整数倍数がサイズであったならSHOULDを調節してください。 このパラメタが存在していないなら、送付者は1つのRTPパケットにいろいろなスピーチフレームを要約するかもしれません。
Sjoberg, et al. Standards Track [Page 41] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[41ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be
included in the payload. If 0 or not present, CRCs
SHALL NOT be used. If crc=1, this also implies
automatically that octet-aligned operation SHALL be used
for the session.
crc: 許容値は、0と1です。 1であるなら、含まれていて、ペイロードでCRCs SHALLを縁どってください。 プレゼント、CRCs SHALLではなく、0であるなら、使用されないでください。 また、crc=1であるなら、これは、八重奏で並べられた操作SHALLがセッションに使用されるのを自動的に含意します。
robust-sorting: Permissible values are 0 and 1. If 1, the
payload SHALL employ robust payload sorting. If 0 or if
not present, simple payload sorting SHALL be used. If
robust-sorting=1, this also implies automatically that
octet-aligned operation SHALL be used for the session.
体力を要しているソーティング: 許容値は、0と1です。 1であるなら、ペイロードSHALLは体力を要しているペイロードソーティングを使います。 0、またはまして、現在の、そして、簡単なペイロードソーティングSHALLであるなら、使用されてください。 また、体力を要しているソーティング=1であるなら、これは、八重奏で並べられた操作SHALLがセッションに使用されるのを自動的に含意します。
interleaving: Indicates that frame-block level interleaving SHALL
be used for the session, and its value defines the
maximum number of frame-blocks allowed in an
interleaving group (see Section 4.4.1). If this
parameter is not present, interleaving SHALL NOT be
used. The presence of this parameter also implies
automatically that octet-aligned operation SHALL be
used.
インターリービング: 表示、フレームブロックレベルインターリービングSHALLがセッション、およびその値に使用されるのがインターリービンググループで許されたフレームブロックの最大数を定義します(セクション4.4.1を見てください)。 このパラメタが存在していないなら、SHALL NOTをはさみ込んで、使用されてください。 また、このパラメタの存在は、八重奏で並べられた操作SHALLが使用されるのを自動的に含意します。
ptime: see RFC 4566 [11].
ptime: RFC4566[11]を見てください。
channels: The number of audio channels. The possible values
(1-6) and their respective channel order is specified in
Section 4.1 in [12]. If omitted, it has the default
value of 1.
チャンネル: 音声チャンネルの数。 [12]でセクション4.1で有り得るのを指定してください値(1-6)と彼らのそれぞれのチャンネルが、命令する。 省略されるなら、それには、1のデフォルト値があります。
max-red: The maximum duration in milliseconds that elapses between
the primary (first) transmission of a frame and any
redundant transmission that the sender will use. This
parameter allows a receiver to have a bounded delay when
redundancy is used. Allowed values are between 0 (no
redundancy will be used) and 65535. If the parameter is
omitted, no limitation on the use of redundancy is
present.
最大赤: フレームの第一(最初に)のトランスミッションと送付者が使用するどんな余分なトランスミッションの間でも経過するミリセカンドで表現される最大の持続時間。 冗長が使用されているとき、このパラメタで、受信機は境界がある遅れを持つことができます。 許容値が0(冗長は全く使用されない)と65535の間あります。 パラメタが省略されるなら、冗長の使用のどんな制限も存在していません。
Encoding considerations:
The Audio data is binary data, and must be encoded for non-
binary transport; the Base64 encoding is suitable for email.
When used in RTP context the data is framed as defined in [14].
問題をコード化します: Audioデータを2進のデータであり、非バイナリーの輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。 RTP文脈で使用されると、データは[14]で定義されるように縁どられます。
Security considerations:
See Section 7 of RFC 4867.
セキュリティ問題: RFC4867のセクション7を見てください。
Public specification:
RFC 4867
3GPP TS 26.090, 26.092, 26.093, 26.101
公共の仕様: RFC4867 3GPP t26.090、26.092、26.093、26.101
Sjoberg, et al. Standards Track [Page 42] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[42ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Applications that use this media type:
This media type is used in numerous applications needing
transport or storage of encoded voice. Some examples include;
Voice over IP, streaming media, voice messaging, and voice
recording on digital cameras.
このメディアタイプを使用するアプリケーション: このメディアタイプは、コード化された声の輸送か格納を必要としながら、頻繁なアプリケーションで使用されます。 例が含むいくつか。 ボイス・オーバー IP、ストリーミング・メディアはデジタルカメラの上にメッセージング、および声の録音を声に出します。
Additional information:
The following applies to stored-file transfer methods:
追加情報: 以下は格納されたファイル転送方法に適用されます:
Magic numbers:
single-channel:
ASCII character string "#!AMR\n"
(or 0x2321414d520a in hexadecimal)
multi-channel:
ASCII character string "#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal)
File extensions: amr, AMR
Macintosh file type code: "amr " (fourth character is space)
マジックナンバー: 単独のチャンネル: 「ASCII文字列」#!AMR\n」(または、16進の0x2321414d520a)マルチチャンネル: 「ASCII文字列」#!AMR_MC1.0\n」(または、16進の0x2321414d525F4D43312E300a)ファイル拡張子: amr、AMRマッキントッシュファイルの種類コード: "amr"(4番目のキャラクタはスペースです)
AMR speech frames may also be stored in the file format "3GP"
defined in 3GPP TS 26.244 [31], which is identified using the
media types "audio/3GPP" or "video/3GPP" as registered by RFC
3839 [32].
また、AMRスピーチフレームは"3GP"が登録されるとしてのRFC3839[32]によるメディアタイプの「オーディオ/3GPP」か「ビデオ/3GPP」を使用することで特定される3GPP t26.244[31]で定義したファイル形式に格納されるかもしれません。
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
詳細のために連絡する人とEメールアドレス: マグヌス Westerlund <magnus.westerlund@ericsson.com 、gt;、アリLakaniemi、lt;、 ari.lakaniemi@nokia.com 、gt。
Intended usage: COMMON.
This media type is widely used in streaming, VoIP, and messaging
applications on many types of devices.
意図している用法: 一般的。 このメディアタイプはストリーミング、VoIP、およびメッセージングアプリケーションで多くのタイプの装置で広く使用されます。
Restrictions on usage:
When this media type is used in the context of transfer over
RTP, the RTP payload format specified in Section 4 SHALL be
used. In all other contexts, the file format defined in Section
5 SHALL be used.
用法における制限: このメディアタイプが文脈で使用されたら、RTP、セクション4 SHALLで指定されたRTPペイロード形式での転送に、使用されてください。 他の文脈、形式がセクション5 SHALLで定義したすべてのファイルでは、使用されてください。
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
以下を書いてください。 マグヌス Westerlund <magnus.westerlund@ericsson.com 、gt;、アリLakaniemi、lt;、 ari.lakaniemi@nokia.com 、gt。
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
Sjoberg, et al. Standards Track [Page 43] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[43ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
8.2. AMR-WB Media Type Registration
8.2. AMR-WBメディアは登録をタイプします。
The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real- time transfers via stored files.
メディアは、AMR-WBが一般に、広く使用されたスピーチコーデックであるので、コーデックがIETF木から割り当てられるAdaptive Multi-レートWideband(AMR-WB)のためにタイプされます。VoIPとメッセージングアプリケーション。 そして、このメディアタイプ登録がRTPを通してともにリアルタイムの転送を覆っている、非、-リアルタイムは格納されたファイルで移されます。
Note, any unspecified parameter MUST be ignored by the receiver.
受信機で注意、どんな不特定のパラメタも無視しなければなりません。
Media Type name: audio
メディアTypeは以下を命名します。 オーディオ
Media subtype name: AMR-WB
メディア「副-タイプ」は以下を命名します。 AMR-Wb
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
These parameters apply to RTP transfer only.
これらのパラメタはRTP転送だけに適用されます。
octet-align: Permissible values are 0 and 1. If 1, octet-aligned
operation SHALL be used. If 0 or if not present,
bandwidth-efficient operation is employed.
八重奏で並んでください: 許容値は、0と1です。 1、八重奏で並べられた操作SHALLは使用されています。 0、またはまして、現在の、そして、帯域幅効率的な操作が採用しているなら。
mode-set: Restricts the active codec mode set to a subset of all
modes, for example, to be able to support transport
channels such as GSM networks in gateway use cases.
Possible values are a comma-separated list of modes from
the set: 0,...,8 (see Table 1a [4]). The SID frame type
9, SPEECH_LOST (frame type 14), and NO_DATA (frame type
15) are never included in the mode set, but can always
be used. If mode-set is specified, it MUST be abided,
and frames encoded with modes outside of the subset MUST
NOT be sent in any RTP payload or used in codec mode
requests. If not present, all codec modes are allowed
for the payload type.
モードセット: 例えば、中のゲートウェイ使用がケースに入れるGSMネットワークなどの輸送チャンネルを支えることができるように活動的なコーデックモードセットをすべてのモードの部分集合に制限します。 可能な値はセットからのモードのコンマで切り離されたリストです: 0,...8 (テーブルの1a[4])を見てください。 SIDフレームタイプ9、SPEECH_LOST(フレームタイプ14)、およびいいえ_DATA(フレームタイプ15)をモードセットに決して含まれていませんが、いつも使用できます。 モードセットが指定されるなら、それをabidedしなければならなくて、モードが部分集合の外にある状態でコード化されたフレームを、どんなRTPペイロードにも送られてはいけないか、コーデックモード要求で使用してはいけません。 プレゼントでないなら、すべてのコーデックモードがペイロードタイプのために許容されています。
mode-change-period: Specifies a number of frame-blocks, N (1 or
2), that is the frame-block period at which codec mode
changes are allowed for the sender. The initial phase of
the interval is arbitrary, but changes must be separated
by multiples of N frame-blocks, i.e., a value of 2
allows the sender to change mode every second frame-
block. The value of N SHALL be either 1 or 2. If this
parameter is not present, mode changes are allowed at
Any time during the session, i.e., N=1.
モード変化の期間: 多くのフレームブロック、N(1か2)、すなわち、コーデックモード変更が送付者のために許容されているフレームブロックの期間を指定します。 Nフレームブロックの倍数で変化を切り離さなければなりません、そして、間隔の初期位相は任意ですが、すなわち、2の値は変化モードへの2番目のフレームブロック毎を送付者に許します。 N SHALLの値はそうです。1か2。 このパラメタが存在していないなら、モード変更はすなわち、セッション、N=1の間のAny時に許容されています。
Sjoberg, et al. Standards Track [Page 44] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[44ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
mode-change-capability: Specifies if the client is capable to
transmit with a restricted mode change period. The
parameter may take value of 1 or 2. A value of 1
indicates that the client is not capable of restricting
the mode change period to 2, and that the codec mode may
be changed at any point. A value of 2 indicates that the
client has the capability to restrict the mode change
period to 2, and thus that the client can correctly
interoperate with a receiver requiring a mode-change-
period=2. If this parameter is not present, the mode-
change restriction capability is not supported, i.e.
mode-change-capability=1. To be able to interoperate
fully with gateways to circuit switched networks (for
example, GSM networks), transmissions with restricted
mode changes (mode-change-capability=2) are required.
Thus, clients are RECOMMENDED to have the capability to
support transmission according to
mode-change-capability=2.
モード変化能力: クライアントが制限されたモード変更の期間で伝わることができるかどうか指定します。 パラメタは1か2の値を取るかもしれません。 1の値は、クライアントがモード変更の期間を2に制限できないで、コーデックモードが任意な点で変えられるかもしれないのを示します。 2の値は、クライアントにはモード変更の期間を2に制限する能力があって、その結果、受信機がモード変化期間=2を必要とすることでクライアントが正しく共同利用できるのを示します。 このパラメタが存在していないなら、モード変化制限能力は支持されないで、すなわち、モード変化能力は=1です。 サーキット交換網(例えば、GSMネットワーク)へのゲートウェイで完全に共同利用できるように、制限されたモード変更(モード変化能力=2)に伴うトランスミッションが必要です。 したがって、クライアントはモード変化能力=2に従ってトランスミッションを支持する能力を持つRECOMMENDEDです。
mode-change-neighbor: Permissible values are 0 and 1. If 1, the
sender SHOULD only perform mode changes to the
neighboring modes in the active codec mode set.
Neighboring modes are the ones closest in bit rate to
the current mode, either the next higher or next lower
rate. If 0 or if not present, change between any two
modes in the active codec mode set is allowed.
モード変化隣人: 許容値は、0と1です。 1であるなら、送付者SHOULDは活動的なコーデックモードセットで隣接しているモードへのモード変更を実行するだけです。 モードを近所付き合いさせて、ものが次の現在のモードへのビット伝送速度、より高いかまたは次の低料金における最も近くにありますか? 0かまして、プレゼントであるなら、活動的なコーデックモードセットにおけるどんな2つのモードの間の変化は許容されています。
maxptime: The maximum amount of media which can be encapsulated
in a payload packet, expressed as time in milliseconds.
The time is calculated as the sum of the time that the
media present in the packet represents. The time SHOULD
be an integer multiple of the frame size. If this
parameter is not present, the sender MAY encapsulate any
number of speech frames into one RTP packet.
maxptime: 時間としてミリセカンドで言い表されたペイロードパケットで要約できる最大の量のメディア。 時間はパケットでのメディアプレゼントが表す現代の合計として計算されます。 フレームの整数倍数がサイズであったならSHOULDを調節してください。 このパラメタが存在していないなら、送付者は1つのRTPパケットにいろいろなスピーチフレームを要約するかもしれません。
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be
included in the payload. If 0 or not present, CRCs
SHALL NOT be used. If crc=1, this also implies
automatically that octet-aligned operation SHALL be used
for the session.
crc: 許容値は、0と1です。 1であるなら、含まれていて、ペイロードでCRCs SHALLを縁どってください。 プレゼント、CRCs SHALLではなく、0であるなら、使用されないでください。 また、crc=1であるなら、これは、八重奏で並べられた操作SHALLがセッションに使用されるのを自動的に含意します。
robust-sorting: Permissible values are 0 and 1. If 1, the
payload SHALL employ robust payload sorting. If 0 or if
not present, simple payload sorting SHALL be used. If
robust-sorting=1, this also implies automatically that
octet-aligned operation SHALL be used for the session.
体力を要しているソーティング: 許容値は、0と1です。 1であるなら、ペイロードSHALLは体力を要しているペイロードソーティングを使います。 0、またはまして、現在の、そして、簡単なペイロードソーティングSHALLであるなら、使用されてください。 また、体力を要しているソーティング=1であるなら、これは、八重奏で並べられた操作SHALLがセッションに使用されるのを自動的に含意します。
Sjoberg, et al. Standards Track [Page 45] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[45ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
interleaving: Indicates that frame-block level interleaving SHALL
be used for the session, and its value defines the
maximum number of frame-blocks allowed in an
interleaving group (see Section 4.4.1). If this
parameter is not present, interleaving SHALL NOT be
used. The presence of this parameter also implies
automatically that octet-aligned operation SHALL be
used.
インターリービング: 表示、フレームブロックレベルインターリービングSHALLがセッション、およびその値に使用されるのがインターリービンググループで許されたフレームブロックの最大数を定義します(セクション4.4.1を見てください)。 このパラメタが存在していないなら、SHALL NOTをはさみ込んで、使用されてください。 また、このパラメタの存在は、八重奏で並べられた操作SHALLが使用されるのを自動的に含意します。
ptime: see RFC 2327 [11].
ptime: RFC2327[11]を見てください。
channels: The number of audio channels. The possible values
(1-6) and their respective channel order is specified in
Section 4.1 in [12]. If omitted, it has the default
value of 1.
チャンネル: 音声チャンネルの数。 [12]でセクション4.1で有り得るのを指定してください値(1-6)と彼らのそれぞれのチャンネルが、命令する。 省略されるなら、それには、1のデフォルト値があります。
max-red: The maximum duration in milliseconds that elapses between
the primary (first) transmission of a frame and any
redundant transmission that the sender will use. This
parameter allows a receiver to have a bounded delay when
redundancy is used. Allowed values are between 0 (no
redundancy will be used) and 65535. If the parameter is
omitted, no limitation on the use of redundancy is
present.
最大赤: フレームの第一(最初に)のトランスミッションと送付者が使用するどんな余分なトランスミッションの間でも経過するミリセカンドで表現される最大の持続時間。 冗長が使用されているとき、このパラメタで、受信機は境界がある遅れを持つことができます。 許容値が0(冗長は全く使用されない)と65535の間あります。 パラメタが省略されるなら、冗長の使用のどんな制限も存在していません。
Encoding considerations:
The Audio data is binary data, and must be encoded for non-
binary transport; the Base64 encoding is suitable for email.
When used in RTP context the data is framed as defined in [14].
問題をコード化します: Audioデータを2進のデータであり、非バイナリーの輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。 RTP文脈で使用されると、データは[14]で定義されるように縁どられます。
Security considerations:
See Section 7 of RFC 4867.
セキュリティ問題: RFC4867のセクション7を見てください。
Public specification:
RFC 4867
3GPP TS 26.190, 26.192, 26.193, 26.201
公共の仕様: RFC4867 3GPP t26.190、26.192、26.193、26.201
Applications that use this media type:
This media type is used in numerous applications needing
transport or storage of encoded voice. Some examples include;
Voice over IP, streaming media, voice messaging, and voice
recording on digital cameras.
このメディアタイプを使用するアプリケーション: このメディアタイプは、コード化された声の輸送か格納を必要としながら、頻繁なアプリケーションで使用されます。 例が含むいくつか。 ボイス・オーバー IP、ストリーミング・メディアはデジタルカメラの上にメッセージング、および声の録音を声に出します。
Sjoberg, et al. Standards Track [Page 46] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[46ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Additional information:
The following applies to stored-file transfer methods:
追加情報: 以下は格納されたファイル転送方法に適用されます:
Magic numbers:
single-channel:
ASCII character string "#!AMR-WB\n"
(or 0x2321414d522d57420a in hexadecimal)
multi-channel:
ASCII character string "#!AMR-WB_MC1.0\n"
(or 0x2321414d522d57425F4D43312E300a in hexadecimal)
File extensions: awb, AWB
Macintosh file type code: amrw
Object identifier or OID: none
マジックナンバー: 単独のチャンネル: 「ASCII文字列」#!AMR-WB\n」(または、16進の0x2321414d522d57420a)マルチチャンネル: 「ASCII文字列」#!AMR-WB_MC1.0\n」(または、16進の0x2321414d522d57425F4D43312E300a)ファイル拡張子: awb、AWBマッキントッシュファイルの種類コード: amrw Object識別子かOID: なし
AMR-WB speech frames may also be stored in the file format "3GP"
defined in 3GPP TS 26.244 [31] and identified using the media
type "audio/3GPP" or "video/3GPP" as registered by RFC 3839
[32].
また、AMR-WBスピーチフレームは、登録されるとしてのRFC3839[32]によるメディアのタイプ「オーディオ/3GPP」か「ビデオ/3GPP」を使用することで"3GP"が3GPP t26.244[31]で定義したファイル形式に格納されて、特定されるかもしれません。
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
詳細のために連絡する人とEメールアドレス: マグヌス Westerlund <magnus.westerlund@ericsson.com 、gt;、アリLakaniemi、lt;、 ari.lakaniemi@nokia.com 、gt。
Intended usage: COMMON.
This media type is widely used in streaming, VoIP, and messaging
applications on many types of devices.
意図している用法: 一般的。 このメディアタイプはストリーミング、VoIP、およびメッセージングアプリケーションで多くのタイプの装置で広く使用されます。
Restrictions on usage:
When this media type is used in the context of transfer over
RTP, the RTP payload format specified in Section 4 SHALL be
used. In all other contexts, the file format defined in Section
5 SHALL be used.
用法における制限: このメディアタイプが文脈で使用されたら、RTP、セクション4 SHALLで指定されたRTPペイロード形式での転送に、使用されてください。 他の文脈、形式がセクション5 SHALLで定義したすべてのファイルでは、使用されてください。
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
以下を書いてください。 マグヌス Westerlund <magnus.westerlund@ericsson.com 、gt;、アリLakaniemi、lt;、 ari.lakaniemi@nokia.com 、gt。
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
8.3. Mapping Media Type Parameters into SDP
8.3. メディア型引数をSDPに写像します。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows:
仕様が特定のマッピングを持っているメディアタイプで運ばれた情報はSession記述プロトコル(SDP)で[11]をさばきます。([11]は、RTPセッションについて説明するのに一般的に使用されます)。 SDPがAMRを使うセッションかAMR-WBコーデックを指定するのに使用されるとき、マッピングは以下の通りです:
Sjoberg, et al. Standards Track [Page 47] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[47ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
- The media type ("audio") goes in SDP "m=" as the media name.
- メディアタイプ(「オーディオ」)はメディア名としてSDP「m=」に行きます。
- The media subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000 for AMR and 16000 for AMR-WB, and the encoding parameters
(number of channels) MUST either be explicitly set to N or
omitted, implying a default value of 1. The values of N that
are allowed are specified in Section 4.1 in [12].
- メディア「副-タイプ」(ペイロード形式名)はコード化名としてSDP"a=rtpmap"に入ります。 "a=rtpmap"のRTPクロックレートがAMR-WBのためのAMRと16000のための8000でなければならなく、コード化パラメタ(チャンネルの数)を明らかにNに設定されなければならないか、または省略しなければなりません、1のデフォルト値を含意して。 許容されているNの値は[12]でセクション4.1で指定されます。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.
- パラメタの"ptime"と"maxptime"はそれぞれSDP"a=ptime"と"a=maxptime"属性に入ります。
- Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the media type parameter string as a
semicolon-separated list of parameter=value pairs.
- パラメタ=価値のセミコロンで切り離されたリストが対にされるので直接メディア型引数ストリングからそれらをコピーすることによって、どんな残っているパラメタもSDP"a=fmtp"属性に入ります。
8.3.1. Offer-Answer Model Considerations
8.3.1. 申し出答えモデル問題
The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of AMR or AMR-WB payload in RTP:
RTPでAMRかAMR-WBペイロードの使用を交渉するのにSDP Offer-答え手順を用いるとき、以下の問題は適用されます:
- Each combination of the RTP payload transport format
configuration parameters (octet-align, crc, robust-sorting,
interleaving, and channels) is unique in its bit-pattern and
not compatible with any other combination. When creating an
offer in an application desiring to use the more advanced
features (crc, robust-sorting, interleaving, or more than one
channel), the offerer is RECOMMENDED to also offer a payload
type containing only the octet-aligned or bandwidth-efficient
configuration with a single channel. If multiple
configurations are of interest to the application, they may all
be offered; however, care should be taken not to offer too many
payload types. An SDP answerer MUST include, in the SDP answer
for a payload type, the following parameters unmodified from
the SDP offer (unless it removes the payload type): "octet-
align"; "crc"; "robust-sorting"; "interleaving"; and
"channels". The SDP offerer and answerer MUST generate AMR or
AMR-WB packets as described by these parameters.
- RTPペイロード輸送形式設定パラメータ(八重奏で並んでいて、crcの、そして、体力を要しているソーティングのインターリービング、およびチャンネル)のそれぞれの組み合わせは、ビット・パターンでユニークであって、いかなる他の組み合わせとも互換性がありません。 より高度な特徴(crc、体力を要しているソーティング、インターリービング、または1個以上のチャンネル)を使用するのが望ましくしながらアプリケーションで申し出を作成するとき、申出人はまた、単独のチャンネルで八重奏で並べられたか帯域幅効率的な構成だけを含むペイロードタイプを提供するRECOMMENDEDです。 複数の構成がアプリケーションに興味があるなら、それらをすべて提供するかもしれません。 しかしながら、あまりに多くのペイロードタイプを提供しないように注意するべきです。 SDP answererはペイロードタイプのためのSDP答えにSDP申し出によって変更されていない以下のパラメタを含まなければなりません(ペイロードタイプを外さない場合): 「八重奏並んでください」。 "crc"。 「体力を要しているソーティング」。 「インターリービング」。 そして、「チャンネル。」 SDP申出人とanswererはこれらのパラメタによって説明されるようにAMRかAMR-WBパケットを発生させなければなりません。
- The "mode-set" parameter can be used to restrict the set of
active AMR/AMR-WB modes used in a session. This functionality
is primarily intended for gateways to access networks such as
GSM or 3GPP UMTS, where the access network may be capable of
supporting only a subset of AMR/AMR-WB modes. The 3GPP
preferred codec configurations are defined in 3GPP TS 26.103
[25], and it is RECOMMENDED that other networks also needing to
restrict the mode set follow the preferred codec configurations
defined in 3GPP for greatest interoperability.
- セッションのときに使用されたアクティブなAMR/AMR-WBモードのセットを制限するのに「モードセット」パラメタを使用できます。 この機能性はゲートウェイがアクセスネットワークがAMR/AMR-WBモードの部分集合しかサポートできないかもしれないGSMや3GPP UMTSなどのネットワークにアクセスすることを主として意図します。 3GPPの都合のよいコーデック構成は3GPP TS26.103[25]で定義されます、そして、また、モードセットを制限する必要がある他のネットワークが最もすばらしい相互運用性のために3GPPで定義された都合のよいコーデック構成に続くのは、RECOMMENDEDです。
Sjoberg, et al. Standards Track [Page 48] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[48ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
The parameter is bi-directional, i.e., the restricted 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
SHALL return the mode-set unmodified or reject the payload
type. However, the answerer is free to choose a mode-set in
the answer only if no mode-set was supplied in the offer for a
unicast two-peer session. The mode-set in the answer is
binding both for offerer and answerer. Thus, an offerer
supporting all modes and subsets SHOULD NOT include the mode-
set parameter. For any other offerer it is RECOMMENDED to
include each mode-set it can support as a separate payload type
within the offer. For multicast sessions, the answerer SHALL
only participate in the session if it supports the offered
mode-set. Thus, it is RECOMMENDED that any offer for a
multicast session include only the mode-set it will require the
answerers to support, and that the mode-set be likely to be
supported by all participants.
パラメタが双方向である、すなわち、制限されたセットは宣言実体によってともに受け取られて、送られるのにメディアに申し込みます。 申し出でモードセットを供給したなら、answerer SHALLは変更されていなくモードセットを返すか、またはペイロードタイプを拒絶します。 しかしながら、ユニキャストの2同輩のセッションのために申し出でモードセットを全く供給しなかった場合にだけ、answererは自由に答えにおけるモードセットを選ぶことができます。 申出人とanswererにおいて、答えにおけるモードセットは拘束力があります。 したがって、すべてのモードを支持している申出人と部分集合SHOULD NOTはモードセットパラメタを含んでいます。 いかなる他の申出人にとっても、それはそれが別々のペイロードタイプとして申し出の中で支えることができるそれぞれのモードセットを含むRECOMMENDEDです。 マルチキャストセッションのために、提供されたモードセットを支える場合にだけ、answerer SHALLはセッションのときに参加します。 したがって、マルチキャストセッションのためのどんな申し出も支持するのがanswerersを必要とするモードセットだけを含んで、モードセットがすべての関係者によって支持されそうであるのは、RECOMMENDEDです。
- The parameters "mode-change-period" and "mode-change-
capability" are intended to be used in sessions with gateways,
for example, when interoperating with GSM networks. Both
parameters are declarative and are combined to allow a session
participant to determine if the payload type can be supported.
The mode-change-period will indicate what the offerer or
answerer requires of data it receives, while the mode-change-
capability indicates its transmission capabilities.
- ゲートウェイとのセッションのときにGSMネットワークと共に共同利用するとき、例えば、「モード変化の期間」というパラメタと「能力をモードで変えること」が使用されることを意図します。 両方のパラメタは、叙述的であり、セッション関係者が、ペイロードタイプを支持できるかどうかと決心しているのを許容するために結合されます。 モード変化の期間は申出人かanswererが必要とするそれが受け取るデータのことを示すでしょう、モード変化能力がトランスミッション能力を示しますが。
A mode-change-period=2 in the offer indicates a requirement on
the answerer to send with a mode-change period of 2, i.e.,
support mode-change-capability=2. If the answerer requires
mode-change-period=2, it SHALL only include it in the answer if
the offerer either has indicated support with mode-change-
capability=2 or has indicated mode-change-period=2; otherwise,
the payload type SHALL be rejected. An offerer that supports
mode-change-capability=2 SHALL include the parameter in all
offers to ensure the greatest possible interoperability, unless
it includes mode-change-period=2 in the offer. The mode-
change-capability SHOULD be included in answers. It is then
indicating the answerer's capability to transmit with that
mode-change-period for the provided payload format
configuration. The information is useful in future
re-negotiation of the payload formats.
申し出におけるモード変化期間=2はすなわち、2のモード変更の期間、サポートモード変化能力=2と共に発信するというanswererに関する要件を示します。 -answererがモードを必要とするなら、変化期間は2と等しいです、それ。申出人が、モード変化能力=2でサポートを示したか、またはモード変化期間が2と等しいのを示した場合にだけ、SHALLは答えにそれを含んでいます。 さもなければ、ペイロードはSHALLをタイプします。拒絶されます。 2モード変化能力を支持する申出人=SHALLは可能な限りすばらしい相互運用性を確実にするというすべての申し出にパラメタを含んでいます、申し出にモード変化期間=2を含んでいない場合。 モード変化能力SHOULD、答えで含められてください。 そして、それは提供されたペイロード形式構成のためにそのモード変化の期間で伝わるanswererの能力を示しています。 情報はペイロード形式の今後の再交渉で役に立ちます。
- The parameter "mode-change-neighbor" is a recommendation to
restrict the switching of codec modes to its neighbor and
SHOULD be followed. It is intended to be used in gateway
scenarios (for example, to GSM networks) where the support of
- 「モード変化隣人」というパラメタはコーデックモードの切り換えをその隣人とSHOULDに制限するという推薦です。続かれています。 ゲートウェイシナリオ(例えばGSMネットワークに)で使用されるのが意図している、どこ、サポート
Sjoberg, et al. Standards Track [Page 49] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[49ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
this parameter and the operations it implies improves
interoperability.
このパラメタとそれが含意する操作は相互運用性を改良します。
"mode-change-neighbor" is a declarative parameter. By
including the parameter, the offerer or answerer indicates that
it desires to receive streams with "mode-change-neighbor"
restrictions.
「モード変化隣人」は叙述的なパラメタです。 パラメタを含んでいることによって、申出人かanswererが、「モード変化隣人」制限で流れを受けることを望んでいるのを示します。
- In most cases, the parameters "maxptime" and "ptime" will not
affect interoperability; however, the setting of the parameters
can affect the performance of the application. The SDP offer-
answer handling of the "ptime" parameter is described in RFC
3264 [13]. The "maxptime" parameter MUST be handled in the
same way.
- 多くの場合、パラメタの"maxptime"と"ptime"は相互運用性に影響しないでしょう。 しかしながら、パラメタの設定はアプリケーションの性能に影響できます。 RFC3264[13]では、説明されますSDP申し出が、"ptime"パラメタの取り扱いに答える。 同様に、"maxptime"パラメタを扱わなければなりません。
- The parameter "max-red" is a stream property parameter. For
send-only or send-recv unicast media streams, the parameter
declares the limitation on redundancy that the stream sender
will use. For recvonly streams, it indicates the desired value
for the stream sent to the receiver. The answerer MAY change
the value, but is RECOMMENDED to use the same limitation as the
offer declares. In the case of multicast, the offerer MAY
declare a limitation; this SHALL be answered using the same
value. A media sender using this payload format is RECOMMENDED
to always include the "max-red" parameter. This information is
likely to simplify the media stream handling in the receiver.
This is especially true if no redundancy will be used, in which
case "max-red" is set to 0. As this parameter was not defined
originally, some senders will not declare this parameter even
if it will limit or not send redundancy at all.
- 「最大赤」というパラメタは流れの特性のパラメタです。 または、発信、-単に、recvを発信させているユニキャストメディアの流れであり、パラメタは流れの送付者が使用する冗長で制限を宣言します。 recvonlyの流れのために、それは、流れのための目標値が受信機に発信したのを示します。answererは値を変えるかもしれませんが、申し出が宣言するようにRECOMMENDEDは同じ制限を使用することになっていますか? マルチキャストの場合では、申出人は制限を宣言するかもしれません。 このSHALL、同じ値を使用することで、答えられてください。 このペイロード形式を使用しているメディア送付者はいつも「最大赤」パラメタを含むRECOMMENDEDです。 この情報は受信機で扱われるメディアの流れを簡素化しそうです。冗長が全く使用されないならこれが特に本当である、その場合、「最大赤」は0に設定されます。 このパラメタが元々定義されなかったように、何人かの送付者は、制限してもこのパラメタを宣言しないか、または冗長を全く送らないでしょう。
- Any unknown parameter in an offer SHALL be removed in the
answer.
- どんな未知のパラメタ、も申し出SHALLでは、答えで取り除いてください。
8.3.2. Usage of Declarative SDP
8.3.2. 叙述的なSDPの使用法
In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows:
叙述的な用法で、RTSP[29]かSAP[30]、パラメタSHALLのSDPのように、以下の通り解釈されてください:
- The payload format configuration parameters (octet-align, crc,
robust-sorting, interleaving, and channels) are all declarative,
and a participant MUST use the configuration(s) that is provided
for the session. More than one configuration may be provided if
necessary by declaring multiple RTP payload types; however, the
number of types should be kept small.
- ペイロード形式設定パラメータ(八重奏で並んでいて、crcの、そして、体力を要しているソーティングのインターリービング、およびチャンネル)はすべて叙述的です、そして、関係者はセッションのために提供される構成を使用しなければなりません。 必要なら、複数のRTPペイロードがタイプされると宣言することによって、1つ以上の構成を提供するかもしれません。 しかしながら、タイプの数は小さく保たれるべきです。
Sjoberg, et al. Standards Track [Page 50] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[50ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
- Any restriction of the AMR or AMR-WB encoder mode-switching and
mode usage through the "mode-set", and "mode-change-period" MUST
be followed by all participants of the session. The restriction
indicated by "mode-change-neighbor" SHOULD be followed. Please
note that such restrictions may be necessary if gateways to other
transport systems like GSM participate in the session. Failure to
consider such restrictions may result in failure for a peer behind
such a gateway to correctly receive all or parts of the session.
Also, if different restrictions are needed by different peers in
the same session (unless a common subset of the restrictions
exists), some peer will not be able to participate. Note that the
usage of mode-change-capability is meaningless when no negotiation
exists, and can thus be excluded in any declarations.
- AMRかAMR-WBエンコーダモード切り換えとモード用法のどんな「モードセット」、およびセッションのすべての関係者が後をつけなければならない「モード変化の期間」を通した制限。 制限は、「モード変化隣人」SHOULDで続かれるように示しました。 GSMのような他の輸送システムへのゲートウェイがセッションのときに関与するなら、そのような制限が必要であるかもしれません。 そのような制限を考えない場合、そのようなゲートウェイの後ろの同輩が正しくすべてを受け取らないことかセッションの部品をもたらすかもしれません。 また、異なった制限が同じセッションのときに異なった同輩によって必要とされると(制限の一般的な部分集合が存在していない場合)、同輩は参加できないでしょう。 モード変化能力の用法は交渉が全く存在しないとき、無意味であり、その結果、どんな宣言でも除くことができることに注意してください。
- Any "maxptime" and "ptime" values should be selected with care to
ensure that the session's participants can achieve reasonable
performance.
- どんな"maxptime"と"ptime"値も、セッションの関係者が妥当な性能を達成できるのを保証するのが慎重に選択されるべきです。
- The usage of "max-red" puts a global upper limit on the usage of
redundancy that needs to be followed by all that understand the
parameter. However, due to the late addition of this parameter,
it may be ignored by some implementations.
- 「最大赤」の用法はパラメタを理解しているすべてがあとに続く必要がある冗長の用法にグローバルな上限を置きます。 しかしながら、このパラメタの遅い添加のため、それはいくつかの実現で無視されるかもしれません。
8.3.3. Examples
8.3.3. 例
Some example SDP session descriptions utilizing AMR and AMR-WB
encodings follow. In these examples, long a=fmtp lines are folded to
meet the column width constraints of this document; the backslash
("\") at the end of a line and the carriage return that follows it
should be ignored.
AMRとAMR-WB encodingsを利用するいくつかの例のSDPセッション記述が続きます。 これらの例では、長いa=fmtp線はこのドキュメントのカラム幅規制を満たすために折り重ねられます。 線の端とそれに続く復帰におけるバックスラッシュ(「\」)は無視されるべきです。
In an example of the usage of AMR in a possible GSM gateway-to- gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets and removes the payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at the same time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]:
可能なGSMゲートウェイからゲートウェイへのシナリオのAMRの使用法に関する例では、申出人は、3つの異なったモードセットを支えることができて、モード変化の期間がモード変化隣人制限と組み合わせた2である必要があります。 もう片方のゲートウェイは、これらの2つのモードセットしか支持できないで、答えでペイロードタイプ97を外します。 提供GSMゲートウェイが同時に活動的な単モードセットを支えるだけであるなら、すると考えるべきである、[13]のセクション10.2で説明されたN選択手順のうちの1:
Sjoberg, et al. Standards Track [Page 51] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[51ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Offer:
以下を提供してください。
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
m=オーディオの49120RTP/AVP97 98 99a=rtpmap: 97 AMR/8000/1a=fmtp: 97 モードに設定された=0、2、5、7。 モード変化期間=2。 モード能力=を変えている2円。 1モード変化隣人=a=rtpmap: 98 AMR/8000/1a=fmtp: 98 モードに設定された=0、2、3、6。 モード変化期間=2。 モード能力=を変えている2円。 1モード変化隣人=a=rtpmap: 99 AMR/8000/1a=fmtp: 99 モードに設定された=0、2、3、4。 モード変化期間=2。 モード能力=を変えている2円。 1モード変化隣人=a=maxptime: 20
Answer:
以下に答えてください。
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \<
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
m=オーディオの49120RTP/AVP98 99a=rtpmap: 98 AMR/8000/1a=fmtp: 98 モードに設定された=0、2、3、6。 モード変化期間=2。 \<モード変化能力=2。 1モード変化隣人=a=rtpmap: 99 AMR/8000/1a=fmtp: 99 モードに設定された=0、2、3、4。 モード変化期間=2。 モード能力=を変えている2円。 1モード変化隣人=a=maxptime: 20
The following example shows the usage of AMR between a non-GSM endpoint and a GSM gateway. The non-GSM offerer requires no restrictions of the mode-change-period or mode-change-neighbor, but must signal its mode-change-capability in the offer and abide by those restrictions in the answer.
以下の例は非GSM終点とGSMゲートウェイの間にAMRの使用法を示しています。 非GSM申出人はモード変化の期間かモード変化隣人の制限を全く必要としません、申し出でモード変化能力を示唆して、答えでそれらの制限を守らなければならないのを除いて。
Offer:
以下を提供してください。
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2
a=maxptime:20
2m=オーディオの49120RTP/AVP97a=rtpmap: 97AMR/8000/1a=fmtp: 97モード変化能力=a=maxptime: 20
Answer:
以下に答えてください。
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
m=オーディオの49120RTP/AVP97a=rtpmap: 97 AMR/8000/1a=fmtp: 97 モードに設定された=0、2、4、7。 モード変化期間=2。 モード能力=を変えている2円。 1モード変化隣人=a=maxptime: 20
Sjoberg, et al. Standards Track [Page 52] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[52ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98):
UEPが中古の(99)であるかもしれない可能なVoIPシナリオと後退宣言(98)におけるAMR-WBの使用法に関する例:
m=audio 49120 RTP/AVP 99 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
オーディオの49120RTP/AVP99 98m=a=rtpmap: 98 AMR-WB/16000a=fmtp: 98 =1を八重奏で並べてください。 2モード変化能力=a=rtpmap: 99 AMR-WB/16000a=fmtp: 99 =1を八重奏で並べてください。 crc=1。 モード変化能力=2
Example of usage of AMR-WB in a possible streaming scenario (two channel stereo):
可能なストリーミングのシナリオ(2チャンネルステレオ)のAMR-WBの使用法に関する例:
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100
オーディオの49120RTP/AVP99m=a=rtpmap: 99AMR-WB/16000/2a=fmtp: =30a=maxptime: 100をはさみ込む99
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute.
ペイロード形式(コード化する)名が大文字で一般的に示されることに注意してください。 MIME血液型亜型は小文字で一般的に示されます。 これらの名前は両方の場所で大文字と小文字を区別しないです。 同様に、パラメタ名はMIMEの種類とデフォルトマッピングでSDP a=fmtp属性に大文字と小文字を区別しないです。
9. IANA Considerations
9. IANA問題
Two media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8.
2つのメディアタイプ(オーディオ/AMRとオーディオ/AMR-WB)をアップデートしました。 セクション8を見てください。
10. Changes from RFC 3267
10. RFC3267からの変化
The differences between RFC 3267 and this document are as follows:
RFC3267とこのドキュメントの違いは以下の通りです:
- Added clarification of behavior in regards to mode change period
and mode-change neighbor that is expected from an IP client; see
Section 4.5.
- IPクライアントから予想されるモード変更の期間とモード変更隣人に関する振舞いの加えられた明確化。 セクション4.5を見てください。
- Updated the maxptime for better clarification. The sentence that
previously read: "The time SHOULD be a multiple of the frame
size." now says "The time SHOULD be an integer multiple of the
frame size." This should have no impact on interoperability.
- より良い明確化のためにmaxptimeをアップデートしました。 以前に読んだ文: 「フレームの倍数が. 」 現在が言うサイズであったならSHOULDを調節してください、「フレームの整数倍数がサイズであったならSHOULDを調節してください、」 これは相互運用性に変化も与えるべきではありません。
- Updated the definition of the mode-set parameter for
clarification.
- 明確化のためのモードセットパラメタの定義をアップデートしました。
- Restricted the values for mode-change-period to 1 or 2, which are
the values used in circuit-switched AMR systems.
- モード変化の期間のための値を1か2に制限しました。(2はサーキットで切り換えられたAMRシステムで使用される値です)。
Sjoberg, et al. Standards Track [Page 53] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[53ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
- Added a new media type parameter Mode-Change-Capability that
defaults to 1, which is the assumed behavior of any non-updated
implementation. This enables the offer-answer procedures to work.
- どんな非アップデートされた実現の想定された振舞いである1もデフォルトとするニューメディア型引数Mode変化能力を加えました。 これは、申し出答え手順が働くのを可能にします。
- Changed mode-change-neighbor to indicate a recommended behavior
rather than a required one.
- 必要なものよりむしろお勧めの振舞いを示すためにモード変化隣人を変えました。
- Added an Offer-Answer Section, see Section 8.3.1. This will have
implications on the interoperability to implementations that have
guessed how to perform offer/answer negotiation of the payload
parameters.
- Offer-答えセクションを加えて、.1にセクション8.3を見ます。 これは相互運用性にペイロードパラメタの申し出/答え交渉を実行する方法を推測した実現に意味を持つでしょう。
- Clarified and aligned the unequal detection usage with the
published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1.
This included replacing a normative statement about packet
handling with an informative paragraph with a reference to UDP-
Lite.
- .1にはっきりさせて、広められたUDP-Lite仕様コネセクション3.6.1と4.4.2に不平等な検出用法を一直線にします。 これは、UDP- Liteの参照でパケット取り扱いに関する規範的陳述を有益なパラグラフで取り替えるのを含んでいました。
- Clarified the bit order in the CRC calculation in Section 4.4.2.1.
- はっきりさせられて、ビットはセクション4.4.2でCRC計算で.1を命令します。
- Corrected the reference in Section 5.3 for the Q and FT fields.
- セクション5.3でのQとFT分野の参照を修正しました。
- Changed the padding bit definition in Sections 4.4.2 and 5.3 so
that it is clear that they shall be ignored.
- 変えて、詰め物がセクション4.4.2と5.3との定義に噛み付いたので、それらが無視されるものとするのは、明確です。
- Added a clarification that comfort noise frames with frame type 9,
10, and 11 SHALL NOT be used in the AMR file format.
- フレームタイプ9、10、および11SHALL NOTがAMRファイルで使用されている安らぎ雑音フレームがフォーマットする明確化を加えました。
- Clarified in Section 4.3.2 that the rules about not sending
NO_DATA frames do apply for all payload format configurations with
the exception of the interleaved mode.
- _DATAフレームを全く送らないことに関する規則がするセクション4.3.2ではっきりさせられて、はさみ込まれたモード以外のすべてのペイロード形式構成に申し込んでください。
- The reference list has been updated to now published RFCs: RFC
3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A
reference to 3GPP TS 26.101 has also been added.
- 現在発行されたRFCsに参考文献一覧表をアップデートしました: RFC3448、RFC3550、RFC3551、RFC3711、RFC3828、およびRFC4566。 また、3GPP TS26.101の参照は加えられます。
- Added notes in storage format section and media type registration
that AMR and AMR-WB frames can also be stored in the 3GP file
format.
- また、3GPファイル形式に登録のそのAMRとAMR-WBが罪に陥れる格納形式部とメディアタイプによる付記された注意を格納できます。
- Added a media type parameter "max-red" that allows the sender to
declare a bounded usage of redundancy. This parameter allows a
receiver to optimize its function as it will know if redundancy
will be used or not. If it is used, the maximum extra delay
introduced by the sender (that is needed to be considered by the
receiver to fully utilize the redundancy) will be known. The
addition of this parameter should have no negative effects on
older implementations as they are mandated to ignore unknown
- 送付者が冗長の境界がある用法を宣言できる「最大赤」というメディア型引数を加えました。 このパラメタで、冗長が使用するなら、受信機は知るように機能を最適化できます。 それが使用されていると、送付者(すなわち、受信機で冗長を完全に利用すると考えられるのが必要である)によって導入された最大の余分な遅れは知られているでしょう。 それらが未知を無視するために強制されるとき、このパラメタの添加は、より古い実現にマイナスの効果を全く持つべきではありません。
Sjoberg, et al. Standards Track [Page 54] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[54ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
parameters per RFC 3267. In addition, older implementations are
required to operate as if the value of max-red is unknown and
possibly infinite.
RFC3267あたりのパラメタ。 さらに、より古い実現が、まるで最大赤の値が未知であってことによると無限であるかのように作動するのに必要です。
- Updated the media type registration to comply with the new
registration rules.
- アップデートして、メディアは、新規登録規則に従うために登録をタイプします。
- Moved section on decoding validation from Security Considerations
to Implementation Considerations, where it makes more sense.
- Security ConsiderationsからImplementation Considerationsまでの合法化を解読するところのセクションを動かしました。そこでは、それが、より多く理解できます。
- Clarified the application of encryption, integrity protection, and
authentication mechanism to the payload.
- 暗号化の応用、保全保護、および認証機構をペイロードにはっきりさせました。
11. Acknowledgements
11. 承認
The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of RFC 3267 and this replacement. The authors would also like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267.
作者はRFC3267の書くことと論評の間中された彼らの重要な貢献とこの交換についてペトリKoskelainen、バーンハード・ウィンマー、ティムFingscheidt、Sanjayグプタ、スティーブンCasner、およびコリン・パーキンスに感謝したがっています。 また、作者はRFC3267のこの交換に関する彼らの意見についてリチャードEjzak、トーマスBelling、およびゴーリーFairhurstに感謝したがっています。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[1] 3GPP TS26.090、「適応型のMulti-レート(AMR)スピーチコード変換」、バージョン4.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
[2] 3GPP TS26.101、「AMRスピーチコーデック枠組構造」、バージョン4.1.0(2001-06)、第3Generation Partnership Project(3GPP)。
[3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
functions", version 5.0.0 (2001-03), 3rd Generation Partnership
Project (3GPP).
[3] 3GPP TS26.190「AMR Widebandスピーチコーデック」。 「コード変換機能」、バージョン5.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure",
version 5.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[4] 3GPP TS26.201「AMR Widebandスピーチコーデック」。 「フレームStructure」、バージョン5.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] 3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate
operation", version 4.0.0 (2000-12), 3rd Generation Partnership
Project (3GPP).
[6]3GPP t26.093、「AMRスピーチコーデック」。 「ソースControlled Rate操作」、バージョン4.0.0(2000-12)、第3Generation Partnership Project(3GPP)。
Sjoberg, et al. Standards Track [Page 55] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[55ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
[7] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled
Rate operation", version 5.0.0 (2001-03), 3rd Generation
Partnership Project (3GPP).
[7] 3GPP t26.193「AMR広帯域スピーチコーデック」。 「ソースControlled Rate操作」、バージョン5.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[8]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[9] 3GPP TS 26.092, "AMR Speech Codec; Comfort noise aspects",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[9]3GPP t26.092、「AMRスピーチコーデック」。 「安らぎ雑音局面」、バージョン4.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[10] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise
aspects", version 5.0.0 (2001-03), 3rd Generation Partnership
Project (3GPP).
[10] 3GPP TS26.192「AMR Widebandスピーチコーデック」。 「安らぎNoise局面」、バージョン5.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[11] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[12] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[14] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[14]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[15] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
[15]Casner、S.、「メディアはRTP有効搭載量形式の登録をタイプする」RFC4855、2007年2月。
12.2. Informative References
12.2. 有益な参照
[16] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding",
version 8.0.1 (2000-11), European Telecommunications Standards
Institute (ETSI).
[16] GSM06.60、「高められたFull Rate(EFR)スピーチコード変換」、バージョン8.0.1(2000-11)、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[17] ANSI/TIA/EIA-136-Rev.C, part 410 - "TDMA Cellular/PCS Radio
Interface, Enhanced Full Rate Voice Codec (ACELP)". Formerly
IS-641. TIA published standard, June 1 2001.
[17] ANSI/TIA/EIA136人のC師、410を分けてください--「TDMAセル/PCSラジオインタフェース、エンハンストフルレート音声コーデック(ACELP)。」 以前、-641です。 TIAは規格、2001年6月1日を発行しました。
[18] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication
System RCR Standard", Association of Radio Industries and
Businesses (ARIB).
[18] ARIB、RCR STD-27H、「PDC通信システムRCR規格」、電波産業会(ARIB)。
[19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
RFC 3828, July 2004.
[19]Larzon、L-A.、デーゲルマルク、M.、ピンク、S.、イェンソン、L-E.、およびG.Fairhurst、「軽量のユーザー・データグラム・プロトコル(UDP-Lite)」、RFC3828 2004年7月。
Sjoberg, et al. Standards Track [Page 56] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[56ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
[20] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols",
version 4.2.0 (2001-09), 3rd Generation Partnership Project
(3GPP).
[20]3GPP TS25.415「UTRAN Iuインタフェースユーザ飛行機プロトコル」、バージョン4.2.0(2001-09)、第3Generation Partnership Project(3GPP)。
[21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[21] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[22] Li, A., et al., "An RTP Payload Format for Generic FEC with
Uneven Level Protection", Work in Progress.
[22] 李、A.、他、「不規則な平らな保護がある一般的なFECのためのRTP有効搭載量形式」、ProgressのWork。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[23] ローゼンバーグとJ.とH.Schulzrinne、「一般的な前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
[24] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[24] 3GPP TS26.102、「IuとUuへのAMRスピーチコーデックインタフェース」、バージョン4.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[25] 3GPP TS 26.202, "AMR Wideband speech codec; Interface to Iu and
Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[25] 3GPP TS26.202、「AMR Widebandスピーチコーデック」。 「IuとUuへのインタフェース」、バージョン5.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[26]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[27] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[27] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。
[28] 3GPP TS 26.103, "Speech codec list for GSM and UMTS", version
5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP).
[28] 3GPP TS26.103、「GSMとUMTSのためのスピーチコーデックリスト」、バージョン5.5.0(2004-09)、第3Generation Partnership Project(3GPP)。
[29] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[29]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[30] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[30] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[31] 3GPP TS 26.244, "3GPP file format (3GP)", version 6.1.0 (2004-
09), 3rd Generation Partnership Project (3GPP).
[31] 3GPP TS26.244、「3GPPファイル形式(3GP)」、バージョン6.1.0(2004- 09)、第3Generation Partnership Project(3GPP)。
[32] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
Generation Partnership Project (3GPP) Multimedia files", RFC
3839, July 2004.
[32] カスターニョ、研究開発Singer、「第3Generation Partnership Project(3GPP)マルチメディアのためのMIMEの種類Registrationsはファイルします」、RFC3839、2004年7月。
[33] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[33] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Sjoberg, et al. Standards Track [Page 57] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[57ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
[34] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[34] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
ETSI documents are available from <http://www.etsi.org/>. 3GPP documents are available from <http://www.3gpp.org/>. TIA documents are available from <http://www.tiaonline.org/>.
ETSIドキュメントは. 3GPPが<http://www.3gpp.org/>から利用可能であると記録する<http://www.etsi.org/>から利用可能です。TIAドキュメントは<http://www.tiaonline.org/>から利用可能です。
Authors' Addresses
作者のアドレス
Johan Sjoberg Ericsson AB SE-164 80 Stockholm, SWEDEN
ジョハンシェーベリエリクソンAB SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: Johan.Sjoberg@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
マグヌスWesterlundエリクソン研究エリクソンAB SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com
以下に電話をしてください。 +46 8 7190000 メール: Magnus.Westerlund@ericsson.com
Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group, FINLAND
アリLakaniemiノキアリサーチセンター私書箱407フィン-00045Nokia Group、フィンランド
Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com
以下に電話をしてください。 +358-71-8008000はメールされます: ari.lakaniemi@nokia.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA
シェモトローラ1501W.シュアーのドライブ、2-B8アーリントンハイツ、イリノイ 60004、米国をQiaobingします。
Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com
以下に電話をしてください。 +1-847-632-3028 メールしてください: Qiaobing.Xie@motorola.com
Sjoberg, et al. Standards Track [Page 58] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007
シェーベリ、他 AMRのための標準化過程[58ページ]RFC4867RTP有効搭載量形式とAMR-WB2007年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 at <%ietf-ipr@ietf.org に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sjoberg, et al. Standards Track [Page 59]
シェーベリ、他 標準化過程[59ページ]
一覧
スポンサーリンク
