RFC4788 日本語訳
4788 Enhancements to RTP Payload Formats for EVRC Family Codecs. Q.Xie, R. Kapoor. January 2007. (Format: TXT=42216 bytes) (Updates RFC3558) (Updated by RFC5188) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Q. Xie
Request for Comments: 4788 Motorola
Updates: 3558 R. Kapoor
Category: Standards Track Qualcomm
January 2007
コメントを求めるワーキンググループQ.シェ要求をネットワークでつないでください: 4788のモトローラアップデート: 3558年のR.カプールカテゴリ: 標準化過程クアルコム2007年1月
Enhancements to RTP Payload Formats for EVRC Family Codecs
EVRC家族コーデックのためのRTP有効搭載量形式への増進
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth.
このドキュメントはいくつかの増進と拡大を伴うRFC3558で定義されたEnhanced Variable Rate Codec(EVRC)RTPペイロード書式をアップデートします。 特に、それはヘッダーなしのサポートとEVRC-Bコーデック、EVRCとEVRC-Bコーデックのための新しいコンパクトな束ねられた形式、およびEVRCとRTPを通して輸送されたEVRC-Bによってコード化されたスピーチの不連続なトランスミッション(DTX)サポートのためのはさみ込まれたか束ねられたパケット・フォーマットを定義します。 低い帯域幅ダイヤルアップの上で作動するボイス・オーバー IP(VoIP)アプリケーションとワイヤレス・ネットワークは帯域幅の効率的な使用のためのそのような増進を必要とします。
Xie & Kapoor Standards Track [Page 1] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3
1.2. Compact (Header-free) Bundled Format . . . . . . . . . . . 3
1.3. Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 5
4.1. Single-Rate Operation . . . . . . . . . . . . . . . . . . 5
5. Storage Format for EVRC-B Codec . . . . . . . . . . . . . . . 6
6. Media Type Definitions . . . . . . . . . . . . . . . . . . . . 6
6.1. Registration of Media Type EVRC1 . . . . . . . . . . . . . 6
6.2. Registration of Media Type EVRCB . . . . . . . . . . . . . 9
6.3. Registration of Media Type EVRCB0 . . . . . . . . . . . . 11
6.4. Registration of Media Type EVRCB1 . . . . . . . . . . . . 12
6.5. Updated Registration of Media Type EVRC . . . . . . . . . 13
6.6. Updated Registration of Media Type EVRC0 . . . . . . . . . 15
6.7. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 17
6.8. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18
7. Backward Compatibility with RFC 3558 . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 EVRC-Bコーデック. . . . . . . . . . . . . . . . . 3 1.2のサポート。 コンパクトな(ヘッダーなしの)束ねられた形式. . . . . . . . . . . 3 1.3。 不連続なトランスミッション(DTX。). . . . . . . . . . . . . 4 2 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 5 3。 EVRC-Bコーデック. . . . . . . . . . . . . . . . . . . . . . . . . 5 4。 コンパクトな束ねられた形式. . . . . . . . . . . . . . . . . . . . 5 4.1。 単一賃率操作. . . . . . . . . . . . . . . . . . 5 5。 EVRC-Bコーデック. . . . . . . . . . . . . . . 6 6のための格納形式。 メディアは定義. . . . . . . . . . . . . . . . . . . . 6 6.1をタイプします。 メディアタイプEVRC1. . . . . . . . . . . . . 6 6.2の登録 メディアタイプEVRCB. . . . . . . . . . . . . 9 6.3の登録 メディアタイプEVRCB0. . . . . . . . . . . . 11 6.4の登録 メディアタイプEVRCB1. . . . . . . . . . . . 12 6.5の登録 メディアタイプEVRC. . . . . . . . . 13 6.6の登録をアップデートしました。 メディアタイプEVRC0. . . . . . . . . 15 6.7の登録をアップデートしました。 MIMEパラメタをSDP. . . . . . . . . . . . . 17 6.8に写像します。 申し出/答え. . . . . . . . . . . . . . . . . . 18 7における用法。 RFC3558.198との後方の互換性。 IANA問題. . . . . . . . . . . . . . . . . . . . . 19 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 19 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 20 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 20
Xie & Kapoor Standards Track [Page 2] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[2ページ]。
1. Introduction
1. 序論
This document defines support for the header-free and interleaved/ bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such EVRC RTP payload capabilities for efficient use of the bandwidth.
このドキュメントはヘッダーなしのサポートとEVRC-Bコーデック、EVRCとEVRC-Bコーデックのための新しいコンパクトな束ねられた形式、およびEVRCとRTPを通して輸送されたEVRC-Bによってコード化されたスピーチの不連続なトランスミッション(DTX)サポートのためのはさみ込まれたか束ねられたパケット・フォーマットを定義します。 低い帯域幅ダイヤルアップの上で作動するボイス・オーバー IP(VoIP)アプリケーションとワイヤレス・ネットワークは帯域幅の効率的な使用のためにそのようなEVRC RTPペイロード能力を必要とします。
1.1. Support of EVRC-B Codec
1.1. EVRC-Bコーデックのサポート
EVRC-B [3] is an extension to EVRC [2] developed in the Third Generation Partnership Project 2 (3GPP2). EVRC-B [3] compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech input into output frames of one of the four different sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 bits). In addition, there are two zero-bit codec frame types: null frames and erasure frames, similar to EVRC [2]. One significant enhancement in EVRC-B is the use of 1/4-rate frames that were not used in EVRC. This provides lower average data rates (ADRs) compared to EVRC, for a given voice quality.
EVRC-B[3]はThird Generation Partnership Project2(3GPP2)で開発されたEVRC[2]への拡大です。 EVRC-B[3]は8000Hzの各20人のミリセカンドを圧縮します、4つの異なったサイズの1つの出力フレームに入力された16ビットの抽出されたスピーチ: 1(171ビット)、Rate1/2(80ビット)、Rate1/4(40ビット)、またはRate1/8(16ビット)を評定してください。 さらに、2ゼロ・ビットのコーデックフレームタイプがあります: EVRC[2]と同様のヌルフレームと消去フレーム。 EVRC-Bでの1つの重要な増進はEVRCで使用されなかった1/4レートのフレームの使用です。 与えられた音声の品質のためにEVRCと比べて、これは下側の平均したデータ信号速度(ADRs)を提供します。
Since speech frames encoded by EVRC-B are different from those encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each other. At the initiation of an RTP session, the RTP sender and receiver need to indicate (e.g., using MIME subtypes that are separate from those of EVRC) that EVRC-B is to be used for the ensuing session.
EVRC-Bによってコード化されたスピーチフレームがEVRCによってコード化されたものと異なっているので、EVRC-BとEVRCコーデックは互いと共に共同利用しません。 RTPセッションの手引きで、RTP送付者と受信機は、EVRC-Bが続くセッションに使用されることになっているのを示す(例えば、MIME血液型亜型を使用して、EVRCのものから分離してください)必要があります。
1.2. Compact (Header-free) Bundled Format
1.2. コンパクトな(ヘッダーなしの)束ねられた形式
The current interleaved/bundled packet format defined in RFC 3558 allows bundling of multiple speech frames of different rates in a single RTP packet, sending mode change requests, and interleaving. To support these functions, a Table of Contents (ToC) is used in each RTP packet, in addition to the standard RTP header. The size of the ToC varies depending on the number of EVRC frames carried in the packet [4].
単一のRTPパケットにRFC3558で定義された現在のはさみ込まれたか束ねられたパケット・フォーマットで異なったレートの複数のスピーチフレームを荷物をまとめさせます、要求、およびインターリービングをモード変更に送って。 これらの機能をサポートするのに、目次(ToC)はそれぞれのRTPパケットで使用されます、標準のRTPヘッダーに加えて。 パケット[4]で運ばれたEVRCフレームの数によって、ToCのサイズは異なります。
The current header-free packet format defined in RFC 3558 is more compact and optimized for use over wireless links. It eliminates the need for a ToC by requiring that each RTP packet contain only one speech frame (of any allowable rate), i.e., bundling is not allowed. Moreover, interleaving and mode change requests are not supported in the header-free format [4].
RFC3558で定義された現在の無ヘッダーのパケット・フォーマットは、よりコンパクトで無線のリンクの上の使用のために最適化されています。 それぞれのRTPパケットが1個のスピーチフレーム(どんな許容できるレートのも)だけを含むのを必要とすることによって、それはToCの必要性を排除します、すなわち、バンドリングが許容されていません。 そのうえ、インターリービングとモード変更要求は無ヘッダーの形式[4]で支持されません。
Xie & Kapoor Standards Track [Page 3] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[3ページ]。
The compact bundled format described in this document presents the user an alternative to the header-free format defined in RFC 3558. This format allows bundling of multiple EVRC or EVRC-B frames without the addition of extra headers, as would be in the case of the interleaved/bundled format. However, in order to use this compact bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can be used in the session. Similar to the header-free format defined in RFC 3558, interleaving and mode change requests are not supported in the compact bundled format.
本書では説明されたコンパクトな束ねられた形式はRFC3558で定義された無ヘッダーの書式への代替手段をユーザに提示します。 この形式はエキストラの添加のないEVRCかEVRC-Bフレームヘッダーを倍数のバンドリングに許容します、はさみ込まれたか束ねられた形式の場合にあるだろうというとき。 しかしながら、このコンパクトな束ねられた形式を使用するために、セッションのときに1つのEVRC/EVRC-Bレート(全額料金か1/2レート)しか使用できません。 RFC3558で定義された無ヘッダーの書式と同様です、インターリービングとモード変更要求はコンパクトな束ねられた形式で支持されません。
1.3. Discontinuous Transmission (DTX)
1.3. 不連続なトランスミッション(DTX)
Information carried in frames of EVRC and EVRC-B codecs varies little during periods of silence. The transmission of these frames across the radio interface in a wireless system is expensive, in terms of capacity; therefore, suppression of these frames is desirable. Such an operation is called DTX, also known as silence suppression.
EVRCとEVRC-Bコーデックのフレームで運ばれた情報は沈黙の期間、少ししか変えません。 ワイヤレスシステムのラジオインタフェースの向こう側のこれらのフレームのトランスミッションは容量で高価です。 したがって、これらのフレームの抑圧は望ましいです。 そのような操作は、DTXと呼ばれて、また、沈黙抑圧として知られています。
In general, when DTX/silence suppression is applied, the first few frames of silence may be transmitted at the beginning of the period of silence to establish background noise. Then, a portion of the stream of subsequent silence frames is not transmitted, and is discarded at the sender. At the receiver, background or comfort noise may be generated by using the previously received silence frames.
DTX/沈黙抑圧が沈黙の期初に適用されているとき、一般に、沈黙のわずかな最初のフレームが、バックグラウンドノイズを証明するために伝えられるかもしれません。 次に、その後の沈黙フレームの流れの一部が、伝えられないで、送付者で捨てられます。 受信機では、バックグラウンドか安らぎ雑音が、以前に容認された沈黙フレームを使用することによって、発生するかもしれません。
The full detail of DTX/silence suppression operation can be found in DTX [8] as well as in RFC 3551 [9], and in RFC 3558 [4]. This document only defines the additional optional MIME parameters (silencesupp, dtxmax, dtxmin, and hangover) for setting up a DTX/ silence suppression session, where "silencesupp" is for indicating the capability and willingness of using DTX/silence suppression; "dtxmax" and "dtxmin", for indicating the desired range of DTX update interval; and "hangover", for indicating the desired number of silence frames at the beginning of each silence period to establish background noise at the receiver (see Section 6.1 for detailed definition).
DTX[8]、RFC3551[9]、およびRFC3558[4]でDTX/沈黙抑圧操作の一部始終を見つけることができます。 このドキュメントはDTX/沈黙抑圧セッションをセットアップするための追加任意のMIMEパラメタ(silencesupp、dtxmax、dtxmin、および二日酔い)を定義するだけです。そこに"silencesupp"が能力と意欲を示すためにDTX/沈黙抑圧を使用することであります。 必要な範囲のDTXアップデート間隔を示すための"dtxmax"と"dtxmin"。 そして、それぞれの沈黙の期間の始めに受信機(詳細な定義に関してセクション6.1を見る)でバックグラウンドノイズを証明するために沈黙フレームの必要な数を示すための「二日酔い。」
The EVRC and EVRC-B codecs, in variable-rate operation mode, send 1/8-rate frames during periods of silence, while in single-rate operation mode (see Section 4), silence is encoded and sent in frames of the same rate as that of speech frames. The DTX parameters defined in this document apply to 1/8-rate frames in the variable- rate mode and to silence frames in the single-rate operation mode.
変動金利オペレーションモードで、EVRCとEVRC-Bコーデックは沈黙の期間、1/8レートのフレームを送ります、単一賃率オペレーションモード(セクション4を見る)で、スピーチフレームのものと同じレートのフレームで沈黙をコード化して、送りますが。 本書では定義されたDTXパラメタは単一賃率オペレーションモードで可変レートモードによる1/8レートのフレームと、そして、沈黙フレームに適用されます。
For simplicity, in the rest of this document the term "silence frame" refers either to an 1/8-rate frame in variable-rate operation or a frame that contains only silence in the signal-rate operation.
簡単さについて、このドキュメントの残りでは、「沈黙フレーム」という用語は変動金利操作における1/8レートのフレームか信号レート操作における沈黙だけを含むフレームについて言及します。
Xie & Kapoor Standards Track [Page 4] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[4ページ]。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. EVRC-B Codec
3. EVRC-Bコーデック
Three RTP packet formats are supported for the EVRC-B codec: the interleaved/bundled packet format, the header-free packet format, and the compact bundled packet format. For the interleaved/bundled and header-free packet formats, the operational details and capabilities, such as ToC, interleaving, and bundling, of EVRC-B, are exactly the same as those of EVRC, as defined in RFC 3558 [4], except that the mode change request field in the ToC MUST be interpreted according to the definition of the RATE_REDUC parameter in EVRC-B [3]. The compact bundled packet format for EVRC-B is defined in Section 4 of this document.
3つのRTPパケット・フォーマットがEVRC-Bコーデックのために支持されます: はさみ込まれたか束ねられたパケット・フォーマット、無ヘッダーのパケット・フォーマット、およびコンパクトな束ねられたパケット・フォーマット。 ToCなどのはさみ込まれるか束ねにされる、無ヘッダーのパケット・フォーマット、操作上の詳細、および能力には、EVRC-Bのインターリービング、およびバンドリングはまさにEVRCのものと同じです、RFC3558[4]で定義されるように、EVRC-B[3]とのRATE_REDUCパラメタの定義に従ってToCのモード変更要求分野を解釈しなければならないのを除いて。 EVRC-Bに、コンパクトな束ねられたパケット・フォーマットはこのドキュメントのセクション4で定義されます。
4. Compact Bundled Format
4. コンパクトな束ねられた形式
A packet in the compact bundled format consists of an RTP header, followed by a sequence of one or more consecutive EVRC/EVRC-B codec data frames of the same rate, as shown below:
コンパクトな束ねられた形式のパケットは以下に示されるように同じレートの1個以上の連続したEVRC/EVRC-Bコーデックデータフレームの系列があとに続いたRTPヘッダーから成ります:
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 [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| One or more EVRC/EVRC-B data frames of same rate |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー[4]| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | 同じレートの1個以上のEVRC/EVRC-Bデータフレーム| | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The codec data frames MUST be generated from the output of the codec following the procedure described in Section 5.2 in RFC 3558 [4], and all MUST be of the same rate and size.
コーデックデータフレームは手順に従うのがRFC3558[4]でセクション5.2で説明したコーデックの出力から発生しなければなりません、そして、すべてが同じレートとサイズのものであるに違いありません。
4.1. Single-Rate Operation
4.1. 単一賃率操作
As mentioned earlier, in order to use the compact bundled format, all the EVRC/EVRC-B data frames in the session MUST be of the same rate. This packet format may carry only full or half-rate frames.
先に述べたように、セッションにおけるすべてのEVRC/EVRC-Bデータフレームが、コンパクトな束ねられた形式を使用する同じレートのものであるに違いありません。 このパケット・フォーマットは、いっぱいだけに運ぶか、またはフレームを半分評定するかもしれません。
Xie & Kapoor Standards Track [Page 5] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[5ページ]。
For a session that uses the compact bundled format, the rate for the session can be determined during the session setup signaling, for example, via Session Description Protocol (SDP) exchanges. See Section 6 below for more details.
コンパクトな束ねられた形式を使用するセッションのために、例えば、セッションセットアップシグナリングの間、Session記述プロトコル(SDP)交換でセッションの速度を測定できます。 その他の詳細に関して以下のセクション6を見てください。
5. Storage Format for EVRC-B Codec
5. EVRC-Bコーデックのための格納形式
The storage format is used for storing EVRC-B-encoded speech frames, e.g., as a file or e-mail attachment.
格納形式は、例えば、ファイルか電子メールの添付ファイルとしてEVRC-Bによってコード化されたスピーチフレームを格納するのに使用されます。
The file begins with a magic number to identify the vocoder that is used. The magic number for EVRC-B corresponds to the ASCII character string:
ファイルはマジックナンバーで使用されたボコーダを特定し始めます。 EVRC-BのためのマジックナンバーはASCII文字列に対応しています:
"#!EVRC-B\n"
(or 0x2321 0x4556 0x5243 0x2d42 0x0a in hexadecimal).
「#!EVRC-B\n」、(0×2321、0×4556、16進の0×5243 0x2d42 0x0a)
Note that the "\n" is an important part of both this magic number and the "#!EVRC\n" magic number defined in Section 11 of RFC 3558, and the "\n" MUST be included in any comparison of either magic number, since, otherwise, a prefix of the EVRC-B magic number could be mistaken for the EVRC magic number.
そして、そして、「それに注意してください、」 \n」が両方のこのマジックナンバーの重要な部分である、」 #!n」マジックナンバーがRFC3558のセクション11で定義したEVRC\、」 どちらかのマジックナンバーのどんな比較にも\n」を含まなければなりません、さもなければ、EVRC-Bマジックナンバーの接頭語をEVRCマジックナンバーに間違えることができたので。
The codec data frames are stored in consecutive order, with a single ToC entry field, extended to one octet, prefixing each codec data frame. The ToC field, as defined in Section 5.1 of [4], is extended to one octet by setting the four most significant bits of the octet to zero. For example, a ToC value of 4 (a full-rate frame) is stored as 0x04.
コーデックデータフレームは連続したオーダーに格納されます、それぞれのコーデックデータフレームを前に置く1つの八重奏まで広げられたただ一つのToCエントリー分野で。 [4]のセクション5.1で定義されるToC分野は、八重奏の4つの最上位ビットをゼロに設定することによって、1つの八重奏まで広げられます。 例えば、4(全額料金フレーム)のToC値は0×04として格納されます。
Speech frames lost in transmission and non-received frames MUST be stored as erasure frames to maintain synchronization with the original media.
オリジナルのメディアとの同期を維持するために消去フレームとしてトランスミッションでなくされたスピーチフレームと非容認されたフレームを格納しなければなりません。
6. Media Type Definitions
6. メディア型定義
6.1. Registration of Media Type EVRC1
6.1. メディアタイプEVRC1の登録
Type name: audio
型名: オーディオ
Subtype names: EVRC1
Subtype名: EVRC1
Required parameters: none
必要なパラメタ: なし
Xie & Kapoor Standards Track [Page 6] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[6ページ]。
Optional parameters:
任意のパラメタ:
ptime: See RFC 4566 [7].
ptime: RFC4566[7]を見てください。
maxptime: The maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST
be calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the
duration of a single codec data frame (20 msec). If not
signaled, the default maxptime value MUST be 200 milliseconds.
maxptime: 時間としてミリセカンドで言い表された各パケットで要約できる最大の量のメディア。 パケットでのメディアプレゼントが表す現代の合計として時間について計算しなければなりません。 単一のコーデックデータフレームの持続時間の倍数が(20msec)であったならSHOULDを調節してください。 合図されないなら、デフォルトmaxptime価値は200ミリセカンドでなければなりません。
fixedrate: Indicates the EVRC rate of the session while in
single-rate operation. Valid values include: 0.5 and 1, where
a value of 0.5 indicates the 1/2 rate, while a value of 1
indicates the full rate. If this parameter is not present, 1/2
rate is assumed.
fixedrate: 単一賃率操作にはある間、セッションのEVRC速度を示します。 有効値は: 0.5と1(0.5の値は1の値である間、1/2レートを示す)は全額料金を示します。 このパラメタが存在していないなら、1/2レートは想定されます。
silencesupp: Permissible values are 0 and 1. A value of 1
indicates that the sender of this parameter: a) is capable of
receiving silence-suppressed speech using DTX, AND b) is
capable of and will send out silence-suppressed speech using
DTX, unless the other end indicates that it does not want to
receive silence-suppressed speech using DTX.
silencesupp: 許容値は、0と1です。 1の値がそれを示す、このパラメタの送付者: a) DTX、b)はできるANDを使用することで沈黙で抑圧されたスピーチを受け取ることができて、DTXを使用することで沈黙で抑圧されたスピーチを出すでしょう、もう一方の端が、DTXを使用することで沈黙で抑圧されたスピーチを受け取りたがっていないのを示さない場合。
A value of 0 indicates that the sender of this parameter: a)
does NOT want to receive silence-suppressed speech using DTX,
AND b) will NOT send out silence-suppressed speech using DTX.
0の値がそれを示す、このパラメタの送付者: DTXを使用して、a)は沈黙で抑圧されたスピーチを受け取りたがっていません、そして、b)はDTXを使用することで沈黙で抑圧されたスピーチを出さないでしょう。
If this parameter is not present, the default value 1 MUST be
assumed. If the RTP receiver indicates through the use of SIP
signaling or other means that it is incapable of or unwilling
to use silence suppression using DTX, silence suppression using
DTX as specified in this document MUST NOT be used for the
session.
このパラメタが存在していないなら、デフォルト値1を想定しなければなりません。 RTP受信機が、何らかのシグナリングが、それがDTXを使用する使用に不可能であるか不本意な沈黙抑圧であることを意味するのをSIPの使用で示すなら、セッションに本書では指定されるとしてDTXを使用する沈黙抑圧を使用してはいけません。
dtxmax: Permissible values are from 0 to 255. Indicates the
maximum DTX update interval in number of frames. During DTX,
the RTP sender occasionally updates the RTP receiver about the
change in background noise characteristics, etc., by sending a
new silence frame to the RTP receiver. The RTP receiver may
use 'dtxmax' to indicate to the RTP sender the maximum interval
(in number of frames) between any two DTX updates it expects to
receive from the RTP sender.
dtxmax: 許容値は、0〜255です。 フレームの数で最大のDTXアップデート間隔を示します。 DTXの間、RTP送付者は時折バックグラウンドノイズの特性などにおける変化に関してRTP受信機をアップデートします、新しい沈黙フレームをRTP受信機に送ることによって。RTP受信機は、最大の間隔をRTP送付者に示すのにそれがRTP送付者から受けると予想するどんな2つのDTXアップデートの間でも'dtxmax'を使用するかもしれません(フレームの数で)。
If this parameter is not present in a session that uses DTX,
the default value 32, as specified in [8], MUST be assumed.
This parameter MUST be ignored if silence suppression using DTX
is not used for the session.
このパラメタがDTXを使用するセッションのときに存在していないなら、[8]で指定されるデフォルト値32を想定しなければなりません。 DTXを使用する沈黙抑圧がセッションに使用されないなら、このパラメタを無視しなければなりません。
Xie & Kapoor Standards Track [Page 7] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[7ページ]。
Note also that if the RTP receiver elects to detect DTX using
dtxmax, the dtxmax parameter will affect the amount of delay
the RTP receiver sees before detecting DTX in the stream.
また、RTP受信機が、dtxmaxを使用することでDTXを検出するのを選ぶと、dtxmaxパラメタが流れでDTXを検出する前にRTP受信機が見る遅れの量に影響することに注意してください。
dtxmin: Permissible values are from 0 to 255. Indicates the
minimum DTX update interval in number of frames. The RTP
receiver may use 'dtxmin' to indicate to the RTP sender the
minimal interval (in number of frames) between any two DTX
updates it expects to receive from the RTP sender.
dtxmin: 許容値は、0〜255です。 フレームの数で最小のDTXアップデート間隔を示します。 RTP受信機は、最小量の間隔をRTP送付者に示すのにそれがRTP送付者から受けると予想するどんな2つのDTXアップデートの間でも'dtxmin'を使用するかもしれません(フレームの数で)。
If this parameter is not present, the default value 12, as
specified in [8] MUST be assumed. This parameter MUST be
ignored if silence suppression using DTX is not used for the
session.
このパラメタがそうなら、[8]でプレゼント、指定されるとしてのいずれのデフォルト値12も想定してはいけません。 DTXを使用する沈黙抑圧がセッションに使用されないなら、このパラメタを無視しなければなりません。
hangover: Permissible values are from 0 to 255. Indicates the
number of consecutive silence frames transmitted at the end of
an active speech interval but before the DTX interval begins.
When setting up an RTP session that uses DTX, an RTP receiver
can use this parameter to signal the number of silence frames
it expects to receive before the beginning of DTX. While
hangover=0 is allowed, it is RECOMMENDED that hangover be set
to 1 or greater since the presence of silence frames at the end
of an active speech can help the RTP receiver to identify the
beginning of the DTX period.
二日酔い: 許容値は、0〜255です。 アクティブなスピーチ間隔にもかかわらず、DTX間隔が始まる前を除いて、連続した沈黙フレームの数が終わりに伝わったのを示します。 DTXを使用するRTPセッションをセットアップするとき、RTP受信機は、それがDTXの始まりの前に受け取ると予想する沈黙フレームの数に合図するのにこのパラメタを使用できます。 二日酔い=0は許容されていますが、活発なスピーチの終わりの沈黙フレームの存在が、RTP受信機がDTXの期間の初めを特定するのを助けることができるので二日酔いが1以上に設定されるのは、RECOMMENDEDです。
If this parameter is not present for a session that uses DTX,
the default value 1, as specified in [8] MUST be assumed. This
parameter MUST be ignored if silence suppression using DTX is
not used for the session.
このパラメタがそれが使用するセッションの間、存在していないなら、[8]でDTX、指定されるとしてのデフォルト値1を想定しなければなりません。 DTXを使用する沈黙抑圧がセッションに使用されないなら、このパラメタを無視しなければなりません。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is defined for transfer of EVRC-encoded data via RTP, using
the compact bundled format as described in RFC 4788.
問題をコード化します: このメディアタイプは、縁どられた2進のデータ(RFC4288を見てください、セクション4.8)であり、EVRCによってコード化されたデータの転送のためにRTPを通して定義されます、RFC4788で説明されるようにコンパクトな束ねられた形式を使用して。
Security considerations: See Section 9 of RFC 4788.
セキュリティ問題: RFC4788のセクション9を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification:
The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer
method with compact bundled RTP format is specified in RFC 4788.
広められた仕様: EVRCボコーダは3GPP2C. S0014[2]で指定されます。 コンパクトな束ねられたRTP形式がある転写法はRFC4788で指定されます。
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
このメディアタイプを使用するアプリケーション: 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Xie & Kapoor Standards Track [Page 8] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[8ページ]。
Additional information: none
追加情報: なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
詳細のために連絡する人とEメールアドレス: Xie <Qiaobing.Xie@motorola.com をQiaobingする、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type depends on RTP framing; hence, it is only defined
for transfer via RTP (RFC 3550 [5]). Transfer within other
framing protocols is not defined at this time.
用法における制限: このメディアタイプはRTP縁どりを当てにします。 したがって、それは転送のためにRTPを通して定義されるだけです。(RFC3550[5])。 他の縁どりプロトコルの中の転送はこのとき、定義されません。
Author:
Qiaobing Xie
以下を書いてください。 シェをQiaobingします。
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
6.2. Registration of Media Type EVRCB
6.2. メディアタイプEVRCBの登録
Type name: audio
型名: オーディオ
Subtype names: EVRCB
Subtype名: EVRCB
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
ptime: see RFC 4566 [7].
ptime: RFC4566[7]を見てください。
maxptime: The maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST
be calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the
duration of a single codec data frame (20 msec). If not
signaled, the default maxptime value MUST be 200 milliseconds.
maxptime: 時間としてミリセカンドで言い表された各パケットで要約できる最大の量のメディア。 パケットでのメディアプレゼントが表す現代の合計として時間について計算しなければなりません。 単一のコーデックデータフレームの持続時間の倍数が(20msec)であったならSHOULDを調節してください。 合図されないなら、デフォルトmaxptime価値は200ミリセカンドでなければなりません。
maxinterleave: Maximum number for interleaving length (field LLL
in the Interleaving Octet). The interleaving lengths used in
the entire session MUST NOT exceed this maximum value. If not
signaled, the maxinterleave length MUST be 5.
maxinterleave: インターリービングの長さ(Interleaving Octetの分野LLL)の最大数。 全体のセッションのときに使用されたインターリービングの長さはこの最大値を超えてはいけません。 合図されないなら、maxinterleaveの長さは5であるに違いありません。
silencesupp: see Section 6.1 for definition. If this parameter
is not present, the default value 1 MUST be assumed.
silencesupp: 定義に関してセクション6.1を見てください。 このパラメタが存在していないなら、デフォルト値1を想定しなければなりません。
Xie & Kapoor Standards Track [Page 9] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[9ページ]。
dtxmax: see Section 6.1
dtxmax: セクション6.1を見てください。
dtxmin: see Section 6.1
dtxmin: セクション6.1を見てください。
hangover: see Section 6.1
二日酔い: セクション6.1を見てください。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is defined for transfer of EVRC-B-encoded data via RTP using
the Interleaved/Bundled packet format specified in RFC 3558 [4].
問題をコード化します: このメディアタイプは、RFC3558[4]で指定されたInterleaved/束ねられたパケット・フォーマットを使用することで縁どられた2進のデータ(RFC4288を見てください、セクション4.8)であり、EVRC-Bによってコード化されたデータの転送のためにRTPを通して定義されます。
Security considerations: See Section 9 of RFC 4788.
セキュリティ問題: RFC4788のセクション9を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer
method with Interleaved/Bundled packet format via RTP is specified
in RFC 3558.
広められた仕様: EVRC-Bボコーダは3GPP2C. S0014-B[3]で指定されます。 RTPを通してInterleaved/束ねられたパケット・フォーマットがある転写法はRFC3558で指定されます。
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
このメディアタイプを使用するアプリケーション: 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Additional information:
The following information applies for storage format only.
追加情報: 以下の情報は格納形式だけに申し込みます。
Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
File extensions: evb, EVB
Macintosh file type code: None
Object identifier or OID: None
マジックナンバー: #EVRC-B\n(RFC4788のセクション5を見ます)ファイル拡張子: evb、EVBマッキントッシュファイルの種類コード: なにも、Object識別子かOID: なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
詳細のために連絡する人とEメールアドレス: Xie <Qiaobing.Xie@motorola.com をQiaobingする、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type may be used with RTP framing (RFC 3550 [5]) and as
a storage format. When used with RTP, the procedures in Section 3
MUST be followed. In all other contexts, the storage format
defined in Section 5 MUST be used.
用法における制限: このメディアタイプは縁どっているRTPと共に使用されるかもしれません。(RFC3550[5])と格納形式として。 RTPと共に使用されると、セクション3の手順に従わなければなりません。 他のすべての文脈では、セクション5で定義された格納書式を使用しなければなりません。
Author:
Qiaobing Xie
以下を書いてください。 シェをQiaobingします。
Xie & Kapoor Standards Track [Page 10] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[10ページ]。
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
6.3. Registration of Media Type EVRCB0
6.3. メディアタイプEVRCB0の登録
Type name: audio
型名: オーディオ
Subtype names: EVRCB0
Subtype名: EVRCB0
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
silencesupp: see Section 6.1 for definition. If this parameter
is not present, the default value 1 MUST be assumed.
silencesupp: 定義に関してセクション6.1を見てください。 このパラメタが存在していないなら、デフォルト値1を想定しなければなりません。
dtxmax: see Section 6.1
dtxmax: セクション6.1を見てください。
dtxmin: see Section 6.1
dtxmin: セクション6.1を見てください。
hangover: see Section 6.1
二日酔い: セクション6.1を見てください。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is defined for transfer of EVRC-B-encoded data via RTP using
the Header-Free packet format specified in RFC 3558 [4].
問題をコード化します: このメディアタイプは、RFC3558[4]で指定された自由なHeaderパケット・フォーマットを使用することで縁どられた2進のデータ(RFC4288を見てください、セクション4.8)であり、EVRC-Bによってコード化されたデータの転送のためにRTPを通して定義されます。
Security considerations: See Section 9 of RFC 4788.
セキュリティ問題: RFC4788のセクション9を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer
method with Header-Free packet format via RTP is specified in RFC
3558 and RFC 4788.
広められた仕様: EVRC-Bボコーダは3GPP2C. S0014-B[3]で指定されます。 RTPを通して自由なHeaderパケット・フォーマットがある転写法はRFC3558とRFC4788で指定されます。
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
このメディアタイプを使用するアプリケーション: 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Additional information: none
追加情報: なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
詳細のために連絡する人とEメールアドレス: Xie <Qiaobing.Xie@motorola.com をQiaobingする、gt。
Xie & Kapoor Standards Track [Page 11] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[11ページ]。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type depends on RTP framing; hence, it is only defined
for transfer via RTP (RFC 3550 [5]). Transfer within other
framing protocols is not defined at this time.
用法における制限: このメディアタイプはRTP縁どりを当てにします。 したがって、それは転送のためにRTPを通して定義されるだけです。(RFC3550[5])。 他の縁どりプロトコルの中の転送はこのとき、定義されません。
Author:
Qiaobing Xie
以下を書いてください。 シェをQiaobingします。
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
6.4. Registration of Media Type EVRCB1
6.4. メディアタイプEVRCB1の登録
Type name: audio
型名: オーディオ
Subtype names: EVRCB1
Subtype名: EVRCB1
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
ptime: see RFC 4566 [7].
ptime: RFC4566[7]を見てください。
maxptime: The maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST
be calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the
duration of a single codec data frame (20 msec). If not
signaled, the default maxptime value MUST be 200 milliseconds.
maxptime: 時間としてミリセカンドで言い表された各パケットで要約できる最大の量のメディア。 パケットでのメディアプレゼントが表す現代の合計として時間について計算しなければなりません。 単一のコーデックデータフレームの持続時間の倍数が(20msec)であったならSHOULDを調節してください。 合図されないなら、デフォルトmaxptime価値は200ミリセカンドでなければなりません。
fixedrate: Indicates the EVRC-B rate of the session while in
single-rate operation. Valid values include: 0.5 and 1, where
a value of 0.5 indicates the 1/2 rate while a value of 1
indicates the full rate. If this parameter is not present, 1/2
rate is assumed.
fixedrate: 単一賃率操作にはある間、セッションのEVRC-B速度を示します。 有効値は: 0.5と1。(そこで、1の値は全額料金を示しますが、0.5の値は1/2レートを示します)。 このパラメタが存在していないなら、1/2レートは想定されます。
silencesupp: see Section 6.1 for definition. If this parameter
is not present, the default value 1 MUST be assumed.
silencesupp: 定義に関してセクション6.1を見てください。 このパラメタが存在していないなら、デフォルト値1を想定しなければなりません。
dtxmax: see Section 6.1
dtxmax: セクション6.1を見てください。
dtxmin: see Section 6.1
dtxmin: セクション6.1を見てください。
Xie & Kapoor Standards Track [Page 12] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[12ページ]。
hangover: see Section 6.1
二日酔い: セクション6.1を見てください。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is defined for transfer of EVRC-B-encoded data via RTP using
the compact bundled format as described in RFC 4788.
問題をコード化します: このメディアタイプは、RFC4788で説明されるようにコンパクトな添付された形式を使用することで縁どられたバイナリ・データ(RFC4288を見てください、セクション4.8)であり、EVRC-Bによってコード化されたデータの転送のためにRTPを通して定義されます。
Security considerations: See Section 9 of RFC 4788.
セキュリティ問題: RFC4788のセクション9を見てください。
Interoperability considerations: none.
相互運用性問題: なし。
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3]. Transfer
method with compact bundled RTP format is specified in RFC 4788.
広められた仕様: EVRC-Bボコーダは3GPP2C. S0014-B[3]で指定されます。 コンパクトな添付されたRTP形式がある転写法はRFC4788で指定されます。
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
このメディアタイプを使用するアプリケーション: 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Additional information: none
追加情報: なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
詳細のために連絡する人とEメールアドレス: Xie <Qiaobing.Xie@motorola.com をQiaobingする、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type depends on RTP framing; hence, it is only defined
for transfer via RTP (RFC 3550 [5]). Transfer within other
framing protocols is not defined at this time.
用法における制限: このメディアタイプはRTP縁どりを当てにします。 したがって、それは転送のためにRTPを通して定義されるだけです。(RFC3550[5])。 他の縁どりプロトコルの中の転送はこのとき、定義されません。
Author:
Qiaobing Xie
以下を書いてください。 シェをQiaobingします。
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
6.5. Updated Registration of Media Type EVRC
6.5. メディアタイプEVRCのアップデートされた登録
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
(定義は任意のDTXパラメタで加えられたRFC3558から来ていて、新しいテンプレートが[10]で指定されている状態で、アップデートします。)
Type name: audio
型名: オーディオ
Subtype names: EVRC
Subtype名: EVRC
Xie & Kapoor Standards Track [Page 13] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[13ページ]。
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
ptime: Defined as usual for RTP audio (see RFC 4566).
ptime: RTPオーディオ(RFC4566を見る)のためにいつものように定義されます。
maxptime: The maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds. The time SHALL
be calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the
duration of a single codec data frame (20 msec). If not
signaled, the default maxptime value SHALL be 200 milliseconds.
maxptime: 時間としてミリセカンドで言い表された各パケットでカプセル化することができる最大の量のメディア。 メディアがパケットが表すコネを現代の合計で提示するので計算されていて、SHALLを調節してください。 単一のコーデックデータフレームの持続時間の倍数が(20msec)であったならSHOULDを調節してください。 200がミリセカンドであり、合図されないなら、デフォルトmaxptimeはSHALLを評価します。
maxinterleave: Maximum number for interleaving length (field LLL
in the Interleaving Octet). The interleaving lengths used in
the entire session MUST NOT exceed this maximum value. If not
signaled, the maxinterleave length SHALL be 5.
maxinterleave: インターリービングの長さ(Interleaving Octetの分野LLL)の最大数。 全体のセッションのときに使用されたインターリービングの長さはこの最大値を超えてはいけません。 合図される、maxinterleaveの長さのSHALL、5になってください。
silencesupp: see Section 6.1 for definition. If this parameter
is not present, the default value 1 MUST be assumed.
silencesupp: 定義に関してセクション6.1を見てください。 このパラメタが存在していないなら、デフォルト値1を想定しなければなりません。
dtxmax: see Section 6.1
dtxmax: セクション6.1を見てください。
dtxmin: see Section 6.1
dtxmin: セクション6.1を見てください。
hangover: see Section 6.1
二日酔い: セクション6.1を見てください。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8),
and is defined for transfer of EVRC-encoded data via RTP using the
Interleaved/Bundled packet format specified in Sections 4.1, 6,
and 7 of RFC 3558. It is also defined for other transfer methods
using the storage format specified in Section 11 of RFC 3558.
問題をコード化します: このメディアタイプは、RFC3558のセクション4.1、6、および7で指定されたパケット・フォーマットであると、縁どられたバイナリ・データ(RFC4288を見てください、セクション4.8)であり、Interleavedを使用するRTPを通したEVRCによってコード化されたデータの転送のために定義されるか、または添付されます。 また、それは、他の転写法のためにRFC3558のセクション11で指定されたストレージ形式を使用することで定義されます。
Security considerations: See Section 14, "Security Considerations",
of RFC 3558.
セキュリティ問題: セクション14、RFC3558の「セキュリティ問題」を見てください。
Interoperability considerations:
The DTX parameters are receiver options. Existing RFC 3558
implementations will not send any of the DTX parameters in their
SDP and will ignore any DTX parameters they receive. The adaptive
DTX behavior of DTX-capable EVRC codecs (as detailed in [8],
Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
相互運用性問題: DTXパラメタは受信機オプションです。 既存のRFC3558実装は、それらのSDPのDTXパラメタのいずれも送らないで、彼らが受け取るどんなDTXパラメタも無視するでしょう。 DTXできるEVRCコーデック([8]、セクション4.3.5で詳しく述べられるように)の適応型のDTX動きは非DTX EVRCコーデックで相互運用性を確実にします。
Published specification:
The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer
methods are specified in RFC 3558.
広められた仕様: EVRCボコーダは3GPP2C. S0014[2]で指定されます。 転写法はRFC3558で指定されます。
Xie & Kapoor Standards Track [Page 14] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[14ページ]。
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
このメディアタイプを使用するアプリケーション: 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Additional information:
The following information applies for storage format only.
追加情報: 以下の情報はストレージ形式だけに申し込みます。
Magic number: #!EVRC\n (see Section 11 of RFC 3558)
File extensions: evc, EVC
Macintosh file type code: none
Object identifier or OID: none
マジックナンバー: #EVRC\n(RFC3558のセクション11を見ます)ファイル拡張子: evc、EVCマッキントッシュファイルの種類コード: なにも、Object識別子かOID: なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
詳細のために連絡する人とEメールアドレス: Xie <Qiaobing.Xie@motorola.com をQiaobingする、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type may be used with RTP framing (RFC 3550 [5]) and as
a storage format. When used with RTP, the procedures in RFC 3558,
Section 4.1, MUST be followed. In all other contexts, the storage
format defined in RFC 3558, Section 11, MUST be used.
用法における制限: このメディアタイプは縁どっているRTPと共に使用されるかもしれません。(RFC3550[5])とストレージ形式として。 RTPと共に使用されると、RFC3558の手順(セクション4.1)に従わなければなりません。 他のすべての文脈では、RFC3558で定義されたストレージ書式(セクション11)を使用しなければなりません。
Author:
Adam Li/Qiaobing Xie
以下を書いてください。 アダム李/Qiaobingシェ
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
6.6. Updated Registration of Media Type EVRC0
6.6. メディアタイプEVRC0のアップデートされた登録
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
(定義は任意のDTXパラメタで加えられたRFC3558から来ていて、新しいテンプレートが[10]で指定されている状態で、アップデートします。)
Type name: audio
型名: オーディオ
Subtype names: EVRC0
Subtype名: EVRC0
Required parameters: none
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
silencesupp: see Section 6.1 for definition. If this parameter
is not present, the default value 1 MUST be assumed.
silencesupp: 定義に関してセクション6.1を見てください。 このパラメタが存在していないなら、デフォルト値1を想定しなければなりません。
Xie & Kapoor Standards Track [Page 15] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[15ページ]。
dtxmax: see Section 6.1
dtxmax: セクション6.1を見てください。
dtxmin: see Section 6.1
dtxmin: セクション6.1を見てください。
hangover: see Section 6.1
二日酔い: セクション6.1を見てください。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is only defined for transfer of EVRC-encoded data via RTP
using the Header-Free packet format specified in Section 4.2 of
RFC 3558.
問題をコード化します: このメディアタイプは、RFC3558のセクション4.2で指定された自由なHeaderパケット・フォーマットを使用することで縁どられたバイナリ・データ(RFC4288を見てください、セクション4.8)であり、EVRCによってコード化されたデータの転送のためにRTPを通して定義されるだけです。
Security considerations: See Section 14, "Security Considerations",
of RFC 3558.
セキュリティ問題: セクション14、RFC3558の「セキュリティ問題」を見てください。
Interoperability considerations:
The DTX parameters are receiver options. Existing RFC 3558
implementations will not send any of the DTX parameters in their
SDP and will ignore any DTX parameters they receive. The adaptive
DTX behavior of DTX-capable EVRC codecs (as detailed in [8],
Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
相互運用性問題: DTXパラメタは受信機オプションです。 既存のRFC3558実装は、それらのSDPのDTXパラメタのいずれも送らないで、彼らが受け取るどんなDTXパラメタも無視するでしょう。 DTXできるEVRCコーデック([8]、セクション4.3.5で詳しく述べられるように)の適応型のDTX動きは非DTX EVRCコーデックで相互運用性を確実にします。
Published specification:
The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer
methods are specified in RFC 3558.
広められた仕様: EVRCボコーダは3GPP2C. S0014[2]で指定されます。 転写法はRFC3558で指定されます。
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
このメディアタイプを使用するアプリケーション: 多くのVoIPアプリケーション(モバイルアプリケーションと同様に)がこのタイプを使用すると予想されます。
Additional information: none
追加情報: なし
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
詳細のために連絡する人とEメールアドレス: Xie <Qiaobing.Xie@motorola.com をQiaobingする、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type depends on RTP framing; hence, it is only defined
for transfer via RTP (RFC 3550 [5]). Transfer within other
framing protocols is not defined at this time.
用法における制限: このメディアタイプはRTP縁どりを当てにします。 したがって、それは転送のためにRTPを通して定義されるだけです。(RFC3550[5])。 他の縁どりプロトコルの中の転送はこのとき、定義されません。
Author:
Adam Li/Qiaobing Xie
以下を書いてください。 アダム李/Qiaobingシェ
Xie & Kapoor Standards Track [Page 16] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[16ページ]。
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
6.7. Mapping MIME Parameters into SDP
6.7. MIMEパラメタをSDPに写像します。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [7], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the compact bundled format for EVRC/EVRC-B-encoded speech, the mapping is as follows:
タイプ仕様が特定のマッピングを持っているMIMEメディアで運ばれた情報はSession記述プロトコル(SDP)で[7]をさばきます。([7]は、RTPセッションについて説明するのに一般的に使用されます)。 SDPがいつEVRC/EVRC-Bによってコード化されたスピーチのためのコンパクトな添付された形式を使うセッション、マッピングを指定するのにおいて使用されているかは、以下の通りです:
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIMEの種類(「オーディオ」)はメディア名としてSDP「m=」に行きます。
o The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or
"EVRCB1") goes in SDP "a=rtpmap" as the encoding name.
o MIMEは副タイプされます。("EVRC"と「EVRC0"か、コード化としての「EVRC1"、"EVRCB"、EVRCB0"、または「EVRCB1") SDPのゴエス」a=rtpmap」が命名します」。
o The optional parameters "ptime" and "maxptime" (for subtypes EVRC,
EVRC1, EVRCB, and EVRCB1) go in the SDP "a=ptime" and "a=maxptime"
attributes, respectively.
o 任意のパラメタの"ptime"と"maxptime"(血液型亜型EVRC、EVRC1、EVRCB、およびEVRCB1のための)はそれぞれSDP"a=ptime"と"a=maxptime"属性に入ります。
o The optional parameter "maxinterleave" (for subtypes EVRC and
EVRCB) goes in the SDP "a=fmtp" attribute by copying it directly
from the MIME media type string as "maxinterleave=value".
o 「maxinterleaveは値と等しい」ので直接メディアタイプが結ぶMIMEからそれをコピーすることによって、任意のパラメタ"maxinterleave"(血液型亜型EVRCとEVRCBのための)はSDP"a=fmtp"属性に入ります。
o The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1)
goes in the "a=fmtp" attribute by copying it directly from the
MIME media type string as "fixedrate=value".
o 「fixedrateは値と等しい」ので直接メディアタイプが結ぶMIMEからそれをコピーすることによって、任意のパラメタ"fixedrate"(血液型亜型EVRC1とEVRCB1のための)は"a=fmtp"属性に入ります。
o The optional parameters "silencesupp", "dtxmax", "dtxmin", and
"hangover" go in the "a=fmtp" attribute by copying it directly
from the MIME media type string as "silencesupp=value",
"dtxmax=value", "dtxmin=value", and "hangover=value",
respectively.
o 任意のパラメタ"silencesupp"、"dtxmax"、"dtxmin"、および「二日酔い」はそれぞれ「silencesuppは値と等しい」ので直接メディアタイプが結ぶMIMEからそれをコピーするのによる"a=fmtp"属性、「dtxmaxは値と等しい」、「dtxminは値と等しい」、および「二日酔い=価値」に入ります。
Example of usage of EVRC1:
EVRC1の使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:120
オーディオの49120RTP/AVP97m=a=rtpmap: 97EVRC1/8000 a=fmtp: 97fixedrate=0.5 a=maxptime: 120
Example of usage of EVRCB:
EVRCBの使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=maxptime:120
オーディオの49120RTP/AVP97m=a=rtpmap: 97EVRCB/8000a=maxptime: 120
Xie & Kapoor Standards Track [Page 17] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[17ページ]。
Example of usage of EVRCB0:
EVRCB0の使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000
オーディオの49120RTP/AVP97m=a=rtpmap: 97EVRCB0/8000
Example of usage of EVRCB1:
EVRCB1の使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:100
オーディオの49120RTP/AVP97m=a=rtpmap: 97EVRCB1/8000 a=fmtp: 97fixedrate=0.5 a=maxptime: 100
Example of usage of EVRC with DTX with silencesupp=1:
silencesupp=1とDTXとEVRCの使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
オーディオの49120RTP/AVP97m=a=rtpmap: 97EVRC/8000a=fmtp: 97silencesupp=1 dtxmax=32 dtxmin=12二日酔い=1
Example of usage of EVRC with DTX with silencesupp=0:
silencesupp=0とDTXとEVRCの使用法に関する例:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=0
オーディオの49120RTP/AVP97m=a=rtpmap: 97EVRC/8000a=fmtp: 97silencesupp=0
6.8. Usage in Offer/Answer
6.8. 申し出/答えにおける用法
All SDP parameters in this payload format are declarative, and all reasonable values are expected to be supported. In particular, when DTX is supported, the RTP sender implementation SHOULD support hangover, dtxmin, and dtxmax values from 0 to 255. Thus, the standard usage of Offer/Answer, as described in RFC 3264 [6], SHOULD be followed.
このペイロード形式のすべてのSDPパラメタが宣言的です、そして、すべての適正価値がサポートされると予想されます。 DTXがサポートされるとき、特に、RTP送付者実装SHOULDは二日酔い、dtxmin、およびdtxmaxに値を0〜255までサポートします。 SHOULD、その結果、Offer/の標準的用法にRFC3264[6]で説明されるように答えます。従われています。
In addition, the following rules MUST be followed while negotiating DTX parameters:
さらに、DTXパラメタを交渉している間、以下の規則に従わなければなりません:
1. If any DTX parameter is not present in either offer and/or
answer, the default value of the DTX parameter MUST be assumed.
1. 何かDTXパラメタがどちらかの申し出、そして/または、答えで存在していないなら、DTXパラメタのデフォルト値を想定しなければなりません。
2. If silencesupp is present and set to 0 in either offer or answer,
the values of all received DTX parameters other than silencesupp
SHOULD be ignored.
2. silencesuppがプレゼントとセットであるなら、silencesupp SHOULDを除いて、すべての受信されたDTXパラメタのどちらかの申し出か答え、値における0まで、無視されてください。
3. In an offer or answer, the value of dtxmax SHOULD always be
larger than or equal to the value of dtxmin, regardless of
whether the values are indicated explicitly or implicitly by
default. Moreover, if the indicated value of dtxmin is larger
3. いつもdtxmax SHOULDの申し出か答え、値において、dtxminのより多くの値になってください、値がデフォルトで明らかかそれとなく示されるかどうかにかかわらず。 そのうえ、dtxminの表示値は、より大きいです。
Xie & Kapoor Standards Track [Page 18] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[18ページ]。
than that of dtxmax, an RTP sender MUST ignore the indicated
values and MUST fall back on using the default dtxmin and dtxmax
values.
デフォルトdtxminとdtxmaxを使用するときRTP送付者がdtxmaxでは、表示値を無視しなければならなくて、転ばなければならないのが値を支持するより。
7. Backward Compatibility with RFC 3558
7. RFC3558との後方の互換性
This document adds new optional DTX parameters to the original EVRC payload subtypes "EVRC" and "EVRC0" defined in RFC 3558. Since the new DTX parameters are receiver options, we expect that the existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures the backward interoperability between the DTX- capable EVRC codec and non-DTX EVRC codecs.
このドキュメントはオリジナルのEVRCペイロード血液型亜型"EVRC"と「RFC3558で定義されたEVRC0"」に新しい任意のDTXパラメタを加えます。 新しいDTXパラメタが受信機オプションであるので、私たちは、既存のRFC3558実装がそれらのSDPのDTXパラメタのいずれも送らないで、彼らが受け取るどんなDTXパラメタも無視すると予想します。 DTXできるEVRCコーデック([8]、セクション4.3.5で詳しく述べられるように)の適応型のDTX動きはDTXのできるEVRCコーデックと非DTX EVRCコーデックの間の後方の相互運用性を確実にします。
8. IANA Considerations
8. IANA問題
Four (4) new MIME subtype registrations - "EVRC1", "EVRCB", "EVRCB0", and "EVRCB1" - are defined in this document (see Section 6.1 - Section 6.4) for EVRC-B and compact bundled payload format support.
4つの(4)の新しいMIME「副-タイプ」登録証明書--、「EVRC1"、"EVRCB"、「EVRCB0"、および「EVRCB1"--ことEVRC-Bに関する(セクション6.1を見てください--セクション6.4)本書では定義されて、であり、コンパクトな添付されたペイロード形式サポート。」
For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558 [4] and RFC 4788, four additional optional parameters - "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and used in DTX.
すべてのEVRCとEVRC-B RTPのために、RFC3558[4]とRFC4788、fourの追加任意のパラメタで定義されたペイロード書式("silencesupp"、"dtxmax"、"dtxmin"、および「二日酔い」)は、DTXで定義されて、使用されます。
The MIME subtype registrations "EVRC" and "EVRC0", originally defined in RFC 3558 [4], are updated with the optional DTX parameters (see Sections 6.5 and 6.6).
MIMEは登録証明書"EVRC"を副タイプします、そして、「任意のDTXパラメタで元々RFC3558[4]で定義されたEVRC0"をアップデート(セクション6.5と6.6を見てください)」。
9. Security Considerations
9. セキュリティ問題
Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [4], RFC 3550 [5], and any appropriate profile (for example, RFC 3551 [9]). This payload does not specify any different security services.
この仕様に基づき定義されたペイロードを使用する実装がRFC3558[4]、RFC3550[5]、およびどんな適切なプロフィールでも議論したセキュリティ問題を条件としています。(例えば、RFC3551[9])。 このペイロードは少しの異なったセキュリティー・サービスも指定しません。
10. Acknowledgements
10. 承認
The following people have made significant contributions to this document (in alphabetical order): Parag Agashe, Jim Ashley, Harikishan Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh Vij.
以下の人々はこのドキュメント(アルファベット順に)への重要な貢献をしました: Parag Agashe、ジム・アッシュリー、Harikishan Desineni、セラフィン・ディアーズ、Harinath Garudadri、Gouri Johanssen、Ananth Kandhadai、Waqar Mohsin、Ashokロイ、ジーノScribano、およびGajinderシンVij。
Special thanks to Colin Perkins, Magnus Westerlund, and Adam Li for their careful review and comments that significantly improved the quality of this document.
彼らの慎重なレビューのためのコリン・パーキンス、マグヌスWesterlund、およびアダム・李への特別な感謝とこのドキュメントの品質をかなり改良したコメント。
Xie & Kapoor Standards Track [Page 19] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[19ページ]。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] "Enhanced Variable Rate Codec, Speech Service Option 3 for
Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014,
January 1997.
[2] 「高められた変動金利コーデック、スピーチサービスは広帯域普及のスペクトルデジタル・システムのために3をゆだねる」3GPP2C.S0014、1997年1月。
[3] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68
for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B
v1.0, May 2006.
[3] 「高められた変動金利コーデック、広帯域のためのスピーチサービスオプション3と68はスペクトルデジタル・システムを広げます」、3GPP2C.S0014-B v1.0、2006年5月。
[4] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558,
July 2003.
[4] 李、A.、「高められた変動金利コーデック(EVRC)と選択可能なモードボコーダ(SMV)のためのRTP有効搭載量形式」、RFC3558(2003年7月)。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003.
[5]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[7] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[8] "Discontinuous Transmission (DTX) of Speech in cdma2000
Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005.
[8]「cdma2000 SystemsのSpeechの不連続なTransmission(DTX)」、3GPP2C. S0076-0、バージョン1.0、2005年12月。
11.2. Informative References
11.2. 有益な参照
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[9]SchulzrinneとH.とS.Casner、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC3551、2003年7月。
[10] Casner, S., "Media Type Registration of RTP Payload Formats",
Work in Progress, March 2006.
[10] S.、「メディアはRTP有効搭載量形式の登録をタイプする」というCasnerが進歩、2006年3月に働いています。
Xie & Kapoor Standards Track [Page 20] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[20ページ]。
Authors' Addresses
作者のアドレス
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US
シェモトローラ1501W.シュアーのドライブ、2-F9アーリントンハイツ、IL60004米国をQiaobingします。
Phone: +1-847-632-3028 EMail: Qiaobing.Xie@Motorola.com
以下に電話をしてください。 +1-847-632-3028 メールしてください: Qiaobing.Xie@Motorola.com
Rohit Kapoor Qualcomm Inc. US
Rohitカプールクアルコム株式会社米国
Phone: +1-858-845-1161 EMail: rkapoor@qualcomm.com
以下に電話をしてください。 +1-858-845-1161 メールしてください: rkapoor@qualcomm.com
Xie & Kapoor Standards Track [Page 21] RFC 4788 EVRC RTP Format Enhancements January 2007
シェとカプールStandardsはEVRC RTP形式増進2007年1月にRFC4788を追跡します[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Xie & Kapoor Standards Track [Page 22]
シェとカプール標準化過程[22ページ]
一覧
スポンサーリンク
