RFC3267 日本語訳
3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and AdaptiveMulti-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund,A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 bytes) (Obsoleted by RFC4867) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Sjoberg
Request for Comments: 3267 M. Westerlund
Category: Standards Track Ericsson
A. Lakaniemi
Nokia
Q. Xie
Motorola
June 2002
コメントを求めるワーキンググループJ.シェーベリの要求をネットワークでつないでください: 3267年のM.Westerlundカテゴリ: 標準化過程エリクソンA.LakaniemiノキアQ.シェモトローラ2002年6月
Real-Time Transport Protocol (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
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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 MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format.
このドキュメントはAdaptive Multi-レート(AMR)に使用されるためにリアルタイムのトランスポート・プロトコル(RTP)ペイロード形式を指定します、そして、Adaptive MultiレートWideband(AMR-WB)はスピーチ信号をコード化しました。 ペイロード形式は、AMRとAMR-WB輸送が非IPネットワークでフォーマットする存在で共同利用できるように設計されています。 さらに、ファイル形式はメールなどの格納モードアプリケーションにおけるAMRとAMR-WBスピーチデータの輸送に指定されます。 2は含まれていたMIMEの種類登録証明書、AMRのためのもの、およびAMR-WBのための1つを切り離します、RTPペイロード形式と格納形式の両方の使用を指定して。
Sjoberg, et. al. Standards Track [Page 1] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[1ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
Table of Contents
目次
1. Introduction.................................................... 3
2. Conventions and Acronyms........................................ 3
3. Background on AMR/AMR-WB and Design Principles.................. 4
3.1. The Adaptive Multi-Rate (AMR) Speech Codec.................. 4
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec...... 5
3.3. Multi-rate Encoding and Mode Adaptation..................... 5
3.4. Voice Activity Detection and Discontinuous Transmission..... 6
3.5. Support for Multi-Channel Session........................... 6
3.6. Unequal Bit-error Detection and Protection.................. 7
3.6.1. Applying UEP and UED in an IP Network................... 7
3.7. Robustness against Packet Loss.............................. 9
3.7.1. Use of Forward Error Correction (FEC)................... 9
3.7.2. Use of Frame Interleaving...............................11
3.8. Bandwidth Efficient or Octet-aligned Mode...................11
3.9. AMR or AMR-WB Speech over IP scenarios......................12
4. AMR and AMR-WB RTP Payload Formats..............................14
4.1. RTP Header Usage............................................14
4.2. Payload Structure...........................................16
4.3. Bandwidth-Efficient Mode....................................16
4.3.1. The Payload Header......................................16
4.3.2. The Payload Table of Contents...........................17
4.3.3. Speech Data.............................................19
4.3.4. Algorithm for Forming the Payload.......................20
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.........................30
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
5. AMR and AMR-WB Storage Format...................................34
5.1. Single Channel Header.......................................34
5.2. Multi-channel Header........................................35
5.3. Speech Frames...............................................36
6. Congestion Control..............................................37
7. Security Considerations.........................................37
7.1. Confidentiality.............................................37
1. 序論… 3 2. コンベンションと頭文字語… 3 3. AMR/AMR-WBの上のバックグラウンドと設計原則… 4 3.1. 適応型のマルチレート(AMR)スピーチコーデック… 4 3.2. 適応型のマルチレート広帯域(AMR-WB)スピーチコーデック… 5 3.3. マルチレートコード化とモード適合… 5 3.4. アクティビティ検出と不連続なトランスミッションを声に出してください… 6 3.5. マルチチャンネルセッションのために、支持します。 6 3.6. 不平等なビット誤り検出と保護… 7 3.6.1. IPネットワークでUEPとUEDを適用します… 7 3.7. パケット損失に対する丈夫さ… 9 3.7.1. 前進型誤信号訂正(FEC)の使用… 9 3.7.2. フレームインターリービングの使用…11 3.8. 帯域幅の効率的であるか八重奏で並べられたモード…11 3.9. IPシナリオの上のAMRかAMR-WB Speech…12 4. AMRとAMR-WB RTP有効搭載量形式…14 4.1. RTPヘッダー用法…14 4.2. 有効搭載量構造…16 4.3. 帯域幅効率的なモード…16 4.3.1. 有効搭載量ヘッダー…16 4.3.2. 有効搭載量目次…17 4.3.3. スピーチデータ…19 4.3.4. 有効搭載量を形成するためのアルゴリズム…20 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. 有効搭載量を形成するための方法…30 4.4.5. 有効搭載量の例…32 4.4.5.1. 複数のフレームを運ぶ基本的なただ一つのチャンネル有効搭載量…32 4.4.5.2. CRC、インターリービング、および体力を要しているソーティングがある2チャンネル有効搭載量…32 4.5. 実現問題…33 5. AMRとAMR-WB格納形式…34 5.1. チャンネルヘッダーを選抜してください…34 5.2. マルチチャンネルヘッダー…35 5.3. スピーチフレーム…36 6. 混雑コントロール…37 7. セキュリティ問題…37 7.1. 秘密性…37
Sjoberg, et. al. Standards Track [Page 2] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[2ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
7.2. Authentication..............................................38
7.3. Decoding Validation.........................................38
8. Payload Format Parameters.......................................38
8.1. AMR MIME Registration.......................................39
8.2. AMR-WB MIME Registration....................................41
8.3. Mapping MIME Parameters into SDP............................44
9. IANA Considerations.............................................45
10. Acknowledgements...............................................45
11. References.....................................................45
11.1 Informative References......................................46
12. Authors' Addresses.............................................48
13. Full Copyright Statement.......................................49
7.2. 認証…38 7.3. 合法化を解読します…38 8. 有効搭載量形式パラメタ…38 8.1. AMRは登録をまねます…39 8.2. AMR-Wb MIME登録…41 8.3. MIMEパラメタをSDPに写像します…44 9. IANA問題…45 10. 承認…45 11. 参照…45 11.1 有益な参照…46 12. 作者のアドレス…48 13. 完全な著作権宣言文…49
1. Introduction
1. 序論
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 MIME type registrations are provided, one for AMR and one for AMR-WB.
ペイロード形式自体はセクション4で指定されます。 関連するファイル形式はセクション5でメールなどの格納モードアプリケーションにおけるAMRとAMR-WBスピーチデータの輸送に指定されます。 セクション8、twoでは、登録証明書が提供されるMIMEの種類、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 RFC2119 [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
3GPP--第三世代パートナーシッププロジェクトAMR--適応型のマルチレートコーデックAMR-WB--適応型のマルチレート広帯域コーデックCMR--コーデックモード要求CN--安らぎ雑音DTX--不連続なトランスミッション
Sjoberg, et. al. Standards Track [Page 3] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[3ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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
ETSI--ヨーロッパのTelecommunications Standards Institute FEC--前進のError Correction SCR--ソースControlled Rate Operation SID--沈黙Indicator(CNパラメタだけを含むフレーム)VAD--声のActivity Detection UED--不平等なError Detection UEP--不平等なError Protection
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スピーチが縁どるすべてがまさに同じ期間を表します。
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 MIME 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では、パラメタのすべてがMIME「副-タイプ」登録証明書の形でAMRとAMR-WB encodingsに指定されます。 セッションセットアップでこれらのパラメタを示唆するか、または関係者の事前同意をアレンジするのに使用される方法はこのドキュメントの範囲を超えています。 しかしながら、セクション8.3はSDPを使用するそれらのアプリケーションのためのSession記述プロトコル(SDP)[11]にパラメタに関するマッピングを提供します。
3.1. The Adaptive Multi-Rate (AMR) Speech Codec
3.1. 適応型のマルチレート(AMR)スピーチコーデック
The AMR codecs 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 8 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 4] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[4ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
Among the 8 AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [14], the 7.4 kbps mode as IS-641 codec in TDMA [13], and the 12.2 kbps mode as GSM-EFR [12].
モードをコード化する8AMRにおける3は別々にそれら自身の規格として既に採用されます。 特に、6.7キロビット毎秒モードはPDC-EFR[14]として採用されます、7.4キロビット毎秒モード、-641である、コーデック、TDMA[13]、およびGSM-EFR[12]としての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 9 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. E.g., 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 to enable 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 5] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[5ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 8 AMR modes for an AMR session or any combination of the 9 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 MIME parameters that may be used to signal these mode adaptation controls at session setup.
セクション8はセッションセットアップでこれらのモード適合コントロールを示唆するのに使用されるかもしれない1セットのMIMEパラメタを指定します。
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
セッションセットアップのときに、バンドの外では、それぞれのフレームブロックの異なったチャンネルからセッションにおける、チャンネルの数とスピーチフレームの注文を示すのにシグナリングを使用しなければなりません。 シグナリングにSDPを使用するとき、チャンネルの数はrtpmapで指定されます。
Sjoberg, et. al. Standards Track [Page 6] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[6ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
attribute and the order of channels carried in each frame-block is implied by the number of channels as specified in Section 4.1 in [24].
[24]で指定されるとしてのセクション4.1のチャンネルの数でそれぞれのフレームブロックで運ばれたチャンネルの属性と注文を含意します。
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 most sensitive and bits in class C least sensitive (see Table 1 below for AMR and [4] for AMR-WB). A 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ビット)で見つけられた誤りが噛み付かれる場合にだけ、フレームは破損していると申告されます。 他方では、他のビットにおける誤り、すなわち、クラス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合計スピーチ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 7] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[7ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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を達成できます。
Today there exist some link layers that do not discard packets with 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 [15], bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links.
今日、噛み付いている誤り、例えば、SLIPと共にパケットを捨てないいくつかのリンクレイヤが存在します、そして、いくらかの無線電信がリンクされます。 インターネットトラフィックパターンが、よりマルチメディア中心のものに向かって移行している状態で、より多くのリンクレイヤのそのような本質は将来、現れるかもしれません。 部分的なチェックサムのトランスポート層サポートで、例えばUDP-Lite[15]、ビットの誤りの許容性があるAMR、およびAMR-WB交通で支持されたものはこれらのタイプのリンクの上により良い性能を達成できました。
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つの基本的なアプローチがあります:
1) Utilizing a partial checksum to cover headers and the most
important speech bits of the payload. It is recommended that at
least all class A bits are covered by the checksum.
1) ヘッダーとペイロードの最も重要なスピーチビットを含むのに部分的なチェックサムを利用します。 少なくともすべてのクラスAビットがチェックサムでカバーされているのは、お勧めです。
2) Utilizing a partial checksum to only cover headers, but a frame
CRC to cover the class A bits of each speech frame in the RTP
payload.
2) カバーヘッダーだけに部分的なチェックサムを利用しますが、それぞれのスピーチのクラスAビットがRTPペイロードで縁どるカバーにフレーム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 pay
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 UMTS can be found in [20] and for
AMR-WB in [21].
注意、ネットワーク設計者がクラスBとC残差ビット誤り率に注意を向けるのは、まだ重要です。 クラスAビットほど誤りに敏感ではありません、クラスBとCビットはわずかではありません、そして、これらのビットにおける非検出された誤りはスピーチ品質における退行を引き起こしますが。 [20]と[21]のAMR-WBに関して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コード化などのアプリケーションを支持できるくらい低い残りのビット誤り率を選ぶのは義務です。
Approach 1 is a bit efficient, flexible and simple way, 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 frames in a payload there is the possibility that a single bit error in protected bits will cause all the frames to be discarded.
アプローチ1は、少し効率的で、フレキシブルで簡単な道ですが、2回の損失と共に来ます、そして、すなわち、保護されたスピーチビットにおけるa)の噛み付いている誤りでペイロードを捨てるでしょう、そして、ペイロードの複数のフレームをそこに輸送するとき、b)は保護されたビットにおけるただ一つの噛み付いている誤りですべてのフレームを捨てる可能性です。
Sjoberg, et. al. Standards Track [Page 8] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[8ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 gives an improvement in speech quality when transporting multiple frames over links subject to bit errors.
フレーム的なCRC(アプローチ2)の形で何らかのオーバーヘッドで必要であるなら、これらの損失を避けることができます。 問題a)では、CRCはスピーチ品質でクラスAビットに噛み付いている誤りを検出して、誤り補正にフレームを使用するのを可能にします。(誤り補正は小さい改良を与えます)。 ペイロードの複数のフレームを輸送するとき、b)に関しては、CRCsはクラスAビットにおけるただ一つの噛み付いている誤りですべてのフレームを捨てる可能性を取り除きます。 リンクの上に噛み付いている誤りを条件として複数のフレームを輸送するとき、それを避けると、スピーチ品質における改良は与えられます。
The choice between the above two approaches must be made based on the available bandwidth, and desired tolerance to bit errors. Neither solution is appropriate to all cases. Section 8 defines parameters that may be used at session setup to select 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., RFC2733 [19], 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 [18] that can be applied to AMR or AMR-WB payload transport.
以前に送られたデータの反復の簡単な計画はFECを達成することにおいて一方通行です。 別の、より多くの帯域幅効率的な可能な計画はペイロードの外部のFEC、例えば修理データを含む余分なパケットを発生させるRFC2733[19]を使用することです。 また、UEPを使用することで外部のFEC計画を支持する感度命令で全体のペイロードを分類できます。 また、AMRに適用できるそのような計画[18]かAMR-WBペイロード輸送の一般的なバージョンの進行中の仕事があります。
With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of the same mode or of another mode, e.g., one with lower-bandwidth. We describe such a scheme next.
AMRかAMR-WBでは、コーデックが同じモードか別のモードの余分なコピーを送るマルチレート能力を使用するのは可能です、例えば、下側の帯域幅がある1。 私たちは次に、そのような計画について説明します。
Sjoberg, et. al. Standards Track [Page 9] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[9ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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. 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.
このアプローチの使用は、セッションセットアップのときに合図するのを必要としません。 言い換えれば、スピーチ送付者は、受信機に相談しないでこの計画を使用するのを選ぶことができます。余分なフレームを含むパケットが新しいフレームだけについてパケットと異なるように見えないので、これはそうです。 どんなパケットも無くならないなら、受信機はあるタイムスタンプのために、フレームの複本かバージョン(異なったモードで、コード化される)を受けるかもしれません。 同じスピーチフレームの複数のバージョンが受け取られているなら、最も高いレートがあるモードがスピーチデコーダによって使用されるのは、お勧めです。
This redundancy scheme provides the same functionality as the one described in RFC 2198 "RTP Payload for Redundant Audio Data" [24]. 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 5 frame times, 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有効搭載量」[24]で説明されたものと同じ機能性を提供します。 多くの場合、このペイロード形式のメカニズムは、さらに、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 receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on none-IP
送付者はチャンネルに関するフィードバックに基づく適切な量の冗長を選択するのに責任があります、例えば、RTCP受信機レポートで。 送付者のFECの選択はCMRに基づいているべきではありません、このパラメタが最もたぶんベースで設定されたときオンである、なにも、-、IP
Sjoberg, et. al. Standards Track [Page 10] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[10ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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).
情報、例えば、ラジオリンク性能測定。 また、送付者も混雑を避けるのに責任があります(その他の詳細に関してセクション6を見てください)。(混雑は冗長によって悪化させられるかもしれません)。
3.7.2. Use of Frame Interleaving
3.7.2. フレームインターリービングの使用
To decrease protocol overhead, the payload design allows several speech frame-blocks be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that in case of packet loss this means 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 robust to packet loss and bit errors.
2つのオペレーションモードの間では、八重奏で並べられたモードだけがスピーチをパケット損失に体力を要している輸送と噛み付いている誤りにする体力を要しているソーティングを使用する能力、インターリービング、およびフレームCRCを持っています。
Sjoberg, et. al. Standards Track [Page 11] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[11ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
3.9. AMR or AMR-WB Speech over IP scenarios
3.9. IPシナリオの上のAMRかAMR-WB Speech
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 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をサポートする利点はリソースをリンクします。
Streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than 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 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 occurs when AMR or AMR-WB encoded speech will be transmitted from a non-IP system (e.g., a GSM or 3GPP network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
AMRかAMR-WBが非IPシステムからIPに伝えられた(例えば、GSMか3GPPネットワーク)/UDP/がRTP VoIP端末であるつもりであったならスピーチをコード化したとき、別のシナリオは起こります、そして、逆もまた同様です、図3に表現されるように。
Sjoberg, et. al. Standards Track [Page 12] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[12ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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/3GPP network | IP network
|
AMRかAMR-WB、終わっている、I.366 2、3、+------+ +----------または+ 3G Iu。| | またはIP/UDP/RTP/AMR。| | <、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 端末| GSM Abis| | IP/UDP/RTP/AMR-Wb| | など +------+ +----------+ | GSM/3GPPネットワーク| IPネットワーク|
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 response to CMR by the IP terminal.
速いモードの切り換えをするAMRの能力は、スピーチ品質を最適化するためにいくつかの非IPのネットワークで開発されます。 IPネットワークへのゲートウェイを含んでいて、シナリオにこの機能性を保存するために、コーデックモード要求(CMR)分野が必要です。 ゲートウェイは両方の指示で非IPとIPの部品の間にCMRを送るのに原因となるようになるでしょう。 IP端末はゲートウェイによって進められた、非IPデコーダに行くスピーチ品質を最適化したCMRに続くはずです。 ゲートウェイのモードコントロールアルゴリズムはIP端末によってIPネットワークによってCMRへの応答に課された遅れを収容しなければなりません。
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ネットワークで混雑を制御するのを意図するように。
Sjoberg, et. al. Standards Track [Page 13] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[13ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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で例証されるように。
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/3GPP network | IP network | GSM/3GPP 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/3GPPネットワーク| IPネットワーク| GSM/3GPPネットワーク| |
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]で指定されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
Sjoberg, et. al. Standards Track [Page 14] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[14ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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タイムスタンプはパケットにおける最初のフレームブロックにコード化された最初のサンプルの標本抽出の瞬間に対応しています。 タイムスタンプクロック周波数がサンプリング周波数と同じであるので、タイムスタンプユニットがサンプルにあります。
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, either in exact duplicates, or 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 is always made an integral number of octets long 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に噛み付きました。
Sjoberg, et. al. Standards Track [Page 15] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[15ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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プロフィールが、このコード化のためのペイロードタイプを選任するか、またはペイロードタイプによってダイナミックに制限されていることになっていると指定すると予想されます。
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はどんなモード要求も存在していなくて、他の値が今後の使用のためのものであることを示します。
Sjoberg, et. al. Standards Track [Page 16] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[16ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
The mode request received in the CMR field is valid until the next CMR is received, i.e., a newly received CMR value overrides the previous one. Therefore, if a terminal continuously wishes to receive frames in the 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.
次のCMRが受け取られているまでCMR分野に受け取られたモード要求が有効である、すなわち、新たに受け取られたCMR値は前のものをくつがえします。 したがって、端末が同じモードXで絶え間なくフレーム搬入したいなら、すべての外国行きのペイロードと端末がどのモードを受けたらよいかでどちらでもよいかどうかCMR=Xを設定するのが必要であり、すべての外国行きのペイロードのSHOULDセットCMR=15です。
If receiving a payload with a CMR value which 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, CMR SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session.
マルチチャンネルセッション、CMR SHOULD、ペイロードの受信機で、セッションのときにすべてのチャンネルに、必要なコード化モードとして解釈されてください。
An IP end-point SHOULD NOT set the CMR based on packet losses or other congestion indications, for several reasons:
CMRがパケット損失に基礎づけた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 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 mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a mode change is needed.
マルチキャストグループに送られたパケットのためにCMR分野を15に設定しなければなりません。 モードが変化するというヒントが必要であるように、スピーチ送付者SHOULDのエンコーダは、マルチキャストセッションにスピーチを送るとき、モード要求を無視しますが、RTCPフィードバック情報を使用するかもしれません。
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).
コーデックモード選択はセッションパラメタによって利用可能なモードの部分集合に制限されるかもしれません。 そうだとすれば、合図された部分集合の中に要求されたモードがあるに違いありません(セクション8を見てください)。
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 17] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[17ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 there is no data produced by the speech encoder for that frame 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. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted, 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 18] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[18ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [16], 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 comparing to dropping the damaged frames. See Section 4.4.2.1 for more details.
フレーム質のインディケータはATMペイロード形式がITU-T I.366.2で説明されている相互運用性のために含まれています、UMTS Iuインタフェース[16]、他の輸送形式と同様に。 フレーム質のインディケータは、破損しているフレームが誤り補正のためのスピーチデコーダに送られるのを可能にします。 これは破損しているフレームを落とすと比較されるスピーチ品質を改良できます。 セクション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 [24]. 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エントリーは[24]でセクション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 3 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 one or more speech frames or comfort noise frames, as described in the ToC of the payload.
ペイロードに関するスピーチデータは1個以上のスピーチフレームか安らぎ雑音フレームを含んでいます、ペイロードの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 19] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[19ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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, contiguously into octets beginning with the most significant bits of the fields and the octets.
帯域幅効率的なモードによる完全なRTPペイロードはペイロードヘッダー、目次、およびスピーチからのビットが近接してToCリストで彼らの対応するToCエントリーで定義されるオーダーで分野と八重奏の最も重要なビットで始まる八重奏に縁どるパッキングで形成されます。
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)
Sjoberg, et. al. Standards Track [Page 20] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[20ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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ペイロードを示しています。
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 zero bits 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ゼロ・ビットがペイロード八重奏を並べさせるためにそっと歩くとして終わりに加えられます。
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sjoberg, et. al. Standards Track [Page 21] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[21ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 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 kpbs 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.85kpbsモード(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 is 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 0s are padded to the end to make the payload octet aligned.
以下に示すように、ペイロードは受信機の側の上のエンコーダが将来のコード化モードをAMR-WB8.85キロビット毎秒(CMR=1)に変えるというモード要求を運びます。 フレームのいずれもIPの起源(Q=1)で破損しません。 コード化されたスピーチとSIDビット(h(176)へのd(131)へのd(0)、g(0)からg(39)、およびh(0))は、[4]に応じて感度オーダーを滑降させる際にペイロードでアレンジされます。 (注意、どんなスピーチビットも3番目のフレームに存在していません。) 最終的に、7 0が、ペイロード八重奏を並べさせるために終わりまで水増しされます。
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sjoberg, et. al. Standards Track [Page 22] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[22ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 kbit/s (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.4kbit/s(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 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[23ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[24ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 interleave 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 interleave group during an interleave session. Here we assume ILL=L for the interleave group that starts at speech frame- block n. We also assume that the first payload packet of the interleave group is s and the number of speech frame-blocks carried in each payload is N. Then we will have:
以下の例はインタリーブにおけるブロックがインタリーブセッションの間に分類するスピーチフレームのアレンジメントを例証します。 ここで、私たちは、スピーチフレームで始まるインタリーブグループのためのILL=Lがnを妨げると思います。 また、私たちは、インタリーブグループの最初のペイロードパケットがsであると思います、そして、各ペイロードで運ばれたスピーチフレームブロックの数は私たちが望んでいるN.Thenが以下を持っているということです。
Payload s (the first packet of this interleave 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 interleave group):
有効搭載量s+1(このインタリーブグループの2番目のパケット):
Sjoberg, et. al. Standards Track [Page 25] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[25ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
ILL=L, ILP=1,
frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)
...
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 interleave 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 interleave 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 interleave group. In other words, all payloads in an interleave 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 MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
受信機がバンドで出ている手段による使用に合図したなら、ペイロードの送付者はインターリービングを適用するだけでよいです。 インターリービングが受信機で要件をバッファリングしながら増加するので、受信機はインターリービンググループでIに許されたフレームブロックの最大数を設定するのに「インターリービング=私」というMIMEパラメタを使用します。
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 interleave group is less or equal to I, i.e., 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, i.e.,
すなわち、八重奏で並べられたモードによる目次(ToC)は各エントリーがペイロードで運ばれたスピーチフレームに対応するToCエントリーのリストと任意にスピーチフレームCRCsのリストから成ります。
+---------------------+
| 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もないことに注意してください。
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 consecutive 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
Sjoberg, et. al. Standards Track [Page 26] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[26ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
The following example shows the ToC of three consecutive packets, each carrying 3 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 makes the interleave group 9 frame-blocks large.
はさみ込まれた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
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との定義を見てください。
Sjoberg, et. al. Standards Track [Page 27] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[27ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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.
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 bit 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 [15], to protect the RTP header, payload header, and table of contents bits in a payload. The frame CRC, when used, MUST be calculated only over all class A bits in the frame. Class B and C bits in the frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum.
UEDを達成するなら、1SHOULDが、ペイロードにRTPヘッダー、ペイロードヘッダー、および目次ビットを保護するのにトランスポート層チェックサム、例えばUDP-Lite[15]で定義されたものを使用します。 使用されると、フレームでフレームCRCについてすべてのクラスAビットの上だけ計算しなければなりません。 フレームのクラス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]のテーブル2の標準として指定されます、そして、SIDフレーム(FT=9)には、40クラスAビットがあります。 このペイロード形式にクラスAビットのこれらの定義を使用しなければなりません。
Packets SHOULD be discarded if the transport layer checksum detects errors.
パケットSHOULD、トランスポート層チェックサムが誤りを検出するなら、捨てられてください。
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]とその他の詳細を見てください。
Sjoberg, et. al. Standards Track [Page 28] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[28ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年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 CRC's takes 8 bits
それぞれのCRCのものは8ビット取ります。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | c0| c1| c2| c3| c4| c5| c6| c7| +---+---+---+---+---+---+---+---+
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 has the following form: 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 bit of the CRC register and the bit. The CRC register is then right shifted one step (inputting a "0" as the leftmost bit). If the result of the XOR operation mentioned above is a "1" "10111000" is then 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) have been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRC's.
CRCの実際の計算を以下の通りにします: まず最初に、CRCが示す8ビットはゼロにリセットされます: 00000000. CRCが計算されるものとする各ビットにおいて、XOR操作をCRCレジスタの一番右のビットとビットの間します。 次に、CRCレジスタが正しい移行しているワンステップである、(aを入力する、「一番左ビットとしての0インチ)」 前記のようにXOR操作の結果による「1インチ「10111000」はCRCレジスタへの次に、ビット的なXOR-エドである」なら。 CRCはスピーチフレームへのCRCがそうするべきであるd(0)がカバーであるなら. この場合最初のビットをカバーしているでしょうに。この操作はこのCRCの最後のビットであるときに、(例えば、セクション3.6におけるTable1に従ったAMR5.9のためのd(54))がそうであるそれぞれの中古さビットの計算のために繰り返されて、CRCレジスタのコンテンツは単にCRCのリストの対応する分野にコピーされるべきです。
Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm.
汎用CPUにおけるCRCの速い計算は、テーブル駆動のアルゴリズムを使用することで可能です。
Sjoberg, et. al. Standards Track [Page 29] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[29ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 zeroes
at the end if not all bits in the octet are used. 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 can be arranged
either one whole frame after another as usual, or with the
octets of all frames interleaved together at the octet level.
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 [15]) or UEP
(such as the ULP [18]) mechanisms to the payload data. The
details of assembling the payload are given in the next
section.
- 複数のスピーチフレームがスピーチデータ(すなわち、合成ペイロード)に存在しているとき、スピーチフレームは整っているどちらかがいつものようか、すべてのフレームの八重奏が八重奏レベルで一緒にはさみ込まれている別のものの後の全体のフレームであったなら存在できます。 各フレームの中のビットが最初に最も多くの誤り敏感なビットで配置されるので、八重奏をはさみ込むと、それらの敏感なビットはパケットのより多くの始まり頃に、あるようにすべてのフレームから集まります。 これがUEDのアプリケーションを許容する「体力を要しているソーティング命令」と呼ばれる、(UDP-Lite[15])かUEP、(ペイロードデータへのULP[18])メカニズムなどのように。 ペイロードを組み立てることの詳細は次のセクションで明らかにされます。
The use of robust sorting order for a session MUST be agreed via out-of-band means. Section 8 specifies a MIME parameter for this purpose.
バンドで出ている手段で同意しなければならないセッションの体力を要しているソーティング命令の使用。 セクション8はこのためにMIMEパラメタを指定します。
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 sessions.
注意、体力を要しているソーティング命令は、フレーム・レベルに実行するだけでよくて、その結果、フレームブロックレベルにあるインターリービングから独立しています、セクション4.4.1で説明されるように。 言い換えれば、非はさみ込まれたかはさみ込まれたセッションに体力を要しているソーティングを適用できます。
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 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もないことに注意してください。
Sjoberg, et. al. Standards Track [Page 30] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[30ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 that frame 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 to communicate to other layers performing UED/UEP the number of octets to be covered 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 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[31ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 session 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キロビット毎秒コード化モード(FT=5)の2個のAMRフレームを運ぶただ一つのチャンネルセッションから八重奏の並べられたペイロードを示しています。 ペイロードでは、(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 above example the last octet in both speech frames is padded with one 0 to make it octet-aligned.
両方のスピーチフレームにおける最後の八重奏が1つ0で水増しされる、作る上記の例でそれが八重奏で並んだことに注意してください。
4.4.5.2. Two Channel Payload with CRC, Interleaving, and Robust-sorting
4.4.5.2. 2はCRC、インターリービング、および体力を要しているソーティングがある有効搭載量を向けます。
This example shows an octet aligned payload from a two channel session. Two frame-blocks, each containing 2 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 and frame-block interleaving are both enabled for the session. The interleaving length is 2 (ILL=1) and this payload is the first one in an interleave group (ILP=0).
そのうえ、フレームCRCとフレームブロックインターリービングはセッションのためにともに有効にされます。 インターリービングの長さは2(ILL=1)です、そして、このペイロードはインタリーブグループ(ILP=0)で最初のものです。
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
そしてペイロードの最初の2個のフレームが、フレームブロック#1のLとRチャンネルスピーチフレームです、ビットf1L(0 .158)から成って。
Sjoberg, et. al. Standards Track [Page 32] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[32ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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.
それぞれ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 above example the last octet in all the 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 MIME 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とMIMEパラメタを理解しなければなりません。 この要件は、実現が、いつもそれが交信できるかどうか決めることができるのを確実にします。
No operation 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 mode for single channel. The other operations mode: interleaving, robust sorting, frame-wise CRC in both single and multi-channel is OPTIONAL to implement.
ペイロード形式のどんなオペレーションモードも、実行するために義務的ではありません。 ペイロード形式を使用するアプリケーションの要件は、何を実行したらよいかを決定するのに使用されるべきです。 基本的な相互運用性を達成するために、SHOULDが帯域幅効率的なものと同様に八重奏で並べられたモードを少なくとも実行する実現はチャンネルを選抜します。 もう片方の操作モード: シングルとマルチチャンネルの両方のはさみ込んでいて、強健な分類していて、フレーム的なCRCは道具へのOPTIONALです。
Sjoberg, et. al. Standards Track [Page 33] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[33ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 e-mail 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.
ただ一つのチャンネル内容がマルチチャンネル内容のものと異なったファイルヘッダー形式を使用することに既に配備された実現がある保護区相互運用性に注意してください。
5.1. Single channel Header
5.1. チャンネルHeaderを選抜してください。
A single channel AMR or AMR-WB file header contains only a magic number and 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)
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」をマジックナンバーの重要な部分であり、比較に含まなければなりません、さもなければ、上のただ一つのチャンネルマジックナンバーが次のセクションで定義されたマルチチャンネルファイルのものから区別がつかなくなるので。
Sjoberg, et. al. Standards Track [Page 34] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[34ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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 bit 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
[24].
チェン(4の噛み付いている符号のない整数): この格納ファイルに含まれた音声チャンネルの数を示します。 [24]でセクション4.1でフレームブロックの中のチャンネルの有効値と注文を指定します。
Sjoberg, et. al. Standards Track [Page 35] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[35ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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.1.2. The P bits are padding and MUST be set to 0.
同様に、FT野原とQビットはセクション4.1.2で定義づけられます。 Pビットはそっと歩いていて、0に設定しなければなりません。
Following this one octet header come the speech bits as defined in 4.3.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment.
この1個の八重奏ヘッダーに続いて、来てください、4.3で.3に定義されるスピーチビット 八重奏整列を達成するのに必要であるなら、それぞれのフレームの最後の八重奏はゼロで水増しされます。
The following example shows an AMR frame in 5.9 kbit coding mode (with 118 speech bits) in the storage format.
以下の例は、5.9kbitの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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame-blocks or speech frames lost in transmission and non-received 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]) or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media.
どんな_DATAフレームとしてもフレームブロックか非スピーチの期間、トランスミッションとSIDアップデートの間の非受信されたフレームブロックで失われたスピーチフレームを格納してはいけません。(同期を保つために[2]と[4])かSPEECH_LOST(タイプ14を罪に陥れてください、単にAMR-WBに、利用可能である)で完全なフレームブロックで定義されるようにオリジナルのメディアでタイプ15を罪に陥れてください。
Sjoberg, et. al. Standards Track [Page 36] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[36ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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, e.g., "Equation-Based Congestion Control for Unicast Applications" [17].
このペイロード形式雇用混雑を使用するAMRかAMR-WBアプリケーションが制御されるのは、RECOMMENDEDです。 輻輳制御のための実際のメカニズムは、指定されませんが、本当の時間流れ(例えば、「ユニキャストアプリケーションのための方程式ベースの輻輳制御」[17])に適しているべきです。
7. Security Considerations
7. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8].
この仕様に基づき定義されたペイロード書式を使用するRTPパケットは[8]で議論した総合証券問題を受けることがあります。
As this format transports encoded speech, the main security issues include confidentiality and authentication of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [22], MAY be used.
この形式がコード化されたスピーチを輸送するとき、主な安全保障問題はスピーチ自体の秘密性と認証を含んでいます。 ペイロード形式自体には、どんな内蔵のセキュリティーメカニズムもありません。SRTP[22]などの外部のメカニズムは使用されるかもしれません。
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.
このペイロード形式は、パケット処理のために受信機サイド計算量で少しの重要な非の一様性も示さないで、その結果、病理学的なデータの領収書のためサービスの否定の脅威を引き起こしそうにはありません。
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 a need to encrypt the payload header or the table of contents due to 1) that they only carry information about the requested speech mode, frame type, and frame quality, and 2) that this information could be useful to some third party, e.g., quality monitoring.
コード化されたAMRかAMR-WBスピーチの秘密性を達成するために、すべてのスピーチデータ・ビットが、コード化される必要があるでしょう。 この情報が要求されたスピーチモード、フレームタイプ、フレーム品質、および2の)情報であるかもしれませんが、彼らが運ばない1のしか)ためペイロードヘッダーか目次をコード化するより少ないa必要が第三者、例えば、上質のモニターの役に立った状態であります。
Sjoberg, et. al. Standards Track [Page 37] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[37ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
As long as the AMR or AMR-WB payload is only packed and unpacked at either end, encryption may be performed after packet encapsulation so that there is no conflict between the two operations.
AMRかAMR-WBペイロードが梱包されるだけであり、どちらの終わりにもアンパックされる限り、暗号化は、パケットカプセル化の後に2つの操作の間には、闘争が全くないように、実行されるかもしれません。
Interleaving may affect encryption. Depending on the encryption scheme used, there may be restrictions on, for example, the time when keys can be changed. Specifically, the key change may need to occur at the boundary between interleave groups.
インターリービングは暗号化に影響するかもしれません。 使用される暗号化計画によって、例えば、キーを変えることができる時代に、制限があるかもしれません。 明確に、キーチェンジは、インタリーブグループの間の境界に起こる必要があるかもしれません。
The type of encryption method used may impact the error robustness of the payload data. The error robustness may be severely reduced when the data is encrypted unless an encryption method without error- propagation is used, e.g., a stream cipher. Therefore, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted.
方法が使用した暗号化のタイプはペイロードデータの誤り丈夫さに影響を与えるかもしれません。 誤り伝播のない暗号化方法が使用されていない場合データがコード化されているとき、誤り丈夫さは厳しく減少するかもしれません、例えば、ストリーム暗号。 したがって、体力を要しているソーティングに基づくUED/UEPはペイロードデータがコード化されているとき、適用するのが難しいかもしれません。
7.2. Authentication
7.2. 認証
To authenticate the sender of the speech, an external mechanism has to be used. It is RECOMMENDED that such a mechanism protect all the speech data bits. Note that the use of UED/UEP may be difficult to combine with authentication because any bit errors will cause authentication to fail.
スピーチの送付者を認証するために、外部のメカニズムは使用されなければなりません。 そのようなメカニズムがすべてのスピーチデータ・ビットを保護するのは、RECOMMENDEDです。 UED/UEPの使用は誤りが認証がどんなビット失敗されるのでも認証に結合するのが難しいかもしれないことに注意してください。
Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality. Tampering with the CMR field may result in speech in a different quality than desired.
中央の男性攻撃者にいじられるデータはスピーチ品質を下げることができた誤ったdepacketization/解読をもたらすかもしれません。 CMR分野をいじると、異なった品質におけるスピーチは望まれているよりもたらされるかもしれません。
To prevent a man-in-the-middle attacker from tampering with the payload packets, some additional information besides the speech bits SHOULD be protected. This may include the payload header, ToC, frame CRCs, RTP timestamp, RTP sequence number, and the RTP marker bit.
中央の男性攻撃者がスピーチビットSHOULD以外にペイロードパケット、何らかの追加情報をいじるのを防ぐには、保護されてください。 これはペイロードヘッダー、ToC、フレームCRCs、RTPタイムスタンプ、RTP一連番号、およびRTPマーカービットを含むかもしれません。
7.3. Decoding Validation
7.3. 合法化を解読します。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information of the session 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はパケットを捨てます。 これは長さの分野に誤りを持っているパケットを解読するとスピーチ品質が厳しく下げられるかもしれないからです。
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 MIME subtype registrations
このセクションはAMRとAMR-WBペイロード形式に関するオプション機能を選択するのに使用されるかもしれないパラメタを定義します。 パラメタはここでMIME「副-タイプ」登録証明書の一部と定義されます。
Sjoberg, et. al. Standards Track [Page 38] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[38ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
for the AMR and AMR-WB speech codecs. 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 MIME or SDP.
AMRとAMR-WBスピーチコーデックのために。 また、Session記述プロトコル(SDP)[11]へのパラメタに関するマッピングをSDPを使用するそれらのアプリケーションに提供します。 同等なパラメタは使用のためのほかの場所でMIMEかSDPを使用しない制御プロトコルで定義されるかもしれません。
Two separate MIME registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by the MIME subtype.
2は登録証明書がされるMIME、AMRのためのもの、およびAMR-WBのための1つを切り離します、それらがMIME「副-タイプ」が区別しなければならない異なったencodingsであるので。
The data format and parameters are specified for both real-time transport in RTP and for storage type applications such as e-mail attachments.
データの形式とパラメタはRTPのともにリアルタイムの輸送と電子メールの添付ファイルなどの格納タイプアプリケーションに指定されます。
8.1. AMR MIME Registration
8.1. AMR MIME登録
The MIME subtype for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is expected to be a widely used speech codec in general VoIP applications. This MIME registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
AMRが一般に、広く使用されたスピーチコーデックであると予想されるので(AMR)コーデックがIETF木から割り当てられるAdaptive Multi-レートVoIPアプリケーションのためのMIME「副-タイプ」。 このMIME登録は格納されたファイルで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: Requested AMR mode set. Restricts the active codec
mode set to a subset of all modes. Possible values are a
comma separated list of modes from the set: 0,...,7 (see
Table 1a [2]). If such mode set is specified by the
decoder, the encoder MUST abide by the request and MUST
NOT use modes outside of the subset. If not present, all
codec modes are allowed for the session.
モードセット: 要求されたAMRモードはセットしました。 活動的なコーデックモードセットをすべてのモードの部分集合に制限します。 可能な値はセットからのモードのコンマの切り離されたリストです: 0,...7 (テーブルの1a[2])を見てください。 モードが設定したそのようなものがデコーダによって指定されるなら、エンコーダは、要求を守らなければならなくて、部分集合の外でモードを使用してはいけません。 プレゼントでないなら、すべてのコーデックモードがセッションのために許容されています。
mode-change-period: Specifies a number of frame-blocks, N, that is
the interval at which codec mode changes are allowed.
The initial phase of the interval is arbitrary, but
モード変化の期間: 多くのフレームブロック、N、すなわち、コーデックモード変更が許容されている間隔を指定します。 しかし、間隔の初期位相は任意です。
Sjoberg, et. al. Standards Track [Page 39] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[39ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
changes must be separated by multiples of N frame-blocks.
If this parameter is not present, mode changes are
allowed at any time during the session.
Nフレームブロックの倍数で変化を切り離さなければなりません。 このパラメタが存在していないなら、モード変更はいつでも、セッションの間、許容されています。
mode-change-neighbor: Permissible values are 0 and 1. If 1, mode
changes SHALL only be made 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、モードがSHALLを変えるなら、活動的なコーデックモードセットで隣接しているモードに単に作られてください。 モードを近所付き合いさせて、ものが次の現在のモードへのビット伝送速度、より高いかまたは次の低料金における最も近くにありますか? 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 the media
present in the packet represents. The time SHOULD be a
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, otherwise not. If crc=1, this
also implies automatically that octet-aligned operation
SHALL be used for the session.
crc: 許容値は、0と1です。 1であるなら、含まれていて、ペイロードで、そうでなければ、縁どらないところでCRCs SHALLを縁どってください。 また、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.
インターリービング: セッションとその値がインターリービンググループで許されたフレームブロックの最大数を定義するので(セクション4.4.1を見てください)フレームブロックレベルインターリービングSHALLが使用されるのを示します。 このパラメタが存在していないなら、SHALLをはさみ込んで、使用されないでください。 また、このパラメタの存在は、八重奏で並べられた操作SHALLが使用されるのを自動的に含意します。
ptime: see RFC2327 [11].
ptime: RFC2327[11]を見てください。
channels: The number of audio channels. The possible values and
their respective channel order is specified in section
4.1 in [24]. If omitted it has the default value of 1.
チャンネル: 音声チャンネルの数。 [24]のセクション4.1で有り得るのを指定してください値と彼らのそれぞれのチャンネルが、命令する。 省略されるなら、それには、1のデフォルト値があります。
Encoding considerations:
This type is defined for transfer via both RTP (RFC 1889)
and stored-file methods as described in Sections 4 and 5,
問題をコード化します: このタイプは転送のためにセクション4と5で説明されるRTP(RFC1889)と格納されたファイル方法の両方を通して定義されます。
Sjoberg, et. al. Standards Track [Page 40] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[40ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
respectively, of RFC 3267. Audio data is binary data,
and must be encoded for non-binary transport; the Base64
encoding is suitable for Email.
それぞれ、RFC3267 オーディオデータを2進のデータであり、非バイナリー輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。
Security considerations:
See Section 7 of RFC 3267.
セキュリティ問題: RFC3267のセクション7を見てください。
Public specification:
Please refer to Section 11 of RFC 3267.
公共の仕様: RFC3267のセクション11を参照してください。
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)
マジックナンバー: チャンネルを選抜してください: 「ASCII文字列」#!AMR\n」(または、16進の0x2321414d520a)マルチチャンネル: 「ASCII文字列」#!AMR_MC1.0\n」(または、16進の0x2321414d525F4D43312E300a)
File extensions: amr, AMR Macintosh file type code: none Object identifier or OID: none
ファイル拡張子: amr、AMRマッキントッシュファイルの種類コード: なにも、Object識別子かOID: なし
Person & email address to contact for further information:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
詳細のために連絡する人とEメールアドレス: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com
Intended usage: COMMON.
It is expected that many VoIP applications (as well as
mobile applications) will use this type.
意図している用法: 一般的。 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Author/Change controller:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
IETF Audio/Video transport working group
コントローラを書くか、または変えてください: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com IETF Audio/ビデオ輸送ワーキンググループ
8.2. AMR-WB MIME Registration
8.2. AMR-Wb MIME登録
The MIME subtype for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is expected to be a widely used speech codec in general VoIP applications. This MIME registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
AMR-WBが一般に、広く使用されたスピーチコーデックがVoIPアプリケーションであったなら予想されるので、IETF木からAdaptive Multi-レートWideband(AMR-WB)コーデックのためのMIME「副-タイプ」を割り当てます。 このMIME登録は格納されたファイルでRTPを通したリアルタイムの転送と非リアルタイムの転送の両方を覆っています。
Note, any unspecified parameter MUST be ignored by the receiver.
受信機で注意、どんな不特定のパラメタも無視しなければなりません。
Sjoberg, et. al. Standards Track [Page 41] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[41ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
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: Requested AMR-WB mode set. Restricts the active codec
mode set to a subset of all modes. Possible values are a
comma separated list of modes from the set: 0,...,8 (see
Table 1a [4]). If such mode set is specified by the
decoder, the encoder MUST abide by the request and MUST
NOT use modes outside of the subset. If not present, all
codec modes are allowed for the session.
モードセット: 要求されたAMR-WBモードはセットしました。 活動的なコーデックモードセットをすべてのモードの部分集合に制限します。 可能な値はセットからのモードのコンマの切り離されたリストです: 0,...8 (テーブルの1a[4])を見てください。 モードが設定したそのようなものがデコーダによって指定されるなら、エンコーダは、要求を守らなければならなくて、部分集合の外でモードを使用してはいけません。 プレゼントでないなら、すべてのコーデックモードがセッションのために許容されています。
mode-change-period: Specifies a number of frame-blocks, N, that is
the interval at which codec mode changes are allowed.
The initial phase of the interval is arbitrary, but
changes must be separated by multiples of N frame-blocks.
If this parameter is not present, mode changes are
allowed at any time during the session.
モード変化の期間: 多くのフレームブロック、N、すなわち、コーデックモード変更が許容されている間隔を指定します。 間隔の初期位相は任意ですが、Nフレームブロックの倍数で変化を切り離さなければなりません。 このパラメタが存在していないなら、モード変更はいつでも、セッションの間、許容されています。
mode-change-neighbor: Permissible values are 0 and 1. If 1, mode
changes SHALL only be made 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、モードがSHALLを変えるなら、活動的なコーデックモードセットで隣接しているモードに単に作られてください。 モードを近所付き合いさせて、ものが次の現在のモードへのビット伝送速度、より高いかまたは次の低料金における最も近くにありますか? 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 the media
present in the packet represents. The time SHOULD be a
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 42] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[42ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be
included in the payload, otherwise not. If crc=1, this
also implies automatically that octet-aligned operation
SHALL be used for the session.
crc: 許容値は、0と1です。 1であるなら、含まれていて、ペイロードで、そうでなければ、縁どらないところでCRCs SHALLを縁どってください。 また、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.
インターリービング: セッションとその値がインターリービンググループで許されたフレームブロックの最大数を定義するので(セクション4.4.1を見てください)フレームブロックレベルインターリービングSHALLが使用されるのを示します。 このパラメタが存在していないなら、SHALLをはさみ込んで、使用されないでください。 また、このパラメタの存在は、八重奏で並べられた操作SHALLが使用されるのを自動的に含意します。
ptime: see RFC2327 [11].
ptime: RFC2327[11]を見てください。
channels: The number of audio channels. The possible values and
their respective channel order is specified in section
4.1 in [24]. If omitted it has the default value of 1.
チャンネル: 音声チャンネルの数。 [24]のセクション4.1で有り得るのを指定してください値と彼らのそれぞれのチャンネルが、命令する。 省略されるなら、それには、1のデフォルト値があります。
Encoding considerations:
This type is defined for transfer via both RTP (RFC 1889)
and stored-file methods as described in Sections 4 and 5,
respectively, of RFC 3267. Audio data is binary data,
and must be encoded for non-binary transport; the Base64
encoding is suitable for Email.
問題をコード化します: このタイプは転送のためにセクション4と5でRFC3267についてそれぞれ説明されるRTP(RFC1889)と格納されたファイル方法の両方を通して定義されます。 オーディオデータを2進のデータであり、非バイナリー輸送のためにコード化しなければなりません。 Base64コード化はメールに適しています。
Security considerations:
See Section 7 of RFC 3267.
セキュリティ問題: RFC3267のセクション7を見てください。
Public specification:
Please refer to Section 11 of RFC 3267.
公共の仕様: RFC3267のセクション11を参照してください。
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)
マジックナンバー: チャンネルを選抜してください: 「ASCII文字列」#!AMR-WB\n」(または、16進の0x2321414d522d57420a)マルチチャンネル: 「ASCII文字列」#!AMR-WB_MC1.0\n」(または、16進の0x2321414d522d57425F4D43312E300a)
Sjoberg, et. al. Standards Track [Page 43] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[43ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
File extensions: awb, AWB
Macintosh file type code: none
Object identifier or OID: none
ファイル拡張子: awb、AWBマッキントッシュファイルの種類コード: なにも、Object識別子かOID: なし
Person & email address to contact for further information:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
詳細のために連絡する人とEメールアドレス: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com
Intended usage: COMMON.
It is expected that many VoIP applications (as well as
mobile applications) will use this type.
意図している用法: 一般的。 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Author/Change controller:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
IETF Audio/Video transport working group
コントローラを書くか、または変えてください: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com IETF Audio/ビデオ輸送ワーキンググループ
8.3. Mapping MIME Parameters into SDP
8.3. MIMEパラメタをSDPに写像します。
The information carried in the MIME 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:
タイプ仕様が特定のマッピングを持っているMIMEメディアで運ばれた情報はSession記述プロトコル(SDP)で[11]をさばきます。([11]は、RTPセッションについて説明するのに一般的に使用されます)。 SDPがAMRを使うセッションかAMR-WBコーデックを指定するのに使用されるとき、マッピングは以下の通りです:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- MIMEの種類(「オーディオ」)はメディア名としてSDP「m=」に行きます。
- The MIME 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 is specified in Section 4.1 in [24].
- MIME「副-タイプ」(ペイロード形式名)はコード化名としてSDP"a=rtpmap"に入ります。 "a=rtpmap"のRTPクロックレートがAMR-WBのためのAMRと16000のための8000でなければならなく、コード化パラメタ(チャンネルの数)を明らかにNに設定されなければならないか、または省略しなければなりません、1のデフォルト値を含意して。 許容されているNの値は[24]でセクション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 MIME media type string as a
semicolon separated list of parameter=value pairs.
- パラメタ=価値のセミコロンの切り離されたリストが対にされるので直接メディアタイプが結ぶMIMEからそれらをコピーすることによって、どんな残っているパラメタもSDP"a=fmtp"属性に入ります。
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線はこのドキュメントのカラム幅規制を満たすために折り重ねられます。 線の端とそれに続く復帰におけるバックスラッシュ(「\」)は無視されるべきです。
Sjoberg, et. al. Standards Track [Page 44] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[44ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
Example of usage of AMR in a possible GSM gateway scenario:
可能なGSMゲートウェイシナリオのAMRの使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-neighbor=1
a=maxptime:20
m=オーディオの49120RTP/AVP97a=rtpmap: 97 AMR/8000/1a=fmtp: 97 モードに設定された=0、2、5、7。 モード変化期間=2。 1\モード変化隣人=a=maxptime: 20
Example of usage of AMR-WB in a possible VoIP scenario:
可能なVoIPシナリオのAMR-WBの使用法に関する例:
m=audio 49120 RTP/AVP 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1
mはオーディオの49120RTP/AVP98a=rtpmapと等しいです: 98AMR-WB/16000a=fmtp: 98は=1を八重奏で並べます。
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 new MIME subtypes have been registered, see Section 8. A new SDP attribute "maxptime", defined in Section 8, has also been registered. The "maxptime" attribute is expected to be defined in the revision of RFC 2327 [11] and is added here with a consistent definition.
セクション8は、2の新しいMIME血液型亜型を登録してあるのを見ます。 また、セクション8で定義された新しいSDP属性"maxptime"を登録してあります。 "maxptime"属性は、RFC2327[11]の改正で定義されると予想されて、ここで一貫した定義で言い足されます。
10. Acknowledgements
10. 承認
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 this document.
作者はこのドキュメントの書くことと論評の間中された彼らの重要な貢献についてペトリKoskelainen、バーンハード・ウィンマー、ティムFingscheidt、Sanjayグプタ、スティーブンCasner、およびコリン・パーキンスに感謝したがっています。
11. References
11. 参照
[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)。
Sjoberg, et. al. Standards Track [Page 45] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[45ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
[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)。
[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", RFC
1889, January 1996.
[8]Schulzrinne、H、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[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. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[11] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[24] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control" RFC 1890, January 1996.
[24]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」RFC1890、1996年1月。
11.1 Informative References
11.1 有益な参照
[12] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding",
version 8.0.1 (2000-11), European Telecommunications Standards
Institute (ETSI).
[12] GSM06.60、「高められたFull Rate(EFR)スピーチコード変換」、バージョン8.0.1(2000-11)、ヨーロッパのTelecommunications Standards Institute(ETSI)。
Sjoberg, et. al. Standards Track [Page 46] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[46ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
[13] 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.
[13] ANSI/TIA/EIA136人のC師、410を分けてください--「TDMAセル/PCS--ラジオインタフェース、エンハンストフルレートはコーデック(ACELP)を声に出します」。 以前、-641です。 TIAは規格、2001年6月1日を発行しました。
[14] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication
System RCR Standard", Association of Radio Industries and
Businesses (ARIB).
[14] ARIB、RCR STD-27H、「PDC通信システムRCR規格」、電波産業会(ARIB)。
[15] Larzon, L., Degermark, M. and S. Pink, "The UDP Lite Protocol",
Work in Progress.
[15] 「UDP Liteプロトコル」というLarzon、L.、デーゲルマルク、M.、およびS.ピンクは進行中で働いています。
[16] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols",
version 4.2.0 (2001-09), 3rd Generation Partnership Project
(3GPP).
[16]3GPP TS25.415「UTRAN Iuインタフェースユーザ飛行機プロトコル」、バージョン4.2.0(2001-09)、第3Generation Partnership Project(3GPP)。
[17] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based
Congestion Control for Unicast Applications", ACM SIGCOMM 2000,
Stockholm, Sweden .
[17] S.フロイド、M.ハンドレー、J.Padhye、J.ウィトマー、「ユニキャストアプリケーションのための方程式ベースの輻輳制御」、ACM SIGCOMM2000、ストックホルム、スウェーデン。
[18] Li, A., et. al., "An RTP Payload Format for Generic FEC with
Uneven Level Protection", Work in Progress.
[18] et李、A.、アル、「不規則な平らな保護がある一般的なFECのためのRTP有効搭載量形式」、ProgressのWork。
[19] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[19] ローゼンバーグとJ.とH.Schulzrinne、「一般的な前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
[20] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[20] 3GPP TS26.102、「IuとUuへのAMRスピーチコーデックインタフェース」、バージョン4.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[21] 3GPP TS 26.202 "AMR Wideband speech codec; Interface to Iu and
Uu", version 5.0.0 (2001-03), 3rd Generation Partnership
Project (3GPP).
[21] 3GPP TS26.202「AMR Widebandスピーチコーデック」。 「IuとUuへのインタフェース」、バージョン5.0.0(2001-03)、第3Generation Partnership Project(3GPP)。
[22] Baugher, et. al., "The Secure Real Time Transport Protocol",
Work in Progress.
et[22]Baugher、アル、「安全なリアルタイムのトランスポート・プロトコル」、ProgressのWork。
[23] 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.
[23] パーキンスとC.とKouvelasとI.とホドソンとO.とハードマンとV.とハンドレーとM.とBolot、J.とベガ-ガルシアとA.とS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」RFC2198(1997年9月)。
ETSI documents can be downloaded from the ETSI web server, "http://www.etsi.org/". Any 3GPP document can be downloaded from the 3GPP webserver, "http://www.3gpp.org/", see specifications. TIA documents can be obtained from "www.tiaonline.org".
ETSIウェブサーバー、" http://www.etsi.org/ "からETSIドキュメントをダウンロードできます。 3GPP webserverからダウンロードできる3GPPが、ドキュメントであるいずれ" http://www.3gpp.org/ "も仕様を見ます。 "www.tiaonline.org"からTIAドキュメントを入手できます。
Sjoberg, et. al. Standards Track [Page 47] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[47ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
12. Authors' Addresses
12. 作者のアドレス
Johan Sjoberg Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
ジョハンシェーベリエリクソン研究エリクソンAB SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 50878230 EMail: Johan.Sjoberg@ericsson.com
以下に電話をしてください。 +46 8 50878230 メール: Johan.Sjoberg@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
マグヌスWesterlundエリクソン研究エリクソンAB SE-164 80ストックホルム(スウェーデン)
Phone: +46 8 4048287 EMail: Magnus.Westerlund@ericsson.com
以下に電話をしてください。 +46 8 4048287 メール: 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: qxie1@email.mot.com
以下に電話をしてください。 +1-847-632-3028 メールしてください: qxie1@email.mot.com
Sjoberg, et. al. Standards Track [Page 48] RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
etシェーベリ、アル。 AMRのための標準化過程[48ページ]RFC3267RTP有効搭載量形式とAMR-WB2002年6月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sjoberg, et. al. Standards Track [Page 49]
etシェーベリ、アル。 標準化過程[49ページ]
一覧
スポンサーリンク
