RFC4348 日本語訳
4348 Real-Time Transport Protocol (RTP) Payload Format for theVariable-Rate Multimode Wideband (VMR-WB) Audio Codec. S. Ahmadi. January 2006. (Format: TXT=73528 bytes) (Updated by RFC4424) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Ahmadi Request for Comments: 4348 January 2006 Category: Standards Track
Ahmadiがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4348 2006年1月のカテゴリ: 標準化過程
Real-Time Transport Protocol (RTP) Payload Format for the
Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
変動金利マルチモード広帯域(VMR-WB)オーディオコーデックのためのリアルタイムのトランスポート・プロトコル(RTP)有効搭載量形式
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.
このドキュメントは、Variable-レートMultimode Wideband(VMR-WB)スピーチコーデックに使用されるためにリアルタイムのトランスポート・プロトコル(RTP)ペイロード形式を指定します。ペイロード形式は、VMR-WB輸送が非IPネットワークでフォーマットする存在で共同利用できるように設計されています。 メディアタイプ登録はVMR-WB RTPペイロード形式のために含まれています。
VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved.
VMR-WBはそれの1つが、あるレートにおけるAMR-WB(すなわち、RFC3267)オーディオコーデックで共同利用できる多くのオペレーティング・モードを持っている変動金利マルチモード広帯域スピーチコーデックです。 したがって、本書では共同利用できるモードでVMR-WBとAMR-WBの間のデータ・パケット交換を容易にして、コード変換機能が全くかかわっていなく簡素化するのに備えました。
Ahmadi Standards Track [Page 1] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................3
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec ......4
3.1. Narrowband Speech Processing ...............................5
3.2. Continuous vs. Discontinuous Transmission ..................6
3.3. Support for Multi-Channel Session ..........................6
4. Robustness against Packet Loss ..................................7
4.1. Forward Error Correction (FEC) .............................7
4.2. Frame Interleaving and Multi-Frame Encapsulation ...........8
5. VMR-WB Voice over IP Scenarios ..................................9
5.1. IP Terminal to IP Terminal .................................9
5.2. GW to IP Terminal .........................................10
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals) ...10
5.4. GW to GW (between Two VMR-WB-Enabled Terminals) ...........11
6. VMR-WB RTP Payload Formats .....................................12
6.1. RTP Header Usage ..........................................13
6.2. Header-Free Payload Format ................................14
6.3. Octet-Aligned Payload Format ..............................15
6.3.1. Payload Structure ..................................15
6.3.2. The Payload Header .................................15
6.3.3. The Payload Table of Contents ......................18
6.3.4. Speech Data ........................................20
6.3.5. Payload Example: Basic Single Channel
Payload Carrying Multiple Frames ...................21
6.4. Implementation Considerations .............................22
6.4.1. Decoding Validation and Provision for Lost
or Late Packets ....................................22
7. Congestion Control .............................................23
8. Security Considerations ........................................23
8.1. Confidentiality ...........................................24
8.2. Authentication and Integrity ..............................24
9. Payload Format Parameters ......................................24
9.1. VMR-WB RTP Payload MIME Registration ......................25
9.2. Mapping MIME Parameters into SDP ..........................27
9.3. Offer-Answer Model Considerations .........................28
10. IANA Considerations ...........................................29
11. Acknowledgements ..............................................29
12. References ....................................................30
12.1. Normative References .....................................30
12.2. Informative References ...................................30
1. 序論…3 2. コンベンションと頭文字語…3 3. 変動金利マルチモード広帯域(VMR-WB)スピーチコーデック…4 3.1. 狭帯域スピーチ処理…5 3.2. 不連続なトランスミッションに対して連続する…6 3.3. マルチチャンネルセッションのために、サポートします。6 4. パケット損失に対する丈夫さ…7 4.1. エラー修正(FEC)を進めてください…7 4.2. インターリービングとマルチフレームカプセル化を縁どってください…8 5. VMR-WBはIPの上でシナリオを声に出します…9 5.1. IP端末へのIP端末…9 5.2. IP端末へのGW…10 5.3. GW(VMR-WBとAMR-WBによって可能にされた端末の間の)へのGW…10 5.4. GW(2台のVMR-WBによって可能にされた端末の間の)へのGW…11 6. VMR-WB RTP有効搭載量形式…12 6.1. RTPヘッダー用法…13 6.2. 無ヘッダーの有効搭載量形式…14 6.3. 八重奏で並べられた有効搭載量形式…15 6.3.1. 有効搭載量構造…15 6.3.2. 有効搭載量ヘッダー…15 6.3.3. 有効搭載量目次…18 6.3.4. スピーチデータ…20 6.3.5. 有効搭載量の例: 複数のフレームを運ぶ基本的なただ一つのチャンネル有効搭載量…21 6.4. 実装問題…22 6.4.1. 無くなっているか遅いパケットへの合法化と支給を解読します…22 7. 混雑コントロール…23 8. セキュリティ問題…23 8.1. 秘密性…24 8.2. 認証と保全…24 9. 有効搭載量形式パラメタ…24 9.1. VMR-WB RTP有効搭載量MIME登録…25 9.2. MIMEパラメタをSDPに写像します…27 9.3. 申し出答えモデル問題…28 10. IANA問題…29 11. 承認…29 12. 参照…30 12.1. 標準の参照…30 12.2. 有益な参照…30
Ahmadi Standards Track [Page 2] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[2ページ]。
1. Introduction
1. 序論
This document specifies the payload format for packetization of VMR- WB-encoded speech signals into the Real-time Transport Protocol (RTP) [3]. The VMR-WB payload formats support transmission of single and multiple channels, frame interleaving, multiple frames per payload, header-free payload, the use of mode switching, and interoperation with existing VMR-WB transport formats on non-IP networks, as described in Section 3.
このドキュメントはレアル-時間Transportプロトコル(RTP)[3]へのVMR- WBによってコード化されたスピーチ信号のpacketizationにペイロード形式を指定します。 VMR-WBペイロードは単一で複数のチャンネル、フレームインターリービング、複数の1ペイロードあたりのフレーム、無ヘッダーのペイロード、モードの切り換えの使用、およびVMR-WB輸送が非IPネットワークでフォーマットする存在があるinteroperationのサポート送信をフォーマットします、セクション3で説明されるように。
The payload format is described in Section 6. The VMR-WB file format (i.e., for transport of VMR-WB speech data in storage mode applications such as email) is specified in [7]. In Section 9, a media type registration for VMR-WB RTP payload format is provided.
ペイロード形式はセクション6で説明されます。 VMR-WBファイル形式(すなわち、メールなどのストレージモードアプリケーションにおける、VMR-WBスピーチデータの輸送のための)は[7]で指定されます。 セクション9、VMR-WB RTPペイロード形式のための登録が提供されるメディアタイプで。
Since VMR-WB is interoperable with AMR-WB at certain rates, an attempt has been made throughout this document to maximize the similarities with RFC 3267 while optimizing the payload format for the non-interoperable modes of the VMR-WB codec.
VMR-WBが、あるレートにおけるAMR-WBと共に共同利用できるので、このドキュメント中でVMR-WBコーデックの非共同利用できるモードのためにペイロード形式を最適化している間、類似性をRFC3267と共に最大にするのを試みをしました。
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 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
The following acronyms are used in this document:
以下の頭文字語は本書では使用されます:
3GPP - The Third Generation Partnership Project
3GPP2 - The Third Generation Partnership Project 2
CDMA - Code Division Multiple Access
WCDMA - Wideband Code Division Multiple Access
GSM - Global System for Mobile Communications
AMR-WB - Adaptive Multi-Rate Wideband Codec
VMR-WB - Variable-Rate Multimode Wideband Codec
CMR - Codec Mode Request
GW - Gateway
DTX - Discontinuous Transmission
FEC - Forward Error Correction
SID - Silence Descriptor
TrFO - Transcoder-Free Operation
UDP - User Datagram Protocol
RTP - Real-Time Transport Protocol
RTCP - RTP Control Protocol
MIME - Multipurpose Internet Mail Extension
SDP - Session Description Protocol
VoIP - Voice-over-IP
プロジェクト2CDMA--符号分割多重接続WCDMA--3GPP--第三世代パートナーシッププロジェクト3GPP2--第三世代パートナーシップW-CDMA方式GSM--GSM AMR-WB--適応型のマルチレート広帯域コーデックVMR-WB--変動金利マルチモード広帯域コーデックCMR--コーデックモード; 要求GW--ゲートウェイDTX--不連続なトランスミッションFEC--前進型誤信号訂正SID--沈黙記述子TrFO--無トランスコーダの操作UDP--ユーザー・データグラム・プロトコルRTP--リアルタイムのトランスポート・プロトコルRTCP--RTP制御プロトコルMIME--マルチパーパスインターネットメールエクステンションSDP--セッション記述プロトコルVoIP--Voice-over-IP
Ahmadi Standards Track [Page 3] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[3ページ]。
The term "interoperable mode" in this document refers to VMR-WB mode 3, which is interoperable with AMR-WB codec modes 0, 1, and 2.
「共同利用できるモード」という用語は本書ではVMR-WBモード3を示します。(それは、AMR-WBコーデックモード0、1、および2で共同利用できます)。
The term "non-interoperable modes" in this document refers to VMR-WB modes 0, 1, and 2.
「非共同利用できるモード」という用語は本書ではVMR-WBモード0、1、および2を示します。
The term "frame-block" is used in this document to describe the time-synchronized set of speech frames in a multi-channel VMR-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 represent exactly the same time period.
「フレームブロック」という用語は、マルチチャンネルVMR-WBセッションのときに時間で連動しているセットのスピーチフレームについて説明するのに本書では使用されます。 N-チャンネルセッションのときに特に、フレームブロックはNスピーチフレームを含むでしょう、チャンネル各人からの1、Nスピーチが縁どるすべてがまさに同じ期間を表します。
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec
3. 変動金利マルチモード広帯域(VMR-WB)スピーチコーデック
VMR-WB is the wideband speech-coding standard developed by Third Generation Partnership Project 2 (3GPP2) for encoding/decoding wideband/narrowband speech content in multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a source-controlled variable-rate multimode wideband speech codec. It has a number of operating modes, where each mode is a tradeoff between voice quality and average data rate. The operating mode in VMR-WB (as shown in Table 2) is chosen based on the traffic condition of the network and the desired quality of service. The desired average data rate (ADR) in each mode is obtained by encoding speech frames at permissible rates (as shown in Tables 1 and 3) compliant with CDMA2000 system, depending on the instantaneous characteristics of input speech and the maximum and minimum rate constraints imposed by the network operator.
VMR-WBは3G CDMAセルラ方式[1]でのマルチメディアサービスにおける広帯域/狭帯域スピーチ内容をコード化するか、または解読するためにThird Generation Partnership Project2(3GPP2)によって開発された広帯域音声符号化規格です。 VMR-WBはソース被制御変数レートマルチモード広帯域スピーチコーデックです。それには、多くのオペレーティング・モードがあります。そこでは、各モードが音声の品質と平均したデータ信号速度の間の見返りです。 VMR-WB(Table2に示されるように)のオペレーティング・モードはネットワークのトラフィック状態と必要なサービスの質に基づいて選ばれています。 CDMA2000システムによる対応することの許されているレート(Tables1と3に示されるように)でスピーチフレームをコード化することによって、各モードによる必要な平均したデータ信号速度(ADR)を得ます、入力スピーチの瞬時に起こっている特性とネットワーク・オペレータによって課された最大の、そして、最小のレート規制によって。
While VMR-WB is a native CDMA codec complying with all CDMA system requirements, it is further interoperable with AMR-WB [4,12] at 12.65, 8.85, and 6.60 kbps. This is due to the fact that VMR-WB and AMR-WB share the same core technology. This feature enables Transcoder-Free (TrFO) interconnections between VMR-WB and AMR-WB across different wireless/wireline systems (e.g., GSM/WCDMA and CDMA2000) without use of unnecessary complex media format conversion.
VMR-WBはすべてのCDMAシステム要求に従うネイティブのCDMAコーデックですが、それは12.65、8.85、および6.60キロビット毎秒におけるAMR-WB[4、12]と共にさらに共同利用できます。 これはVMR-WBとAMR-WBが同じ核の技術を共有するという事実のためです。 この特徴は異なったワイヤレス/ワイヤーラインシステム(例えば、GSM/WCDMAとCDMA2000)の向こう側に不要な複雑なメディアフォーマット変換の使用なしでVMR-WBとAMR-WBの間の自由なTranscoder(TrFO)インタコネクトを可能にします。
Note that the concept of mode in VMR-WB is different from that of AMR-WB where each fixed-rate AMR-WB codec mode is adapted to prevailing channel conditions by a tradeoff between the total number of source-coding and channel-coding bits.
VMR-WBのモードの概念がそれぞれの定率AMR-WBコーデックモードが行き渡っているチャンネル状態に適合させられるAMR-WBのものとソースコーディングとチャンネル・コーディングビットの総数の間の見返りで異なっていることに注意してください。
VMR-WB is able to transition between various modes with no degradation in voice quality that is attributable to the mode switching itself. The operating mode of the VMR-WB encoder may be switched seamlessly without prior knowledge of the decoder. Any non-interoperable mode (i.e., VMR-WB modes 0, 1, or 2) can be chosen depending on the traffic conditions (e.g., network congestion) and the desired quality of service.
VMR-WBはモードの切り換え自体に起因する音声の品質における退行なしで様々なモードの間の変遷にできます。 VMR-WBエンコーダのオペレーティング・モードはシームレスに予備知識なしにデコーダについて切り換えられるかもしれません。 交通状況(例えば、ネットワークの混雑)と必要なサービスの質によって、どんな非共同利用できるモード(すなわち、VMR-WBモード0、1、または2)も選ぶことができます。
Ahmadi Standards Track [Page 4] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[4ページ]。
While in the interoperable mode (i.e., VMR-WB mode 3), mode switching between VMR-WB modes is not allowed because there is only one AMR-WB interoperable mode in VMR-WB. Since the AMR-WB codec may request a mode change, depending on channel conditions, in-band data included in VMR-WB frame structure (see Section 8 of [1] for more details) is used during an interoperable interconnection to switch between VMR-WB frame types 0, 1, and 2 in VMR-WB mode 3 (corresponding to AMR-WB codec modes 0, 1, or 2).
1つのAMR-WBの共同利用できるモードしかVMR-WBにないので、共同利用できるモード(すなわち、VMR-WBモード3)でVMR-WBモードを切り換えるモードが許容されていませんが。 チャンネル条件によって、AMR-WBコーデックがモード変更を要求するかもしれないので、VMR-WB枠組構造(その他の詳細のための[1]のセクション8を見る)にバンドにおけるデータを含んでいるのはVMR-WBモード3(AMR-WBコーデックモード0、1、または2に対応する)でVMR-WBフレームタイプ0、1、および2を切り換えるのに共同利用できるインタコネクトの間、使用されます。
As mentioned earlier, VMR-WB is compliant with CDMA2000 system with the permissible encoding rates shown in Table 1.
先に述べたように、VMR-WBはCDMA2000システムでTable1に示される許されているコード化レートで言いなりになっています。
+---------------------------+-----------------+---------------+ | Frame Type | Bits per Packet | Encoding Rate | | | (Frame Size) | (kbps) | +---------------------------+-----------------+---------------+ | Full-Rate | 266 | 13.3 | | Half-Rate | 124 | 6.2 | | Quarter-Rate | 54 | 2.7 | | Eighth-Rate | 20 | 1.0 | | Blank | 0 | 0 | | Erasure | 0 | 0 | +---------------------------+-----------------+---------------+
+---------------------------+-----------------+---------------+ | フレームタイプ| 1パケットあたりのビット| レートをコード化します。| | | (フレーム・サイズ) | (キロビット毎秒) | +---------------------------+-----------------+---------------+ | 全額料金| 266 | 13.3 | | 半分評価してください。| 124 | 6.2 | | 4分の1レート| 54 | 2.7 | | 8番目に評価してください。| 20 | 1.0 | | 空白| 0 | 0 | | 消去| 0 | 0 | +---------------------------+-----------------+---------------+
Table 1: CDMA2000 system permissible frame types and their
associated encoding rates
テーブル1: CDMA2000のシステムの許されているフレームタイプと彼らの関連コード化レート
VMR-WB is robust to high percentage of frame loss and frames with corrupted rate information. The reception of an Erasure (SPEECH_LOST) frame type at decoder invokes the built-in frame error concealment mechanism. The built-in frame error concealment mechanism in VMR-WB conceals the effect of lost frames by exploiting in-band data and the information available in the previous frames.
VMR-WBは崩壊したレート情報でフレームの損失とフレームの高率に強健です。 デコーダのErasure(SPEECH_LOST)フレームタイプのレセプションはビルトイン・フレーム誤り補正メカニズムを呼び出します。 VMR-WBのビルトイン・フレーム誤り補正メカニズムは、バンドにおけるデータと前のフレームで利用可能な情報を利用することによって、無くなっているフレームの効果を隠します。
3.1. Narrowband Speech Processing
3.1. 狭帯域スピーチ処理
VMR-WB has the capability to operate with either 16000-Hz or 8000-Hz sampled input/output speech signals in all modes of operation [1]. The VMR-WB decoder does not require a priori knowledge about the sampling rate of the original media (i.e., speech/audio signals sampled at 8 or 16 kHz) at the input of the encoder. The VMR-WB decoder, by default, generates 16000-Hz wideband output regardless of the encoder input sampling frequency. Depending on the application, the decoder can be configured to generate 8000-Hz output, as well.
VMR-WBはすべての運転モード[1]に16000Hzの、または、8000Hz抽出された入力/出力スピーチ信号で作動する能力を持っています。 VMR-WBデコーダはエンコーダの入力のときにオリジナルのメディア(すなわち、8kHzか16kHzで抽出されたスピーチ/音声信号)の標本抽出率に関する先験的な知識を必要としません。 VMR-WBデコーダは、エンコーダ入力サンプリング周波数にかかわらずデフォルトで16000Hzの広帯域が出力であると生成します。 アプリケーションによって、また、8000Hzの出力を生成するためにデコーダを構成できます。
Ahmadi Standards Track [Page 5] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[5ページ]。
Therefore, while this specification defines a 16000-Hz RTP clock rate for VMR-WB codec, the injection and processing of 8000-Hz narrowband media during a session is also allowed; however, a 16000-Hz RTP clock rate MUST always be used.
したがって、また、この仕様がVMR-WBコーデックのために16000HzのRTPクロックレートを定義している間、セッションの間の8000Hzの狭帯域メディアの注射と処理は許されています。 しかしながら、いつも16000HzのRTPクロックレートを使用しなければなりません。
The choice of VMR-WB output sampling frequency depends on the implementation and the audio acoustic capabilities of the receiving side.
VMR-WB出力サンプリング周波数のこの選択は実装次第です、そして、受信のオーディオの音の能力に面があります。
3.2. Continuous vs. Discontinuous Transmission
3.2. 不連続なトランスミッションに対して連続しています。
The circuit-switched operation of VMR-WB within a CDMA network requires continuous transmission of the speech data during a conversation. The intrinsic source-controlled variable-rate feature of the CDMA speech codecs is required for optimal operation of the CDMA system and interference control. However, VMR-WB has the capability to operate in a discontinuous transmission mode for some packet-switched applications over IP networks (e.g., VoIP), where the number of transmitted bits and packets during silence period are reduced to a minimum. The VMR-WB DTX operation is similar to that of AMR-WB [4,12].
CDMAネットワークの中のVMR-WBの回路で切り換えられた操作は会話の間、スピーチデータの連続した伝達を必要とします。 CDMAスピーチコーデックの本質的なソース被制御変数レート機能がCDMAシステムと干渉コントロールの最適の操作に必要です。 しかしながら、VMR-WBには、沈黙の期間の伝えられたビットとパケットの数が最小限まで減少するIPネットワーク(例えば、VoIP)の上のいくつかのパケットで切り換えられたアプリケーションのための不連続な転送方式で作動する能力があります。 VMR-WB DTX操作はAMR-WB[4、12]のものと同様です。
3.3. Support for Multi-Channel Session
3.3. マルチチャンネルセッションのサポート
The octet-aligned RTP payload format defined in this document supports multi-channel audio content (e.g., a stereophonic speech session). Although VMR-WB codec itself does not support encoding of multi-channel audio content into a single bit stream, it can be used to encode and decode each of the individual channels separately.
本書では定義された八重奏で並べられたRTPペイロード書式は、マルチチャンネルがオーディオ内容(例えば、ステレオのスピーチセッション)であるとサポートします。 VMR-WBコーデック自体はマルチチャンネルオーディオ内容のコード化をただ一つのビットストリームにサポートしませんが、別々に独特のチャンネル各人をコード化して、解読するのにそれを使用できます。
To transport 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 (see Section 9.2 for more details), the number of channels is specified in the rtpmap 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 [6].
セッションセットアップのときに、バンドの外では、それぞれのフレームブロックの異なったチャンネルからセッションにおける、チャンネルの数とスピーチフレームの注文を示すのにシグナリングを使用しなければなりません。 シグナリング(その他の詳細に関してセクション9.2を見る)にSDPを使用するとき、rtpmap属性でチャンネルの数を指定します、そして、[6]で指定されるとしてのセクション4.1のチャンネルの数でそれぞれのフレームブロックで運ばれたチャンネルの注文を含意します。
Ahmadi Standards Track [Page 6] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[6ページ]。
4. Robustness against Packet Loss
4. パケット損失に対する丈夫さ
The octet-aligned payload format described in this document (see Section 6 for more details) supports several features, including forward error correction (FEC) and frame interleaving, in order to increase robustness against lost packets.
本書では(その他の詳細に関してセクション6を見る)説明された八重奏で並べられたペイロード形式はいくつかの特徴をサポートします、前進型誤信号訂正(FEC)とフレームインターリービングを含んでいて、無くなっているパケットに対して丈夫さを増強するために。
4.1. Forward Error Correction (FEC)
4.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 [8], which generates extra packets containing repair data.
以前に送られたデータの反復の簡単な体系はFECを達成することにおいて一方通行です。 別の可能な体系(より多くの帯域幅効率的である)はペイロード外部のFECを使用することです。 例えば、RFC2733[8]。(そのRFC2733は修理データを含む付加的なパケットを生成します)。
The repetition method 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 illustrates an example.
反復メソッドは現在のフレームブロックと共に以前に伝えられたフレームブロックの簡単な「再-トランスミッション」を伴います。 各ペイロードを送るためにスピーチフレームブロックを分類するのに引窓を使用することによって、これをします。 図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系列。
--+--------+--------+--------+--------+--------+--------+--------+--
| 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: 余分なトランスミッションに関する例
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 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 highest rate be used by the speech decoder.
このアプローチの使用は、セッションセットアップのときに合図するのを必要としません。 言い換えれば、スピーチ送付者は、受信機に相談しないでこの体系を使用するのを選ぶことができます。余分なフレームを含むパケットが新しいフレームだけについてパケットと異なるように見えないので、これはそうです。 どんなパケットも無くならないなら、受信機はあるタイムスタンプのために複本かフレームのバージョンを受けるかもしれません。 同じスピーチフレームの複数のバージョンが受け取られているなら、最も高いレートがスピーチデコーダによって使用されるのは、RECOMMENDEDです。
Ahmadi Standards Track [Page 7] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[7ページ]。
This redundancy scheme provides the same functionality as that described in RFC 2198, "RTP Payload for Redundant Audio Data" [10]. In most cases, the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198. 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.
この冗長体系はRFC2198のそんなに説明されるのと同じ機能性、「余分なオーディオデータのためのRTP有効搭載量」[10]を提供します。 多くの場合、このペイロード形式のメカニズムは、RFCが2198であるとサポートするために両方の終点を必要とするよりさらに効率的であって、簡単です。 時間内にプライマリの、そして、余分なencodingsの間で必要であった普及が5フレーム回より大きいなら、RFC2198の帯域幅オーバーヘッドは低いでしょう。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel (e.g., in RTCP receiver reports) or network traffic. A sender SHOULD NOT base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information. The sender is also responsible for avoiding congestion, which may be aggravated by redundant transmission (see Section 7).
送付者はチャンネル(例えば、RTCP受信機レポートの)かネットワークトラフィックに関するフィードバックに基づく適切な量の冗長を選択するのに責任があります。 CMRにおけるFECの送付者SHOULD NOT塩基選択、このパラメタとして、大部分は非IP情報に基づいてたぶん設定されました。 また、送付者も混雑を避けるのに責任があります(セクション7を見てください)。(混雑は余分なトランスミッションでいらいらさせられるかもしれません)。
4.2. Frame Interleaving and Multi-Frame Encapsulation
4.2. フレームインターリービングとマルチフレームカプセル化
To decrease protocol overhead, the octet-aligned payload format, described in Section 6, allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of this approach is that in case of packet loss several consecutive speech frame-blocks are lost, which usually causes clearly audible distortion in the reconstructed speech.
プロトコルオーバーヘッドを下げるために、セクション6で説明された八重奏で並べられたペイロード形式は、いくつかのスピーチフレームブロックが単一のRTPパケットにカプセル化されるのを許容します。 このアプローチの欠点の1つはパケット損失の場合にいくつかの連続したスピーチフレームブロックが無くなるという(通常、再建されたスピーチで明確に聞きとれるひずみを引き起こします)ことです。
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.
フレームブロックのインターリービングは、そのような場合一連の単一のフレームブロックの損失に連敗を広げることによって、スピーチ品質を改良できます。 しかしながら、いくつかの1ペイロードあたりのフレームブロックをはさみ込んで、添付するのは、また、終わりから終わりへの遅れを増強して、すべてのタイプのアプリケーションには、したがって、適切ではありません。 ストリーミング・アプリケーションは、損失性トランスミッション状態のスピーチ品質を改良するのにたぶんインターリービングを利用できるでしょう。
The octet-aligned payload format 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 9).
八重奏で並べられたペイロード形式はオプションとしてフレームインターリービングの使用をサポートします。 エンコーダ(スピーチ送付者)が当然のことのセッションに外国行きのRTPパケットでフレームインターリービングを使用するように、デコーダ(スピーチ受信機)は、バンドの出ている手段でサポートを示す必要があります(セクション9を見てください)。
Ahmadi Standards Track [Page 8] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[8ページ]。
5. VMR-WB Voice over IP Scenarios
5. VMR-WBボイス・オーバー IPシナリオ
5.1. IP Terminal to IP Terminal
5.1. IP端末へのIP端末
The primary scenario for this payload format is IP end-to-end between two terminals incorporating VMR-WB codec, as shown in Figure 2. Nevertheless, this scenario can be generalized to an interoperable interconnection between VMR-WB-enabled and AMR-WB-enabled IP terminals using the offer-answer model described in Section 9.3. This payload format is expected to be useful for both conversational and streaming services.
このペイロード形式のためのプライマリシナリオは、VMR-WBコーデックを取り入れる2台の端末の間のIPの終わりから終わりです、図2に示されるように。 それにもかかわらず、セクション9.3で説明された申し出答えモデルを使用することでVMR-WBによって可能にされてAMR-WBによって可能にされたIP端末の間の共同利用できるインタコネクトにこのシナリオを広めることができます。 このペイロード形式が会話の、そして、ストリーミングの両方のサービスの役に立つと予想されます。
+----------+ +----------+
| | | |
| TERMINAL |<----------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+----------+ +----------+
(or AMR-WB/RTP/UDP/IP)
+----------+ +----------+ | | | | | 端末| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 端末| | | VMR-Wb/RTP/UDP/IP| | +----------+ +----------+ (または、AMR-WB/RTP/UDP/IP)
Figure 2: IP terminal to IP terminal
図2: IP端末へのIP端末
A conversational service puts requirements on the payload format. Low delay is a very important factor, i.e., fewer speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses across low bandwidth links, especially if the frequency of packets will be high.
会話のサービスはペイロード形式に要件を置きます。 ペイロードパケットあたり低い遅れは非常に重要な要素、すなわち、より少ないスピーチフレームブロックです。 また、ペイロード形式が低い帯域幅の向こう側にリンクを横断するとき、低いオーバーヘッドが必要です、特にパケットの頻度が高くなるなら。
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 of packet loss 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.
ストリーミングのサービスは、会話のサービスよりそれほど厳しくないリアルタイムの要件を持って、したがって、より多くの1パケットあたりのフレームブロックを使用できます。 これはIP、UDP、およびRTPヘッダーからオーバーヘッドを下げます。 しかしながら、いくつかの1パケットあたりのフレームブロックを含んでいるのにトランスミッションがパケット損失により被害を受け易くなるので、インターリービングはスピーチ品質へのパケット損失の影響を減少させるのに使用されるかもしれません。 また、多くのクライアントを扱うストリーミングサーバはpacketizationをするときできるだけわずかなリソースを必要とするペイロード形式を必要とします。
For VMR-WB-enabled IP terminals at both ends, depending on the implementation, all modes of the VMR-WB codec can be used in this scenario. Also, both header-free and octet-aligned payload formats (see Section 6 for details) can be utilized. For the interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3 is used, and all restrictions described in Section 9.3 apply.
両端のVMR-WBによって可能にされたIP端末のために、実装によって、このシナリオでVMR-WBコーデックのすべてのモードを使用できます。 また、無ヘッダーのものと同様に八重奏で並べられたペイロード形式(詳細に関してセクション6を見る)を利用できます。 VMR-WBとAMR-WBの間の共同利用できるインタコネクトにおいて、VMR-WBモード3だけが使用されています、そして、セクション9.3で説明されたすべての制限が適用されます。
Ahmadi Standards Track [Page 9] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[9ページ]。
5.2. GW to IP Terminal
5.2. IP端末へのGW
Another scenario occurs when VMR-WB-encoded speech will be transmitted from a non-IP system (e.g., 3GPP2/CDMA2000 network) to an IP terminal, and/or vice versa, as depicted in Figure 3.
VMR-WBによってコード化されたスピーチが非IPシステム(例えば、3GPP2/CDMA2000ネットワーク)からIP端末まで送られて、逆もまた同様ですときに、別のシナリオは起こります、図3に表現されるように。
VMR-WB over
3GPP2/CDMA2000 network
+------+ +----------+
| | | |
<-------------->| GW |<---------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+------+ +----------+
|
| IP network
|
3GPP2/CDMA2000ネットワーク+の上のVMR-WB------+ +----------+ | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 端末| | | VMR-Wb/RTP/UDP/IP| | +------+ +----------+ | | IPネットワーク|
Figure 3: GW to VoIP terminal scenario
図3: VoIPの端末のシナリオへのGW
VMR-WB's capability to switch seamlessly between operational modes is exploited in CDMA (non-IP) networks to optimize speech quality for a given traffic condition. To preserve this functionality in scenarios including a gateway to an IP network using the octet-aligned payload format, a codec mode request (CMR) field is considered. 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 SHOULD accommodate the delay imposed by the IP network on the response to CMR by the IP terminal.
シームレスに操作上のモードを切り換えるVMR-WBの能力は、与えられたトラフィック状態のためにスピーチ品質を最適化するためにCDMA(非IP)ネットワークで開発されます。 八重奏で並べられたペイロード形式、コーデックモード要求(CMR)分野を使用することでIPネットワークへのゲートウェイを含んでいて、シナリオにこの機能性を保存するのは考えられます。 ゲートウェイは両方の方向で非IPとIPの部品の間にCMRを送るのに原因となるようになるでしょう。 IPの端末のSHOULDはゲートウェイによって進められた、非IPデコーダに行くスピーチ品質を最適化したCMRに続きます。 ゲートウェイSHOULDのモードコントロールアルゴリズムはIP端末によってIPネットワークによってCMRへの応答に課された遅れを収容します。
The IP terminal SHOULD NOT set the CMR (see Section 6.3.2), 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 and to perform congestion control on the IP network.
IPの端末のSHOULD NOTはCMRを設定しますが(セクション6.3.2を見てください)、ゲートウェイは非IP部分のエンコーダに向かって行くフレームのCMR値にそのエンコーダからゲートウェイまでスピーチ品質を最適化して、IPネットワークに輻輳制御を実行するように設定できます。
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals)
5.3. GWへのGW(VMR-WBとAMR-WBによって可能にされた端末の間の)
A third likely scenario is that RTP/UDP/IP 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. This is the most likely scenario for an interoperable interconnection between 3GPP/(GSM-WCDMA)/AMR-WB and 3GPP2/CDMA2000/VMR-WB-enabled mobile stations. In this scenario, the VMR-WB-enabled terminal also declares itself capable of AMR-WB with restricted mode set as described in Section 9.3. 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
3番目のありそうなシナリオはRTP/UDP/IPが2台の非IPシステムの間の輸送として使用されて、すなわち、IPがIP輸送の両側のゲートウェイで溯源されて、終えられるということです、図4で例証されるように。 これはVMR-WBによって3GPP/(GSM-WCDMA)/AMR-WBと3GPP2/CDMA2000/可能にされた移動局の間の共同利用できるインタコネクトのための最もありそうなシナリオです。 また、このシナリオでは、VMR-WBによって可能にされた端末は、それ自体はAMR-WBがセクション9.3で説明されるように設定された制限されたモードでできると宣言します。 CMR値はIPネットワーク側の上のゲートウェイによって受け取られたパケットに設定されるかもしれません。 ゲートウェイは非IP側にCMR値を送るはずです。
Ahmadi Standards Track [Page 10] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[10ページ]。
minimum of three values: (1) the CMR value it receives on the IP side; (2) a CMR value it may choose for congestion control of transmission on the IP side; and (3) the CMR value based on its estimate of reception quality on the non-IP side. The details of the traffic control algorithm are left to the implementation.
3つの値の最小限: (1) それがIP側で受けるCMR値。 (2) それがIP側におけるトランスミッションの輻輳制御に選ぶかもしれないCMR値。 (3) そして、値が基礎づけたCMRは非IPにおけるレセプション品質の見積りのときに面があります。 トラフィックコントロールアルゴリズムの詳細は実現に残されます。
VMR-WB over AMR-WB over
3GPP2/CDMA2000 network 3GPP/(GSM-WCDMA) network
3GPP2/CDMA2000ネットワーク3GPP/(GSM-WCDMA)ネットワークの上のAMR-WBの上のVMR-WB
+------+ +------+
(AMR-WB Payload) | | AMR-WB/RTP/UDP/IP| |(AMR-WB Payload)
<---------------->| GW |<---------------->| GW |<--------------->
| | | |
+------+ +------+
| IP network |
| |
+------+ +------+ (AMR-WB有効搭載量)| | AMR-Wb/RTP/UDP/IP| |(AMR-WB有効搭載量) <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| +------+ +------+ | IPネットワーク| | |
Figure 4: GW to GW scenario (AMR-WB <-> VMR-WB
interoperable interconnection)
図4: GWシナリオへのGW(AMR-WBの<->のVMR-WBの共同利用できるインタコネクト)
During and upon initiation of an interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3 can be used. There are three Frame Types (i.e., FT=0, 1, or 2; see Table 3) within this mode that are compatible with AMR-WB codec modes 0, 1, and 2, respectively. If the AMR-WB codec is engaged in an interoperable interconnection with VMR-WB, the active AMR-WB codec mode set needs to be limited to 0, 1, and 2.
開始とVMR-WBとAMR-WBの間の共同利用できるインタコネクトの開始のときに、VMR-WBモード3しか使用できません。 そこでは、このモードの中のAMR-WBと互換性がある3Frame Types(すなわち、FT=0、1、または2; Table3を見る)がそれぞれコーデックモード0、1、および2ですか? AMR-WBコーデックがVMR-WBと共に共同利用できるインタコネクトに従事しているなら、活動的なAMR-WBコーデックモードセットは、0、1、および2に制限される必要があります。
5.4. GW to GW (between Two VMR-WB-Enabled Terminals)
5.4. GWへのGW(2台のVMR-WBによって可能にされた端末の間の)
The fourth example VoIP scenario is composed of a RTP/UDP/IP 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 5. This is the most likely scenario for Mobile-Station-to-Mobile-Station (MS-to-MS) Transcoder-Free (TrFO) interconnection between two 3GPP2/CDMA2000 terminals that both use VMR-WB codec.
4番目の例のVoIPシナリオは2台の非IPシステムの間のRTP/UDP/IP輸送で構成されます。 すなわち、IPは図5で例証されるようにIP輸送の両側のゲートウェイで溯源されて、終えられます。 これはともにVMR-WBコーデックを使用する2台の3GPP2/CDMA2000端末の間のモバイル駅からモバイル駅(MSからMS)への自由なトランスコーダ(TrFO)インタコネクトのための最もありそうなシナリオです。
Ahmadi Standards Track [Page 11] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[11ページ]。
VMR-WB over VMR-WB over
3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
3GPP2/CDMA2000ネットワーク3GPP2/CDMA2000ネットワークの上のVMR-WBの上のVMR-WB
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
+------+ +------+ | | | | <、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| GW| <、-、-、-、-、-、-、-、-、-、-、--、>|、| VMR-Wb/RTP/UDP/IP| | +------+ +------+ | IPネットワーク| | |
Figure 5: GW to GW scenario (a CDMA2000 MS-to-MS VoIP scenario)
図5: GWシナリオへのGW(CDMA2000 MSからMSへのVoIPシナリオ)
6. VMR-WB RTP Payload Formats
6. VMR-WB RTP有効搭載量形式
For a given session, the payload format can be either header free or octet aligned, depending on the mode of operation that is established for the session via out-of-band means and the application.
当然のことのセッションのために、ペイロード形式がヘッダーを持つことができませんか、または八重奏は並びました、セッションのためにバンドで出ている手段で確立される運転モードとアプリケーションによって。
The header-free payload format is designed for maximum bandwidth efficiency, simplicity, and low latency. Only one codec data frame can be sent in each header-free payload format packet. None of the payload header fields or table of contents (ToC) entries is present (the same consideration is also made in [11]).
無ヘッダーのペイロード形式は最高の帯域幅効率、簡単さ、および低遅延のために設計されています。 それぞれの無ヘッダーのペイロード形式パケットで1個のコーデックデータフレームしか送ることができません。 ペイロードヘッダーフィールドか目次(ToC)エントリーのいずれも存在していません。(また、[11])で同じ考慮をします。
In the octet-aligned payload 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.
八重奏で並べられたペイロード形式では、ペイロードヘッダー、目次エントリー、およびスピーチフレーム自体を含むペイロードのすべての分野が、実現を効率的にするように個別に八重奏境界に並べられます。
Note that 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 payload formats, only the octet-aligned format has the capability to use the interleaving to make the speech transport robust to packet loss.
2つのペイロード形式の間では、八重奏で並べられた形式だけがスピーチ輸送をパケット損失に強健にするのにインターリービングを使用する能力を持っています。
The VMR-WB octet-aligned payload format in the interoperable mode is identical to that of AMR-WB (i.e., RFC 3267).
八重奏で並べられたペイロードが共同利用できるモードでフォーマットするVMR-WBはAMR-WB(すなわち、RFC3267)のものと同じです。
Ahmadi Standards Track [Page 12] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[12ページ]。
6.1. RTP Header Usage
6.1. RTPヘッダー用法
The format of the RTP header is specified in [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[3]で指定されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
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 default sampling frequency (i.e., 16 kHz), so the timestamp unit is in samples.
RTPタイムスタンプはパケットにおける最初のフレームブロックにコード化された最初のサンプルの標本抽出の瞬間に対応しています。 タイムスタンプクロック周波数がデフォルトサンプリング周波数(すなわち、16kHz)と同じであるので、タイムスタンプユニットがサンプルにあります。
The duration of one speech frame-block is 20 ms for VMR-WB. For normal wideband operation of VMR-WB, the input/output media sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 320 for VMR-WB for each consecutive frame-block.
1つのスピーチフレームブロックの持続時間はVMR-WBのための20msです。 VMR-WBの通常の広帯域操作のために、入力/アウトプット・メディアサンプリング周波数は16kHzです、各チャンネルから1フレームあたり320個のサンプルに対応しています。 したがって、タイムスタンプはVMR-WBのためにそれぞれの連続したフレームブロックに320増加します。
The VMR-WB codec is capable of processing speech/audio signals sampled at 8 kHz. By default, the VMR-WB decoder output sampling frequency is 16 kHz. Depending on the application, the decoder can be configured to generate 8-kHz output sampling frequency, as well. Since the VMR-WB RTP payload formats for the 8- and 16-kHz sampled media are identical and the VMR-WB decoder does not need a priori knowledge about the encoder input sampling frequency, a fixed RTP clock rate of 16000 Hz is defined for VMR-WB codec. This would allow injection or processing of 8-kHz sampled speech/audio media without having to change the RTP clock rate during a session. Note that the timestamp is incremented by 320 per frame-block for 8-kHz sampled media, as well.
VMR-WBコーデックはスピーチ/音声信号が8kHzで抽出した処理ができます。 デフォルトで、VMR-WBデコーダ出力サンプリング周波数は16kHzです。 アプリケーションによって、また、8kHzの出力サンプリング周波数を発生させるようにデコーダを構成できます。 8と16kHzの抽出されたメディアのためのVMR-WB RTPペイロード形式が同じであり、VMR-WBデコーダがエンコーダ入力サンプリング周波数に関する先験的な知識を必要としないので、16000Hzの固定RTPクロックレートはVMR-WBコーデックのために定義されます。セッションの間、RTPクロックレートを変える必要はなくて、これは8kHzの抽出されたスピーチ/オーディオメディアの注射か処理を許すでしょう。 タイムスタンプがまた、8kHzの抽出されたメディアのためにフレームブロックあたり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 defined in Section 6.3.2. 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 instead of breaking a multi-frame- block packet into two, as explained in Section 6.3.2.
パケットは複数のフレームブロックのコード化されたスピーチか安らぎ雑音パラメタを含むかもしれません。 インターリービングが採用しているなら、セクション6.3.2で定義されたインターリービング規則に従って、ペイロードに要約されたフレームブロックは選ばれます。 さもなければ、各パケットは1回以上の隣接の20-msフレームブロック間隔の期間をカバーしています。 期間の特定のフレームブロックすべてのチャンネルからのデータがなくなるといけないので(例えばある他の輸送形式からのゲートウェイで)、どんなデータもマルチフレームのブロックしているパケットを2に細かく分けることの代わりにそのフレームブロックに存在していないのを示すのは可能です、セクション6.3.2で説明されるように。
No matter which payload format is used, the RTP 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 header MAY be set, and padding appended, as specified in [3].
どのペイロード形式が使用されていても、RTPペイロードは、必要なら、ゼロ・ビットでそっと歩くことによって、不可欠の数の八重奏長さにいつも作られます。 追加詰め物が八重奏の、より大きい倍数かある他の目的にペイロード長をもたらすのに必要であるなら、RTPヘッダーのPビットは、セットと、[3]で指定されるように追加された詰め物であるかもしれません。
Ahmadi Standards Track [Page 13] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[13ページ]。
The RTP header marker bit (M) SHALL be always set to 0 if the VMR-WB codec operates in continuous transmission. When operating in discontinuous transmission (DTX), the RTP header marker bit 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).
VMR-WBコーデックが連続したトランスミッションで作動するなら0に設定されて、いつもRTPヘッダーマーカービット(M)SHALLはそうです。 不連続なトランスミッション(DTX)で作動するとき、RTPヘッダーマーカーはSHALLに噛み付きました。パケットで運ばれた最初のフレームブロックがスピーチフレーム(talkspurtで1番目であるもの)を含むなら、1に用意ができてください。 他のすべてのパケットに関しては、マーカーはゼロへのセットが(M=0)であったならSHALLに噛み付きました。
The assignment of an RTP payload type for this payload 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 (see Section 9).
このペイロード形式のためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 このペイロード形式が使用されているRTPプロフィールが、このコード化のためのペイロードタイプを選任するか、またはペイロードタイプによってダイナミックに制限されていることになっていると指定する(セクション9を見る)と予想されます。
6.2. Header-Free Payload Format
6.2. 無ヘッダーの有効搭載量形式
The header-free payload format is designed for maximum bandwidth efficiency, simplicity, and minimum delay. Only one speech data frame presents in each header-free payload format packet. None of the payload header fields or ToC entries is present. The encoding rate for the speech frame can be determined from the length of the speech data frame, since there is only one speech data frame in each header-free payload format.
無ヘッダーのペイロード形式は最高の帯域幅効率、簡単さ、および最小の遅れのために設計されています。 1つのスピーチデータだけがそれぞれの無ヘッダーのペイロード形式パケットでプレゼントを縁どっています。 ペイロードヘッダーフィールドかToCエントリーのいずれも存在していません。 スピーチフレームのコード化料金はスピーチデータフレームの長さから決定できます、それぞれの無ヘッダーのペイロード形式には1個のスピーチデータフレームしかないので。
The use of the RTP header fields for header-free payload format is the same as the corresponding one for the octet-aligned payload format. The detailed bit mapping of speech data packets permissible for this payload format is described in Section 8 of [1]. Since the header-free payload format is not compatible with AMR-WB RTP payload, only non-interoperable modes of VMR-WB SHALL be used with this payload format. That is, FT=0, 1, 2, and 9 SHALL NOT be used with header-free payload format.
RTPヘッダーフィールドの無ヘッダーのペイロード形式の使用は八重奏で並べられたペイロード形式のための対応するものと同じです。 このペイロード形式において、許されているスピーチデータ・パケットの詳細な噛み付いているマッピングは[1]のセクション8で説明されます。 無ヘッダーのペイロード以来、形式はAMR-WB RTPペイロードと互換性がありません、VMR-WB SHALLの非共同利用できるモードだけ。このペイロード形式と共に使用されます。 FT=0、1、2、および9SHALL NOT、それはそうです。無ヘッダーのペイロード形式と共に使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー[3]| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + 1つのスピーチだけデータフレーム+++++++++| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the mode of operation, using this payload format, is decided by the transmitting (encoder) site. The default mode of operation for VMR-WB encoder is mode 0 [1]. The mode change request MAY also be sent through non-RTP means, which is out of the scope of this specification.
このペイロード形式を使用して、運転モードが伝える(エンコーダ)サイトによって決められることに注意してください。 VMR-WBエンコーダのためのデフォルト運転モードはモード0[1]です。 また、非RTP手段でモード変更要求を送るかもしれません。(この仕様の範囲の外に手段があります)。
Ahmadi Standards Track [Page 14] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[14ページ]。
6.3. Octet-Aligned Payload Format
6.3. 八重奏で並べられた有効搭載量形式
6.3.1. Payload Structure
6.3.1. 有効搭載量構造
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 ... +----------------+-------------------+----------------
+----------------+-------------------+---------------- | 有効搭載量ヘッダー| 目次| スピーチデータ… +----------------+-------------------+----------------
6.3.2. The Payload Header
6.3.2. 有効搭載量ヘッダー
In octet-aligned payload format, 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): This indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. CMR value 15 indicates that no mode request is present, and other unused values are reserved for future use.
CMR(4ビット): これは、コーデックモード要求がこのペイロードの受信機のサイトのスピーチエンコーダに発信したのを示します。 CMR値15は、どんなモード要求も存在していないのを示します、そして、他の未使用の値は今後の使用のために予約されます。
The value of the CMR field is set according to the following table:
以下のテーブルに従って、CMR分野の値は設定されます:
+-------+----------------------------------------------------------+ | CMR | VMR-WB Operating Modes | +-------+----------------------------------------------------------+ | 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) | | 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) | | 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) | | 3 | VMR-WB mode 2 | | 4 | VMR-WB mode 1 | | 5 | VMR-WB mode 0 | | 6 | VMR-WB mode 2 with maximum half-rate encoding | | 7-14 | (reserved) | | 15 | No Preference (no mode request is present) | +-------+----------------------------------------------------------+
+-------+----------------------------------------------------------+ | CMR| VMR-WBオペレーティング・モード| +-------+----------------------------------------------------------+ | 0 | VMR-WBモード3(6.60キロビット毎秒におけるAMR-WBの共同利用できるモード)| | 1 | VMR-WBモード3(8.85キロビット毎秒におけるAMR-WBの共同利用できるモード)| | 2 | VMR-WBモード3(12.65キロビット毎秒におけるAMR-WBの共同利用できるモード)| | 3 | VMR-WBモード2| | 4 | VMR-WBモード1| | 5 | VMR-WBモード0| | 6 | 最大の半分レートコード化があるVMR-WBモード2| | 7-14 | (予約される)です。 | | 15 | Preferenceがありません(どんなモード要求も存在していません)。| +-------+----------------------------------------------------------+
Table 2: List of valid CMR values and their associated VMR-WB
operating modes
テーブル2: 有効なCMR値とそれらの関連VMR-WBオペレーティング・モードのリスト
Ahmadi Standards Track [Page 15] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[15ページ]。
R: This is a reserved bit that MUST be set to zero. The receiver MUST ignore all R bits.
R: これはゼロに設定しなければならない予約されたビットです。 受信機はすべてのRビットを無視しなければなりません。
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signaled 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 signaled. 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 signaled for the session.
インターリービングがセッションのために合図されるなら、ILLとILP分野はセッションにおける各パケットに存在していなければなりません。
The mode request received in the CMR field is valid until the next CMR is received, i.e., until 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 a payload is received with a CMR value that is not valid, the CMR MUST be ignored by the receiver.
CMR値でペイロードを受け取るなら、それは有効ではありません、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, if the network allows.
セッションのときにすべてのチャンネルに、必要なコード化モードとしてペイロードの受信機によって解釈されてください、ネットワークであるなら。マルチチャンネルセッション、CMR SHOULD、許容します。
There are two factors that affect the VMR-WB mode selection: (i) the performance of any CDMA link connected via a gateway (e.g., in a GW to IP terminal scenario), and (ii) the congestion state of an IP network. The CDMA link performance is signaled via the CMR field, which is not used by IP-only end-points. The IP network state is monitored using, for example, RTCP. A sender needs to select the operating mode to satisfy both these constraints (see Section 7).
VMR-WBモード選択に影響する2つの要素があります: (i) どんなCDMAリンクの性能もゲートウェイ(例えば、IPの端末のシナリオへのGWの)、およびIPネットワークの(ii)混雑事情で接続しました。 CDMAリンク性能はCMR分野を通って合図されます。分野はIPだけエンドポイントによって使用されません。 IPネットワーク状態は、例えばRTCPを使用することでモニターされます。 送付者は、これらの規制の両方を満たすためにオペレーティング・モードを選択する必要があります(セクション7を見てください)。
The encoder SHOULD follow a received mode request, but MAY change to a different mode if the network necessitates it, 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フィードバック情報を使用するかもしれません。
Ahmadi Standards Track [Page 16] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[16ページ]。
If interleaving option is utilized, interleaving MUST be performed on a frame-block basis, as opposed to a frame basis, in a multi-channel session.
インターリービングオプションが利用されているなら、フレームブロックベースにインターリービングを実行しなければなりません、フレーム基礎と対照的に、マルチチャンネルセッションのときに。
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,
有効搭載量s(このインタリーブグループの最初のパケット): 病気の=L、ILP=0
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
フレームブロックを運んでください: n、n+(L+1)、n+2*(L+1)…, n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
有効搭載量s+1(このインタリーブグループの2番目のパケット): ILL=L、ILP=1、Carryフレームブロック: 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,
Carry 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、Carryフレームブロック: 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). 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+N*(L+1)で始まるでしょう。 インターリービング効果が全くパケット(N)あたりのフレームブロックの数が少なくとも2でないならないでしょう。 そのうえ、フレームブロックのペイロード(N)とILL MUST NOTの値あたりの数にインタリーブグループで変えてください。 言い換えれば、インタリーブグループにおけるすべてのペイロードが、同じILLを持たなければならなくて、同じ数のスピーチフレームブロックを含まなければなりません。
The sender of the payload MUST only apply interleaving if the receiver has signaled 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 than or equal to I, i.e., N*(L+1)<=I.
インターリービングを実行するとき、送付者が適切な数のペイロード(N)あたりのフレームブロックとILLを使用しなければならないのでインタリーブグループの結果として起こるサイズが、より私以下である、すなわち、N*(L+1)<は私と等しいです。
The following example shows the ToC of three consecutive packets, each carrying 3 frame-blocks, in an interleaved two-channel session.
はさみ込まれた2チャンネルのセッションのときにそれぞれ3つのフレームブロックを運んで、以下の例は3つの連続したパケットのToCを示しています。
Ahmadi Standards Track [Page 17] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[17ページ]。
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.
ここに、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| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレームブロック1は4ブロック7を妨げます。
Packet #2 ---------
パケット#2---------
ILL=2, ILP=1:
病気の=2、ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 2 Block 5 Block 8
+----+----+----+----+----+----+ | 2L| 2R| 5L| 5R| 8L| 8R| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレームブロック2は5ブロック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| +----+----+----+----+----+----+ | <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| <、-、-、-、-、-、--、>| フレームフレームフレームブロック3は6ブロック9を妨げます。
6.3.3. The Payload Table of Contents
6.3.3. 有効搭載量目次
The table of contents (ToC) in octet-aligned payload format consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload, i.e., 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 6.3.2.
八重奏で並べられたペイロード形式の目次(ToC)は各エントリーがペイロードで運ばれたスピーチフレームに対応するToCエントリーのリストから成ります、インターリービングが使用されているとき、すなわち、ToCでのフレームブロックがほとんど時間内に連続していた状態で置かれないでしょう。 代わりに、パケットでのフレームブロックの存在と注文が中で説明されたパターンに従う、6.3、.2
Ahmadi Standards Track [Page 18] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[18ページ]。
+---------------------+ | list of ToC entries | +---------------------+
+---------------------+ | ToCエントリーのリスト| +---------------------+
A ToC entry for the octet-aligned payload format is as follows:
八重奏で並べられたペイロード形式のための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| +-+-+-+-+-+-+-+-+
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
それぞれスピーチフレームを表して、目次(ToC)はToCエントリーのリストから成ります。
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 whose value is chosen according to
Table 3.
FT(4ビット): Table3によると、値が選ばれているフレームタイプは索引をつけます。
During the interoperable mode, FT=14 (SPEECH_LOST) and
FT=15 (NO_DATA) are used to indicate frames that are
either lost or not being transmitted in this payload,
respectively. FT=14 or 15 MAY be used in the non-
interoperable modes to indicate frame erasure or blank
frame, respectively (see Section 2.1 of [1]).
共同利用できるモードの間、FT=14(SPEECH_LOST)とFT=15(いいえ_DATA)は、なくされているか、またはこのペイロードでそれぞれ伝えられていないフレームを示すのに使用されます。 FT=14か15がそれぞれフレーム消去か空白のフレームを示す非共同利用できるモードで使用されるかもしれません。([1])のセクション2.1を見てください。
If a payload with an invalid FT value is received, the
payload MUST be discarded. Note that for ToC entries
with FT=14 or 15, there will be no corresponding speech
frame in the payload.
無効のFT値に従ったペイロードが受け取られているなら、ペイロードを捨てなければなりません。 ペイロードにはFT=14か15があるToCエントリーには、どんな対応するスピーチフレームもないことに注意してください。
Depending on the application and the mode of operation
of VMR-WB, any combination of the permissible frame
types (FT) shown in Table 3 MAY be used.
VMR-WBのアプリケーションと運転モードによって、Table3で見せられた許されているフレームタイプ(FT)のどんな組み合わせも使用されるかもしれません。
Q (1 bit): Frame quality indicator. If set to 0, indicates that
the corresponding frame is corrupted. During the
interoperable mode, the receiver side (with AMR-WB
codec) should set the RX_TYPE to either SPEECH_BAD or
SID_BAD depending on the frame type (FT), if Q=0. The
VMR-WB encoder always sets Q bit to 1. The VMR-WB
decoder may ignore the Q bit.
Q(1ビット): 質のインディケータを縁どってください。 0にセットして、対応するフレームが崩壊するのを示します。 共同利用できるモードの間、受信機側(AMR-WBコーデックがある)はフレームタイプ(FT)に頼るSPEECH_BADかSID_BADのどちらかにRX_TYPEを設定するはずです、Q=0であるなら。 VMR-WBエンコーダはいつも1まで噛み付かれたQを設定します。 VMR-WBデコーダはQビットを無視するかもしれません。
P bits: Padding bits MUST be set to zero and MUST be ignored by
a receiver.
Pビット: ビットを水増しするのをゼロに設定しなければならなくて、受信機で無視しなければなりません。
Ahmadi Standards Track [Page 19] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[19ページ]。
+----+--------------------------------------------+-----------------+ | FT | Encoding Rate |Frame Size (Bits)| +----+--------------------------------------------+-----------------+ | 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 | | 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 | | 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 | | 3 | Full-Rate 13.3 kbps | 266 | | 4 | Half-Rate 6.2 kbps | 124 | | 5 | Quarter-Rate 2.7 kbps | 54 | | 6 | Eighth-Rate 1.0 kbps | 20 | | 7 | (reserved) | - | | 8 | (reserved) | - | | 9 | CNG (AMR-WB SID) | 40 | | 10 | (reserved) | - | | 11 | (reserved) | - | | 12 | (reserved) | - | | 13 | (reserved) | - | | 14 | Erasure (AMR-WB SPEECH_LOST) | 0 | | 15 | Blank (AMR-WB NO_DATA) | 0 | +----+--------------------------------------------+-----------------+
+----+--------------------------------------------+-----------------+ | フィート| レートをコード化します。|フレーム・サイズ(ビット)| +----+--------------------------------------------+-----------------+ | 0 | 共同利用できるFull-レート(AMR-WB6.60キロビット毎秒)| 132 | | 1 | 共同利用できるFull-レート(AMR-WB8.85キロビット毎秒)| 177 | | 2 | 共同利用できるFull-レート(AMR-WB12.65キロビット毎秒)| 253 | | 3 | 完全なレート13.3キロビット毎秒| 266 | | 4 | 半分レート6.2キロビット毎秒| 124 | | 5 | 4分の1レート2.7キロビット毎秒| 54 | | 6 | 第8レート1.0キロビット毎秒| 20 | | 7 | (予約される)です。 | - | | 8 | (予約される)です。 | - | | 9 | CNG(AMR-WBシド)| 40 | | 10 | (予約される)です。 | - | | 11 | (予約される)です。 | - | | 12 | (予約される)です。 | - | | 13 | (予約される)です。 | - | | 14 | 消去(AMR-Wbスピーチ_は損をしました)| 0 | | 15 | 空白です(AMR-Wbいいえ_データ)。| 0 | +----+--------------------------------------------+-----------------+
Table 3: VMR-WB payload frame types for real-time transport
テーブル3: リアルタイムの輸送のためのVMR-WBペイロードフレームタイプ
For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order. 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.
マルチチャンネルセッションのために、フレームブロックからのすべてのフレームのToCエントリーは連続したオーダーにToCに置かれます。 したがって、NチャンネルとKスピーチフレームブロックがパケットにある状態で、エントリーがToCにN*Kあるに違いありません、そして、最初のNエントリーが最初のフレームブロックからあるでしょう、Nエントリーが2番目のフレームブロックなどからある秒に。
6.3.4. Speech Data
6.3.4. スピーチデータ
Speech data of a payload contains one or more speech frames as described in the ToC of the payload.
ペイロードに関するスピーチデータはペイロードのToCで説明されるように1個以上のスピーチフレームを含んでいます。
Each speech frame represents 20 ms of speech encoded in one of the available encoding rates depending on the operation mode. The length of the speech frame is defined by the frame type in the FT field, with the following considerations:
それぞれのスピーチフレームはオペレーションモードに依存する有効なコード化レートの1つでコード化されたスピーチの20msを表します。 スピーチフレームの長さはFT分野で以下の問題でフレームタイプによって定義されます:
- 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, the
speech frames MUST be arranged one whole frame after another.
- 複数のスピーチフレームがスピーチデータに存在しているとき、スピーチフレームは別のものの後の1個の整っている全体のフレームであるに違いありません。
Ahmadi Standards Track [Page 20] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi規格はVMR-WB RTP有効搭載量形式2006年1月にRFC4348を追跡します[20ページ]。
The order and numbering notation of the speech data bits are as specified in the VMR-WB standard specification [1].
スピーチデータ・ビットの注文と付番記法がVMR-WBの標準の仕様[1]で指定されるようにあります。
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.
フレームインターリービングが選択されるなら、ペイロードは1つ八重奏、またはtwoのペイロードヘッダーと共に始まります。 1八重奏のToCエントリーのリストから成る目次はペイロードヘッダーのあとに続いています。
The speech data follows the table of contents. For the purpose of packetization, all 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.
スピーチデータは目次に従います。 packetizationの目的のために、スピーチフレームを包括するすべての八重奏をペイロードに一体にして追加します。 彼らの対応するToCエントリーがToCリストに配置されるとき、スピーチフレームは同次で梱包されます、与えられたフレームがそこにFT=14か15があるToCエントリーを持っているならそのフレームへの現在のどんなデータ八重奏にもならない例外で。
6.3.5. Payload Example: Basic Single Channel Payload Carrying Multiple
Frames
6.3.5. 有効搭載量の例: 複数のフレームを運ぶ基本的なただ一つのチャンネル有効搭載量
The following diagram shows an octet-aligned payload format from a single channel session that carries two VMR-WB Full-Rate frames (FT=3). In the payload, a codec mode request is sent (e.g., CMR=4), requesting that the encoder at the receiver's side use VMR-WB mode 1. No interleaving is used. Note that in the example below the last octet in both speech frames is padded with zeros to make them octet aligned.
以下のダイヤグラムは、それが2個のVMR-WB Full-レートフレームを運ぶのを(FT=3)ただ一つのチャンネルセッションからの八重奏で並べられたペイロード形式に示します。 ペイロードでは、(例えば、CMR=4)をコーデックモード要求に送ります、受信機の側のエンコーダがVMR-WBモード1を使用するよう要求して。 インタリーブは使用されていません。 両方のスピーチフレームにおける最後の八重奏の下における例でゼロで水増しされる、それらを八重奏にする注意は並びました。
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=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | l |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=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(8..15) | f1(16..23) | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | l |P|P|P|P|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r= f1(264,265)
l= f2(264,265)
r= f1(264,265) l= f2(264,265)
Ahmadi Standards Track [Page 21] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 21] RFC 4348 VMR-WB RTP Payload Format January 2006
6.4. Implementation Considerations
6.4. Implementation Considerations
An application implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. Therefore, an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating.
An application implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. Therefore, an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating.
To enable efficient interoperable interconnection with AMR-WB and to ensure that a VMR-WB terminal appropriately declares itself as a AMR-WB-capable terminal (see Section 9.3), it is also RECOMMENDED that a VMR-WB RTP payload implementation understand relevant AMR-WB signaling.
To enable efficient interoperable interconnection with AMR-WB and to ensure that a VMR-WB terminal appropriately declares itself as a AMR-WB-capable terminal (see Section 9.3), it is also RECOMMENDED that a VMR-WB RTP payload implementation understand relevant AMR-WB signaling.
To further ensure interoperability between various implementations of VMR-WB, implementations SHALL support both header-free and octet- aligned payload formats. Support of interleaving is optional.
To further ensure interoperability between various implementations of VMR-WB, implementations SHALL support both header-free and octet- aligned payload formats. Support of interleaving is optional.
6.4.1. Decoding Validation and Provision for Lost or Late Packets
6.4.1. Decoding Validation and Provision for Lost or Late Packets
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 to avoid potential degradation of speech quality and to invoke the VMR-WB built-in frame error concealment mechanism. Therefore, invalid packets SHALL be treated as lost packets.
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 to avoid potential degradation of speech quality and to invoke the VMR-WB built-in frame error concealment mechanism. Therefore, invalid packets SHALL be treated as lost packets.
Late packets (i.e., the unavailability of a packet when it is needed for decoding at the receiver) should be treated as lost packets. Furthermore, if the late packet is part of an interleave group, depending upon the availability of the other packets in that interleave group, decoding must be resumed from the next available frame (sequential order). In other words, the unavailability of a packet in an interleave group at a certain time should not invalidate the other packets within that interleave group that may arrive later.
Late packets (i.e., the unavailability of a packet when it is needed for decoding at the receiver) should be treated as lost packets. Furthermore, if the late packet is part of an interleave group, depending upon the availability of the other packets in that interleave group, decoding must be resumed from the next available frame (sequential order). In other words, the unavailability of a packet in an interleave group at a certain time should not invalidate the other packets within that interleave group that may arrive later.
Ahmadi Standards Track [Page 22] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 22] RFC 4348 VMR-WB RTP Payload Format January 2006
7. Congestion Control
7. Congestion Control
The general congestion control considerations for transporting RTP data apply to VMR-WB speech over RTP as well. However, the multimode capability of VMR-WB speech codec may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different operating mode.
The general congestion control considerations for transporting RTP data apply to VMR-WB speech over RTP as well. However, the multimode capability of VMR-WB speech codec may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different operating mode.
Another parameter that may impact the bandwidth demand for VMR-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 RTP/UDP/IP headers, at the expense of increased delay.
Another parameter that may impact the bandwidth demand for VMR-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 RTP/UDP/IP headers, at the expense of increased delay.
If forward error correction (FEC) is used to alleviate the 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.
If forward error correction (FEC) is used to alleviate the 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.
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any applicable RTP profile, for example, RFC 3551 [6]. This means that congestion control is required for any transmission over unmanaged best-effort networks.
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any applicable RTP profile, for example, RFC 3551 [6]. This means that congestion control is required for any transmission over unmanaged best-effort networks.
Congestion on the IP network is managed by the IP sender. 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 selecting an appropriate operating mode, but also includes adjusting the level of redundancy or number of frames per packet.
Congestion on the IP network is managed by the IP sender. 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 selecting an appropriate operating mode, but also includes adjusting the level of redundancy or number of frames per packet.
8. Security Considerations
8. Security Considerations
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile such as AVP [9] or SAVP [10].
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile such as AVP [9] or SAVP [10].
As this format transports encoded audio, the main security issues include confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used.
As this format transports encoded audio, the main security issues include confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used.
This payload format and the VMR-WB decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing; thus, they are unlikely to pose a denial-of-service threat due to the receipt of pathological data.
This payload format and the VMR-WB decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing; thus, they are unlikely to pose a denial-of-service threat due to the receipt of pathological data.
Ahmadi Standards Track [Page 23] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 23] RFC 4348 VMR-WB RTP Payload Format January 2006
8.1. Confidentiality
8.1. Confidentiality
In order to ensure confidentiality of the encoded audio, all audio data bits MUST be encrypted. There is less need to encrypt the payload header or the table of contents since they only carry information about the frame type. This information could also be useful to a third party, for example, for quality monitoring.
In order to ensure confidentiality of the encoded audio, all audio data bits MUST be encrypted. There is less need to encrypt the payload header or the table of contents since they only carry information about the frame type. This information could also be useful to a third party, for example, for quality monitoring.
The use of interleaving in conjunction with encryption can have a
negative impact on the confidentiality for a short period of time.
Consider the following packets (in brackets) containing frame numbers
as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a typical
continuous diagonal interleaving pattern). The originator wishes to
deny some participants the ability to hear material starting at time
16. Simply changing the key on the packet with the timestamp at or
after 16, and denying the new key to those participants, does not
achieve this; frames 17, 18, and 21 have been supplied in prior
packets under the prior key, and error concealment may make the audio
intelligible at least as far as frame 18 or 19, and possibly further.
The use of interleaving in conjunction with encryption can have a negative impact on the confidentiality for a short period of time. Consider the following packets (in brackets) containing frame numbers as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a typical continuous diagonal interleaving pattern). The originator wishes to deny some participants the ability to hear material starting at time 16. Simply changing the key on the packet with the timestamp at or after 16, and denying the new key to those participants, does not achieve this; frames 17, 18, and 21 have been supplied in prior packets under the prior key, and error concealment may make the audio intelligible at least as far as frame 18 or 19, and possibly further.
8.2. Authentication and Integrity
8.2. Authentication and Integrity
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits).
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits).
Data tampering by a man-in-the-middle attacker could replace audio content and also result in erroneous depacketization/decoding that could lower the audio quality. For example, tampering with the CMR field may result in speech of a different quality than desired.
Data tampering by a man-in-the-middle attacker could replace audio content and also result in erroneous depacketization/decoding that could lower the audio quality. For example, tampering with the CMR field may result in speech of a different quality than desired.
9. Payload Format Parameters
9. Payload Format Parameters
This section defines the parameters that may be used to select optional features in the VMR-WB RTP payload formats.
This section defines the parameters that may be used to select optional features in the VMR-WB RTP payload formats.
The parameters are defined here as part of the MIME subtype registration for the VMR-WB speech codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
The parameters are defined here as part of the MIME subtype registration for the VMR-WB speech codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
Ahmadi Standards Track [Page 24] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 24] RFC 4348 VMR-WB RTP Payload Format January 2006
9.1. VMR-WB RTP Payload MIME Registration
9.1. VMR-WB RTP Payload MIME Registration
The MIME subtype for the Variable-Rate Multimode Wideband (VMR-WB) audio codec is allocated from the IETF tree since VMR-WB is expected to be a widely used speech codec in multimedia streaming and messaging as well as in VoIP applications. This MIME registration only covers real-time transfers via RTP.
The MIME subtype for the Variable-Rate Multimode Wideband (VMR-WB) audio codec is allocated from the IETF tree since VMR-WB is expected to be a widely used speech codec in multimedia streaming and messaging as well as in VoIP applications. This MIME registration only covers real-time transfers via RTP.
Note, the receiver MUST ignore any unspecified parameter and use the default values instead. Also note that if no input parameters are defined, the default values will be used.
Note, the receiver MUST ignore any unspecified parameter and use the default values instead. Also note that if no input parameters are defined, the default values will be used.
Media Type name: audio
Media Type name: audio
Media subtype name: VMR-WB
Media subtype name: VMR-WB
Required parameters: none
Required parameters: none
Furthermore, if the interleaving parameter is present, the parameter "octet-align=1" MUST also be present.
Furthermore, if the interleaving parameter is present, the parameter "octet-align=1" MUST also be present.
OPTIONAL parameters:
OPTIONAL parameters:
mode-set: Requested VMR-WB operating mode set. Restricts
the active operating modes to a subset of all
modes. Possible values are a comma-separated
list of integer values. Currently, this list
includes modes 0, 1, 2, and 3 [1], but MAY be
extended in the future. If such mode-set is
specified during session initiation, the encoder
MUST NOT use modes outside of the subset. If not
present, all operating modes in the set 0 to 3 are
allowed for the session.
mode-set: Requested VMR-WB operating mode set. Restricts the active operating modes to a subset of all modes. Possible values are a comma-separated list of integer values. Currently, this list includes modes 0, 1, 2, and 3 [1], but MAY be extended in the future. If such mode-set is specified during session initiation, the encoder MUST NOT use modes outside of the subset. If not present, all operating modes in the set 0 to 3 are allowed for the session.
channels: The number of audio channels. The possible
values and their respective channel order
is specified in Section 4.1 in [6]. If
omitted, it has the default value of 1.
channels: The number of audio channels. The possible values and their respective channel order is specified in Section 4.1 in [6]. If omitted, it has the default value of 1.
octet-align: RTP payload format; permissible values are 0 and
1. If 1, octet-aligned payload format SHALL be
used. If 0 or if not present, header-free payload
format is employed (default).
octet-align: RTP payload format; permissible values are 0 and 1. If 1, octet-aligned payload format SHALL be used. If 0 or if not present, header-free payload format is employed (default).
maxptime: See RFC 3267 [4]
maxptime: See RFC 3267 [4]
Ahmadi Standards Track [Page 25] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 25] RFC 4348 VMR-WB RTP Payload Format January 2006
interleaving: Indicates that frame-block level
interleaving SHALL be used for the session.
Its value defines the maximum number of
frame-blocks allowed in an interleaving
group (see Section 6.3.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.
interleaving: Indicates that frame-block level interleaving SHALL be used for the session. Its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 6.3.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.
ptime: See RFC2327 [5]. It SHALL be at least one
frame size for VMR-WB.
ptime: See RFC2327 [5]. It SHALL be at least one frame size for VMR-WB.
dtx: Permissible values are 0 and 1. The default
is 0 (i.e., No DTX) where VMR-WB normally
operates as a continuous variable-rate
codec. If dtx=1, the VMR-WB codec will
operate in discontinuous transmission mode
where silence descriptor (SID) frames are
sent by the VMR-WB encoder during silence
intervals with an adjustable update
frequency. The selection of the SID update-rate
depends on the implementation and
other network considerations that are
beyond the scope of this specification.
dtx: Permissible values are 0 and 1. The default is 0 (i.e., No DTX) where VMR-WB normally operates as a continuous variable-rate codec. If dtx=1, the VMR-WB codec will operate in discontinuous transmission mode where silence descriptor (SID) frames are sent by the VMR-WB encoder during silence intervals with an adjustable update frequency. The selection of the SID update-rate depends on the implementation and other network considerations that are beyond the scope of this specification.
Encoding considerations:
Encoding considerations:
This type is only defined for transfer of VMR-WB-encoded data
via RTP (RFC 3550) using the payload formats specified in
Section 6 of RFC 4348.
This type is only defined for transfer of VMR-WB-encoded data via RTP (RFC 3550) using the payload formats specified in Section 6 of RFC 4348.
Security considerations:
Security considerations:
See Section 8 of RFC 4348.
See Section 8 of RFC 4348.
Public specification:
Public specification:
The VMR-WB speech codec is specified in
3GPP2 specifications C.S0052-0 version 1.0.
Transfer methods are specified in RFC 4348.
The VMR-WB speech codec is specified in 3GPP2 specifications C.S0052-0 version 1.0. Transfer methods are specified in RFC 4348.
Additional information:
Additional information:
Person & email address to contact for further information:
Person & email address to contact for further information:
Sassan Ahmadi, Ph.D. sassan.ahmadi@ieee.org
Sassan Ahmadi, Ph.D. sassan.ahmadi@ieee.org
Ahmadi Standards Track [Page 26] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 26] RFC 4348 VMR-WB RTP Payload Format January 2006
Intended usage: COMMON.
Intended usage: COMMON.
It is expected that many VoIP, multimedia messaging and
streaming applications (as well as mobile applications)
will use this type.
It is expected that many VoIP, multimedia messaging and streaming applications (as well as mobile applications) will use this type.
Author/Change controller:
Author/Change controller:
IETF Audio/Video Transport working group delegated from the IESG
IETF Audio/Video Transport working group delegated from the IESG
9.2. Mapping MIME Parameters into SDP
9.2. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the VMR-WB codec, the mapping is as follows:
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the VMR-WB codec, the mapping is as follows:
- The media type ("audio") goes in SDP "m=" as the media name.
- The media type ("audio") goes in SDP "m=" as the media name.
- The media subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
16000 for VMR-WB.
- The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for VMR-WB.
- The parameter "channels" (number of channels) MUST be either
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
[6]. The parameter "channels", if present, is specified
subsequent to the MIME subtype and RTP clock rate as an encoding
parameter in the "a=rtpmap" attribute.
- The parameter "channels" (number of channels) MUST be either 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 [6]. The parameter "channels", if present, is specified subsequent to the MIME subtype and RTP clock rate as an encoding parameter in the "a=rtpmap" attribute.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and
"a=maxptime" attributes, respectively.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- 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.
- 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.
Some examples of SDP session descriptions utilizing VMR-WB encodings follow.
Some examples of SDP session descriptions utilizing VMR-WB encodings follow.
Example of usage of VMR-WB in a possible VoIP scenario (wideband audio):
Example of usage of VMR-WB in a possible VoIP scenario (wideband audio):
m=audio 49120 RTP/AVP 98
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
m=audio 49120 RTP/AVP 98 a=rtpmap:98 VMR-WB/16000 a=fmtp:98 octet-align=1
Ahmadi Standards Track [Page 27] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 27] RFC 4348 VMR-WB RTP Payload Format January 2006
Example of usage of VMR-WB in a possible streaming scenario (two channel stereo):
Example of usage of VMR-WB in a possible streaming scenario (two channel stereo):
m=audio 49120 RTP/AVP 99
a=rtpmap:99 VMR-WB/16000/2
a=fmtp:99 octet-align=1; interleaving=30
a=maxptime:100
m=audio 49120 RTP/AVP 99 a=rtpmap:99 VMR-WB/16000/2 a=fmtp:99 octet-align=1; interleaving=30 a=maxptime:100
9.3. Offer-Answer Model Considerations
9.3. Offer-Answer Model Considerations
To achieve good interoperability for the VMR-WB RTP payload in an Offer-Answer negotiation usage in SDP [13], the following considerations are made:
To achieve good interoperability for the VMR-WB RTP payload in an Offer-Answer negotiation usage in SDP [13], the following considerations are made:
- The rate, channel, and payload configuration parameters (octet-
align and interleaving) SHALL be used symmetrically, i.e., offer
and answer must use the same values. The maximum size of the
interleaving buffer is, however, declarative, and each agent
specifies the value it supports to receive for recvonly and
sendrecv streams. For sendonly streams, the value indicates what
the agent desires to use.
- The rate, channel, and payload configuration parameters (octet- align and interleaving) SHALL be used symmetrically, i.e., offer and answer must use the same values. The maximum size of the interleaving buffer is, however, declarative, and each agent specifies the value it supports to receive for recvonly and sendrecv streams. For sendonly streams, the value indicates what the agent desires to use.
- To maintain interoperability among all implementations of VMR-WB
that may or may not support all the codec's modes of operation, the
operational modes that are supported by an implementation MAY be
identified at session initiation. The mode-set parameter is
declarative, and only operating modes that have been indicated to
be supported by both ends SHALL be used. If the answerer is not
supporting any of the operating modes provided in the offer, the
complete payload type declaration SHOULD be rejected by removing it
from the answer.
- To maintain interoperability among all implementations of VMR-WB that may or may not support all the codec's modes of operation, the operational modes that are supported by an implementation MAY be identified at session initiation. The mode-set parameter is declarative, and only operating modes that have been indicated to be supported by both ends SHALL be used. If the answerer is not supporting any of the operating modes provided in the offer, the complete payload type declaration SHOULD be rejected by removing it from the answer.
- The remaining parameters are all declarative; i.e., for sendonly
streams they provide parameters that the agent desires to use,
while for recvonly and sendrecv streams they declare the parameters
that it accepts to receive. The dtx parameter is used to indicate
DTX support and capability, while the media sender is only
RECOMMENDED to send using the DTX in these cases. If DTX is not
supported by the media sender, it will send media without DTX; this
will not affect interoperability only the resource consumption.
- The remaining parameters are all declarative; i.e., for sendonly streams they provide parameters that the agent desires to use, while for recvonly and sendrecv streams they declare the parameters that it accepts to receive. The dtx parameter is used to indicate DTX support and capability, while the media sender is only RECOMMENDED to send using the DTX in these cases. If DTX is not supported by the media sender, it will send media without DTX; this will not affect interoperability only the resource consumption.
- Both header-free and octet-aligned payload format configurations
MAY be offered by a VMR-WB enabled terminal. However, for an
interoperable interconnection with AMR-WB, only octet-aligned
- Both header-free and octet-aligned payload format configurations MAY be offered by a VMR-WB enabled terminal. However, for an interoperable interconnection with AMR-WB, only octet-aligned
- The parameters "maxptime" and "ptime" should in most cases not
affect the interoperability; however, the setting of the parameters
can affect the performance of the application.
- The parameters "maxptime" and "ptime" should in most cases not affect the interoperability; however, the setting of the parameters can affect the performance of the application.
Ahmadi Standards Track [Page 28] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 28] RFC 4348 VMR-WB RTP Payload Format January 2006
- To maintain interoperability with AMR-WB in cases where negotiation
is possible using the VMR-WB interoperable mode, a VMR-WB-enabled
terminal SHOULD also declare itself capable of AMR-WB with limited
mode set (i.e., only AMR-WB codec modes 0, 1, and 2 are allowed)
and of octet-align mode of operation.
- To maintain interoperability with AMR-WB in cases where negotiation is possible using the VMR-WB interoperable mode, a VMR-WB-enabled terminal SHOULD also declare itself capable of AMR-WB with limited mode set (i.e., only AMR-WB codec modes 0, 1, and 2 are allowed) and of octet-align mode of operation.
Example:
Example:
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; mode-set=0,1,2
m=audio 49120 RTP/AVP 98 99 a=rtpmap:98 VMR-WB/16000 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 octet-align=1; mode-set=0,1,2
An example of offer-answer exchange for the VoIP scenario described in Section 5.3 is as follows:
An example of offer-answer exchange for the VoIP scenario described in Section 5.3 is as follows:
CDMA2000 terminal -> WCDMA terminal Offer:
m=audio 49120 RTP/AVP 98 97
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1
CDMA2000 terminal -> WCDMA terminal Offer: m=audio 49120 RTP/AVP 98 97 a=rtpmap:98 VMR-WB/16000 a=fmtp:98 octet-align=1 a=rtpmap:97 AMR-WB/16000 a=fmtp:97 mode-set=0,1,2; octet-align=1
WCDMA terminal -> CDMA2000 terminal Answer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1;
WCDMA terminal -> CDMA2000 terminal Answer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR-WB/16000 a=fmtp:97 mode-set=0,1,2; octet-align=1;
For declarative use of SDP such as in SAP [14] and RTSP [15], all parameters are declarative and provide the parameters that SHALL be used when receiving and/or sending the configured stream.
For declarative use of SDP such as in SAP [14] and RTSP [15], all parameters are declarative and provide the parameters that SHALL be used when receiving and/or sending the configured stream.
10. IANA Considerations
10. IANA Considerations
The IANA has registered one new MIME subtype (audio/VMR-WB); see Section 9.
The IANA has registered one new MIME subtype (audio/VMR-WB); see Section 9.
11. Acknowledgements
11. Acknowledgements
The author would like to thank Redwan Salami of VoiceAge Corporation, Ari Lakaniemi of Nokia Inc., and IETF/AVT chairs Colin Perkins and Magnus Westerlund for their technical comments to improve this document.
The author would like to thank Redwan Salami of VoiceAge Corporation, Ari Lakaniemi of Nokia Inc., and IETF/AVT chairs Colin Perkins and Magnus Westerlund for their technical comments to improve this document.
Also, the author would like to acknowledge that some parts of RFC 3267 [4] and RFC 3558 [11] have been used in this document.
Also, the author would like to acknowledge that some parts of RFC 3267 [4] and RFC 3558 [11] have been used in this document.
Ahmadi Standards Track [Page 29] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 29] RFC 4348 VMR-WB RTP Payload Format January 2006
12. References
12. References
12.1. Normative References
12.1. Normative References
[1] 3GPP2 C.S0052-0 v1.0 "Source-Controlled Variable-Rate Multimode
Wideband Speech Codec (VMR-WB) Service Option 62 for Spread
Spectrum Systems", 3GPP2 Technical Specification, July 2004.
[1] 3GPP2 C.S0052-0 v1.0 "Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB) Service Option 62 for Spread Spectrum Systems", 3GPP2 Technical Specification, July 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[4] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "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", RFC 3267, June 2002.
[4] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "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", RFC 3267, June 2002.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
12.2. Informative References
12.2. Informative References
[7] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia
Services", 3GPP2 Technical Specification, September 2005.
[7] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia Services", 3GPP2 Technical Specification, September 2005.
[8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[10] 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.
[10] 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.
[11] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[11] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[12] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled
Rate operation", version 5.0.0 (2001-03), 3rd Generation
Partnership Project (3GPP).
[12] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
Ahmadi Standards Track [Page 30] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 30] RFC 4348 VMR-WB RTP Payload Format January 2006
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
Any 3GPP2 document can be downloaded from the 3GPP2 web server, "http://www.3gpp2.org/", see specifications.
Any 3GPP2 document can be downloaded from the 3GPP2 web server, "http://www.3gpp2.org/", see specifications.
Author's Address
Author's Address
Dr. Sassan Ahmadi EMail: sassan.ahmadi@ieee.org
Dr. Sassan Ahmadi EMail: sassan.ahmadi@ieee.org
Ahmadi Standards Track [Page 31] RFC 4348 VMR-WB RTP Payload Format January 2006
Ahmadi Standards Track [Page 31] RFC 4348 VMR-WB RTP Payload Format January 2006
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
Ahmadi Standards Track [Page 32]
Ahmadi Standards Track [Page 32]
一覧
スポンサーリンク
