Network Working Group H. Schulzrinne
Request for Comments: 2833 Columbia University
Category: Standards Track S. Petrack
MetaTel
May 2000
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
DTMFケタ、電話トーン、および電話信号のための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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
このメモはデュアルトーン多重周波数（DTMF）シグナリング、他のトーン信号とRTPパケット内のテレフォニーイベントを運ぶ方法について説明します。
1 Introduction
1はじめに
This memo defines two payload formats, one for carrying dual-tone multifrequency (DTMF) digits, other line and trunk signals (Section 3), and a second one for general multi-frequency tones in RTP [1] packets (Section 4). Separate RTP payload formats are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate.
このメモは、二つのペイロードフォーマット、デュアルトーン多周波（DTMF）数字、他のラインとトランク信号（セクション3）を担持するための1つ、およびRTPの一般的な多周波トーンのための第[1]パケット（セクション4）を規定します。低レートの音声コーデックを自動認識するために十分正確にこれらのトーン信号を再生することを保証することはできませんので、別々のRTPペイロードフォーマットが望まれています。低ビットレートを維持しながら、別のペイロードフォーマットを定義することも高い冗長性を可能にします。
The payload formats described here may be useful in at least three applications: DTMF handling for gateways and end systems, as well as "RTP trunks". In the first application, the Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway likely has the necessary digital signal processors and algorithms, as it often needs to detect DTMF, e.g., for two-stage dialing. Having the gateway detect tones relieves the receiving Internet end system from having to do this work and also avoids that low bit-rate codecs like G.723.1 render DTMF tones unintelligible. Secondly, an Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver.
ここで説明したペイロードフォーマットは、少なくとも3つの用途に有用であり得る：ゲートウェイとエンドシステム、ならびに「RTPトランク」のDTMF処理。最初のアプリケーションでは、インターネット電話ゲートウェイは、受信回路にDTMFを検出し、ここで説明するRTPペイロードの代わりに、通常のオーディオパケットを送信します。それはしばしば2段階ダイヤリングのために、例えば、DTMFを検出する必要があるように、ゲートウェイは、おそらく、必要なデジタル信号プロセッサおよびアルゴリズムを有します。ゲートウェイはトーンを検出有するこの仕事をすることから受信インターネットエンドシステムを解放し、またG.723.1のような低ビットレートコーデックは不明瞭DTMFトーンをレンダリングすることを回避します。第二に、そのような「インターネット電話」などのインターネットエンドシステムは、正確なトーンペアを生成するとし、レシーバ上のトーン認識の負担をかけることなく、それ自体に関することなく、DTMF機能をエミュレートすることができます。
In the "RTP trunk" application, RTP is used to replace a normal circuit-switched trunk between two nodes. This is particularly of interest in a telephone network that is still mostly circuit-switched. In this case, each end of the RTP trunk encodes audio channels into the appropriate encoding, such as G.723.1 or G.729. However, this encoding process destroys in-band signaling information which is carried using the least-significant bit ("robbed bit signaling") and may also interfere with in-band signaling tones, such as the MF digit tones. In addition, tone properties such as the phase reversals in the ANSam tone, will not survive speech coding. Thus, the gateway needs to remove the in-band signaling information from the bit stream. It can now either carry it out-of-band in a signaling transport mechanism yet to be defined, or it can use the mechanism described in this memorandum. (If the two trunk end points are within reach of the same media gateway controller, the media gateway controller can also handle the signaling.) Carrying it in-band may simplify the time synchronization between audio packets and the tone or signal information. This is particularly relevant where duration and timing matter, as in the carriage of DTMF signals.
「RTPトランク」アプリケーションで、RTPは、2つのノード間で通常の回線交換トランクを置き換えるために使用されます。これは特に、まだほとんどが回線交換で電話ネットワークで重要です。この場合、RTPトランクの各端部は、G.723.1またはG.729などの適切なエンコーディングにオーディオチャンネルをコードします。しかし、この符号化処理は、最下位ビット（「損失ビットシグナリング」）を用いて実施され、また、MFディジットトーンとしてインバンドシグナリングトーンと干渉し得る信号情報をインバンド破壊します。また、このようなANSamのトーンにおける位相反転などのトーンの特性は、音声符号化に耐えられないだろう。したがって、ゲートウェイは、ビットストリームからインバンドシグナリング情報を削除する必要があります。これは今のいずれかまだ定義するシグナリングトランスポート機構で帯域外それを運ぶことができ、またはそれは、このメモで説明されたメカニズムを使用することができます。 （二トランクエンドポイントが同じメディアゲートウェイコントローラの到達範囲内にある場合、メディアゲートウェイコントローラは、シグナリングを処理することができる。）でバンドを運ぶオーディオパケット及びトーン又は信号情報との間の時間同期を単純化することができます。これは、DTMF信号のキャリッジのように、ここで、継続時間及びタイミング問題特に関連があります。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[2]及び対応する実装の要求レベルを示します。
2 Events vs. Tones
トーン対2つのイベント
A gateway has two options for handling DTMF digits and events. First, it can simply measure the frequency components of the voice band signals and transmit this information to the RTP receiver (Section 4). In this mode, the gateway makes no attempt to discern the meaning of the tones, but simply distinguishes tones from speech signals.
ゲートウェイは、DTMFディジットとイベントを処理するための2つのオプションがあります。まず、単に音声帯域信号の周波数成分を測定し、RTP受信部（第4）にこの情報を送信することができます。このモードでは、ゲートウェイはトーンの意味を識別を試みませんが、単に音声信号から音を区別します。
All tone signals in use in the PSTN and meant for human consumption are sequences of simple combinations of sine waves, either added or modulated. (There is at least one tone, the ANSam tone [3] used for indicating data transmission over voice lines, that makes use of periodic phase reversals.)
すべてのトーン信号PSTNで使用されていると人間の消費のためのものは、正弦波、追加または変調の単純な組み合わせの配列です。 （少なくとも1つのトーン、[3]は、周期的位相反転を利用した音声回線上のデータ伝送を示すために使用されるANSamのトーンがあります。）
As a second option, a gateway can recognize the tones and translate them into a name, such as ringing or busy tone. The receiver then produces a tone signal or other indication appropriate to the signal.
第二の選択肢として、ゲートウェイはトーンを認識することができ、そのようなリンギングや話中音など、名前にそれらを変換します。受信機は、信号を適切なトーン信号又は他の指示を生成します。
Generally, since the recognition of signals often depends on their on/off pattern or the sequence of several tones, this recognition can take several seconds. On the other hand, the gateway may have access to the actual signaling information that generates the tones and thus can generate the RTP packet immediately, without the detour through acoustic signals.
一般的に、信号の認識は、多くの場合、彼らのオン/オフパターンまたは複数のトーンの順序に依存するため、この認識は数秒かかることがあります。一方、ゲートウェイはトーンを生成し、したがって、音響信号を介して迂回することなく、直ちにRTPパケットを生成することができ、実際のシグナリング情報にアクセスすることができます。
In the phone network, tones are generated at different places, depending on the switching technology and the nature of the tone. This determines, for example, whether a person making a call to a foreign country hears her local tones she is familiar with or the tones as used in the country called.
電話ネットワークでは、トーンは、スイッチング技術と音の性質に応じて、異なる場所で発生しています。これは、外国に電話をかける人は呼ばれる国で使用されるような彼女がまたはトーンに精通している彼女の地元のトーンを聞くかどうか、例えば、決定します。
For analog lines, dial tone is always generated by the local switch. ISDN terminals may generate dial tone locally and then send a Q.931 SETUP message containing the dialed digits. If the terminal just sends a SETUP message without any Called Party digits, then the switch does digit collection, provided by the terminal as KEYPAD messages, and provides dial tone over the B-channel. The terminal can either use the audio signal on the B-channel or can use the Q.931 messages to trigger locally generated dial tone.
アナログ回線の場合は、ダイヤルトーンは、常にローカルスイッチによって生成されます。 ISDN端末は、ローカルにダイヤルトーンを生成し、ダイヤルされた数字を含むQ.931 SETUPメッセージを送信することができます。端末はただの着信側桁なしでSETUPメッセージを送信した場合、スイッチは、キーパッド・メッセージなどの端末が提供する数字収集を行い、及びB-チャネルを介してダイヤルトーンを提供します。端末はBチャネル上でオーディオ信号を使用するか、またはローカルに生成されたダイヤルトーンをトリガするためにQ.931メッセージを使用することができます。
Ringing tone (also called ringback tone) is generated by the local switch at the callee, with a one-way voice path opened up as soon as the callee's phone rings. (This reduces the chance of clipping the called party's response just after answer. It also permits pre-answer announcements or in-band call-progress indications to reach the caller before or in lieu of a ringing tone.) Congestion tone and special information tones can be generated by any of the switches along the way, and may be generated by the caller's switch based on ISUP messages received. Busy tone is generated by the caller's switch, triggered by the appropriate ISUP message, for analog instruments, or the ISDN terminal.
音を鳴らす（とも呼ばれるリングバックトーン）呼び出し先の電話が鳴るとすぐに開け一方向の音声パスで、呼び出し先のローカルスイッチによって生成されます。 （これは単に答えた後、着信側の応答をクリッピングする可能性を低減します。また、前または呼び出し音の代わりに、発信者に到達する前の回答の発表やインバンドコールプログレスの表示を可能にします。）輻輳トーンと特別な情報トーン道に沿ってスイッチのいずれかによって生成することができ、受信したISUPメッセージに基づいて発信者のスイッチによって生成されてもよいです。ビジートーンは、発呼者のアナログ機器の適切なISUPメッセージによってトリガスイッチ、またはISDN端末によって生成されます。
Gateways which send signaling events via RTP MAY send both named signals (Section 3) and the tone representation (Section 4) as a single RTP session, using the redundancy mechanism defined in Section 3.7 to interleave the two representations. It is generally a good idea to send both, since it allows the receiver to choose the appropriate rendering.
RTPを介したシグナル伝達イベントを送信するゲートウェイは2つの表現をインターリーブするセクション3.7で定義された冗長メカニズムを使用して、単一のRTPセッションの両方として命名信号（セクション3）と階調表現（セクション4）を送信することができます。それは、受信機が適切なレンダリングを選択することができますので、両方を送信するために、一般的には良いアイデアです。
If a gateway cannot present a tone representation, it SHOULD send the audio tones as regular RTP audio packets (e.g., as payload format PCMU), in addition to the named signals.
ゲートウェイは階調表現を提示できない場合、名前付き信号に加えて、定期的なRTPオーディオ・パケット（例えば、ペイロードフォーマットPCMUなど）のようなオーディオ・トーンを送信するべきです。
3 RTP Payload Format for Named Telephone Events
名前付き電話のイベントのための3 RTPペイロードフォーマット
The payload format for named telephone events described below is suitable for both gateway and end-to-end scenarios. In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN recreates the DTMF tones or other telephony events and injects them into the PSTN. Since, for example, DTMF digit recognition takes several tens of milliseconds, the first few milliseconds of a digit will arrive as regular audio packets. Thus, careful time and power (volume) alignment between the audio samples and the events is needed to avoid generating spurious digits at the receiver.
以下に記載する名前、電話イベントのペイロードフォーマットは、ゲートウェイとエンドツーエンドのシナリオの両方に適しています。ゲートウェイのシナリオでは、PSTNへのパケット音声ネットワークを接続するインターネットテレフォニーゲートウェイは、DTMFトーン、または他の電話イベントを再現し、PSTNにそれらを注入します。例えば、DTMFディジット認識は数十ミリ秒かかりますので、数字の最初の数ミリ秒は、通常のオーディオパケットとして到着します。このように、音声サンプルとイベントとの間の慎重な時間と電力（体積）のアライメントは、受信機でのスプリアス桁の発生を回避するために必要とされます。
DTMF digits and named telephone events are carried as part of the audio stream, and MUST use the same sequence number and time-stamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. The default clock frequency is 8,000 Hz, but the clock frequency can be redefined when assigning the dynamic payload type.
DTMFディジットと名付けられた電話イベントは、オーディオストリームの一部として実施され、ゲートウェイで音声波形の生成を簡素化するために通常のオーディオチャンネルと同じシーケンス番号とタイムスタンプベースを使用しなければなりません。デフォルトのクロック周波数は、8,000ヘルツであるが、ダイナミックペイロードタイプを割り当てるときにクロック周波数を再定義することができます。
The payload format described here achieves a higher redundancy even in the case of sustained packet loss than the method proposed for the Voice over Frame Relay Implementation Agreement [4].
ここで説明したペイロードフォーマットは、フレームリレー実装契約ボイスオーバーのために提案された方法[4]よりも持続的なパケット損失の場合には、より高い冗長性を実現します。
If an end system is directly connected to the Internet and does not need to generate tone signals again, time alignment and power levels are not relevant. These systems rely on PSTN gateways or Internet end systems to generate DTMF events and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice-response (IVR) system.
エンドシステムが直接インターネットに接続され、再びトーン信号を生成する必要がない場合、タイムアラインメントおよび電力レベルは関連しません。これらのシステムは、DTMFイベントを生成するために、独自のオーディオ波形解析を実行していないPSTNゲートウェイまたはインターネットエンドシステムに依存しています。そのようなシステムの一例は、インターネット、対話型音声応答（IVR）システムです。
In circumstances where exact timing alignment between the audio stream and the DTMF digits or other events is not important and data is sent unicast, such as the IVR example mentioned earlier, it may be preferable to use a reliable control protocol rather than RTP packets. In those circumstances, this payload format would not be used.
オーディオストリームとDTMFディジットまたは他のイベントとの間の正確なタイミング整列が重要データでない状況では、このような前述したIVRの例として、ユニキャスト送信され、RTPパケットではなく、信頼性の高い制御プロトコルを使用することが好ましいです。これらの状況では、このペイロードフォーマットが使用されません。
A source MAY send events and coded audio packets for the same time instants, using events as the redundant encoding for the audio stream, or it MAY block outgoing audio while event tones are active and only send named events as both the primary and redundant encodings.
ソースは、オーディオストリームのための冗長符号化などのイベントを使用して、同じ時間瞬間のイベントと符号化されたオーディオパケットを送信することができる、またはそれは、イベント・トーンがアクティブである間、送信オーディオブロックのみプライマリおよび冗長符号化と命名イベントを送信することができます。
Note that a period covered by an encoded tone may overlap in time with a period of audio encoded by other means. This is likely to occur at the onset of a tone and is necessary to avoid possible errors in the interpretation of the reproduced tone at the remote end. Implementations supporting this payload format must be prepared to handle the overlap. It is RECOMMENDED that gateways only render the encoded tone since the audio may contain spurious tones introduced by the audio compression algorithm. However, it is anticipated that these extra tones in general should not interfere with recognition at the far end.
符号化されたトーンの対象期間は、他の手段によって符号化されたオーディオの期間と時間的に重なっていてもよいことに留意されたいです。これは、音の開始時に発生する可能性があるとリモートエンドで再生音の解釈の可能性のあるエラーを回避する必要があります。このペイロード・フォーマットをサポートする実装は、重複を処理するために用意されなければなりません。オーディオは、オーディオ圧縮アルゴリズムによって導入されたスプリアストーンが含まれていてもよいので、ゲートウェイが唯一のエンコードされたトーンをレンダリングすることが推奨されます。しかし、一般的にはこれらの余分なトーンが遠端の認識を妨害してはならないことが予想されます。
This payload format is used for five different types of signals:
このペイロードフォーマットは信号の5種類のために使用されます。
o DTMF tones (Section 3.10);
OのDTMFトーン（3.10）。
o fax-related tones (Section 3.11);
Oファックス関連トーン（セクション3.11）。
o standard subscriber line tones (Section 3.12);
O標準加入者線トーン（セクション3.12）。
o country-specific subscriber line tones (Section 3.13) and;
国固有の加入者線トーン（セクション3.13）O;および
o trunk events (Section 3.14).
Oトランクイベント（3.14節）。
A compliant implementation MUST support the events listed in Table 1 with the exception of "flash". If it uses some other, out-of-band mechanism for signaling line conditions, it does not have to implement the other events.
準拠した実装は、「フラッシュ」を除いて、表1に記載されているイベントをサポートしなければなりません。それは回線の状態を知らせるためのいくつかの他、アウトオブバンドメカニズムを使用している場合、それは他のイベントを実装する必要はありません。
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 3.9 specifies how an implementation can use the SDP "fmtp" parameter within an SDP description to indicate its inability to understand a particular event or range of events.
いくつかのケースでは、実装は、単に特定の環境では意味がありません、このようなファックストーンなどの特定のイベントを、無視してもよいです。 3.9節では、実装がイベントの特定のイベントや範囲を理解する能力がないことを示すために、SDP記述の中にSDP「のfmtp」パラメータを使用する方法を指定します。
Depending on the available user interfaces, an implementation MAY render all tones in Table 5 the same or, preferably, use the tones conveyed by the concurrent "tone" payload or other RTP audio payload. Alternatively, it could provide a textual representation.
利用可能なユーザインタフェースに応じて、実装は、表5のすべてのトーン同じレンダリングもよく、または、好ましくは、同時「トーン」ペイロード又は他のRTPオーディオペイロードによって搬送トーンを使用します。また、それはテキスト表現を提供することができます。
Note that end systems that emulate telephones only need to support the events described in Sections 3.10 and 3.12, while systems that receive trunk signaling need to implement those in Sections 3.10, 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line" signals. Systems that do not support fax or modem functionality do not need to render fax-related events described in Section 3.11.
MFトランクはまた、「ラインのほとんどを運ぶことから、3.12と3.14、3.11、トランクシグナリングを受けるシステムは、セクション3.10のものを実装する必要がありながら、電話が唯一、セクション3.10と3.12で説明したイベントをサポートする必要がエミュレートすることエンドシステムに注意してください。 「信号。ファックスまたはモデム機能をサポートしていないシステムでは、セクション3.11で説明ファックス関連のイベントをレンダリングする必要はありません。
The RTP payload format is designated as "telephone-event", the MIME type as "audio/telephone-event". The default timestamp rate is 8000 Hz, but other rates may be defined. In accordance with current practice, this payload format does not have a static payload type number, but uses a RTP payload type number established dynamically and out-of-band.
RTPペイロードフォーマットは、「電話イベント」、「オーディオ/電話イベント」などのMIMEタイプとして指定されます。デフォルトのタイムスタンプ・レートは8000 Hzであるが、他のレートが定義されてもよいです。現在の慣行に従って、このペイロードフォーマットは、静的なペイロードタイプ番号を有するが、動的に帯域外確立されたRTPペイロードタイプ番号を使用しません。
Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section
3.5 extends forwards from that time. The receiver calculates
jitter for RTCP receiver reports based on all packets with a
given timestamp. Note: The jitter value should primarily be
used as a means for comparing the reception quality between
two users or two time-periods, not as an absolute measure.
Marker bit: The RTP marker bit indicates the beginning of a new event.
マーカービット：RTPマーカービットは新しいイベントの始まりを示します。
The payload format is shown in Fig. 1.
ペイロード・フォーマットは、図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Payload Format for Named Events
図1：名前付きイベントのペイロードフォーマット
events: The events are encoded as shown in Sections 3.10 through 3.14.
イベント：3.14を通じてセクション3.10に示すようにイベントが符号化されます。
volume: For DTMF digits and other events representable as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger values denote lower volume. This value is defined only for DTMF digits. For other events, it is set to zero by the sender and is ignored by the receiver.
体積：DTMF桁とトーンとして表現他のイベントの場合、このフィールドはトーンのパワーレベルを記述し、符号を落とした後にdBm0でで発現。パワー・レベルは、0からdBm0で-63の範囲。有効なDTMFの範囲は0から-36 dBm0で（受け入れなければならない）にあります。より低い-55 dBm0では拒絶されなければならない（TR-TSY-000181、ITU-T Q.24A）。したがって、より大きな値は、より低い量を示します。この値は、DTMFディジットのために定義されています。他のイベントのためには、送信者によってゼロに設定され、受信機によって無視されます。
duration: Duration of this digit, in timestamp units. Thus, the event began at the instant identified by the RTP timestamp and has so far lasted as long as indicated by this parameter. The event may or may not have ended.
所要時間：タイムスタンプユニットで、この数字の期間、。このように、イベントはRTPタイムスタンプで識別される瞬間に始まり、これまでに限り、このパラメータによって示されるように続いています。イベントは、または終了していない可能性があります。
For a sampling rate of 8000 Hz, this field is sufficient to
express event durations of up to approximately 8 seconds.
E: If set to a value of one, the "end" bit indicates that this packet contains the end of the event. Thus, the duration parameter above measures the complete duration of the event.
E：1の値に設定した場合は、「終了」ビットは、このパケットは、イベントの終了が含まれていることを示しています。したがって、上記期間のパラメータは、イベントの完全な時間を測定します。
A sender MAY delay setting the end bit until retransmitting
the last packet for a tone, rather than on its first
transmission. This avoids having to wait to detect whether
the tone has indeed ended.
Receiver implementations MAY use different algorithms to create tones, including the two described here. In the first, the receiver simply places a tone of the given duration in the audio playout buffer at the location indicated by the timestamp. As additional packets are received that extend the same tone, the waveform in the playout buffer is extended accordingly. (Care has to be taken if audio is mixed, i.e., summed, in the playout buffer rather than simply copied.) Thus, if a packet in a tone lasting longer than the packet interarrival time gets lost and the playout delay is short, a gap in the tone may occur. Alternatively, the receiver can start a tone and play it until it receives a packet with the "E" bit set, the next tone, distinguished by a different timestamp value or a given time period elapses. This is more robust against packet loss, but may extend the tone if all retransmissions of the last packet in an event are lost. Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless.
受信機の実装は、ここで説明した2つを含むトーンを、作成するために、異なるアルゴリズムを使用するかもしれません。最初に、受信機は、単にタイムスタンプによって示される位置でのオーディオ再生バッファ内の指定された持続時間のトーンを配置します。追加のパケットは、同じトーンを拡張が受信されると、再生バッファの波形はそれに応じて延長されます。 （ケアは、オーディオが混合されている場合は注意しなければならない、すなわち、再生バッファではなく、単にコピーして、合算。）したがって、パケット間時間よりも長く持続音でパケットが失われると、プレイアウト遅延が短い場合、Aトーンのギャップが生じる可能性があります。あるいは、受信機は、トーンを開始し、それは異なるタイムスタンプ値または経過一定期間によって区別「E」ビットセット、次のトーンを有するパケットを受信するまで、それを再生することができます。これは、パケット損失に対してより堅牢であるが、イベントの最後のパケットのすべての再送が失われた場合のトーンを延長することができます。トーンを延長する期間を制限することで、トーンは「立ち往生」することを回避する必要があります。関係なく使用されるアルゴリズムの、トーンがつ以上のパケット間時間によって拡張されるべきではありません。一時停止のわずかな音長の延長や短縮が一般的に無害です。
R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it.
R：このフィールドは、将来の使用のために予約されています。送信側は受信側がそれを無視しなければなりません、それをゼロに設定しなければなりません。
An audio source SHOULD start transmitting event packets as soon as it recognizes an event and every 50 ms thereafter or the packet interval for the audio codec used for this session, if known. (The sender does not need to maintain precise time intervals between event packets in order to maintain precise inter-event times, since the timing information is contained in the timestamp.)
知られている場合は、オーディオソースは、できるだけ早くそれがイベントを認識し、50ms毎、その後、またはこのセッションのために使用されるオーディオコーデックのパケット間隔としてイベントパケットの送信を開始する必要があります。 （送信タイミング情報は、タイムスタンプに含まれているため、正確なイベント間の時間を維持するために、イベントパケット間の正確な時間間隔を維持する必要はありません。）
Q.24 [5], Table A-1, indicates that all administrations surveyed use a minimum signal duration of 40 ms, with signaling velocity (tone and pause) of no less than 93 ms.
Q.24 [5]は、表A-1は、すべての投与がない未満93ミリ秒の速度（トーンを一時停止）シグナリングを用いて、40ミリ秒の最小信号期間を使用調査することを示しています。
If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly. (The RTP sequence number is incremented by one for each packet.) If there has been no new event in the last interval, the event SHOULD be retransmitted three times or until the next event is recognized. This ensures that the duration of the event can be recognized correctly even if the last packet for an event is lost.
イベントが複数の期間継続した場合、イベントの発生源は、RTPタイムスタンプ値は、イベントの開始に対応し、イベントの期間が対応して増加した新しいイベントパケットを送信する必要があります。 （RTPシーケンス番号は、パケット毎に1ずつインクリメントされる。）最後の間隔で新たなイベントがなかった場合は、イベントが3回を再送信するか、次のイベントが認識されるまで。これは、イベントの期間は、イベントの最後のパケットが失われた場合でも、正確に認識できることを保証します。
DTMF digits and events are sent incrementally to avoid having the receiver wait for the completion of the event. Since some tones are two seconds long, this would incur a substantial delay. The transmitter does not know if event length is important and thus needs to transmit immediately and incrementally. If the receiver application does not care about event length, the incremental transmission mechanism avoids delay. Some applications, such as gateways into the PSTN, care about both delays and event duration.
DTMFディジットおよびイベントは、イベントの完了を受信待ちを避けるためにインクリメンタルに送信されます。いくつかのトーンが2秒の長さであるので、これはかなりの遅れを招くだろう。イベントの長さが重要であるため、すぐにインクリメンタルに送信する必要がある場合、送信は知りません。受信側アプリケーションは、イベントの長さを気にしない場合、増分伝達機構は、遅延を回避します。このようPSTNへのゲートウェイなどの一部のアプリケーションでは、遅延やイベント期間の両方を気に。
During an event, the RTP event payload format provides incremental updates on the event. The error resiliency depends on the playout delay at the receiver. For example, for a playout delay of 120 ms and a packet gap of 50 ms, two packets in a row can get lost without causing a gap in the tones generated at the receiver.
イベント期間中、RTPイベントペイロードフォーマットは、イベントの増分更新を提供します。エラー耐性は、受信機でのプレイアウト遅延に依存します。例えば、120ミリ秒のプレイアウト遅延と50ミリ秒のパケットギャップのために、行に2つのパケットは、受信機で生成されたトーンに隙間を生じさせることなく、迷子ができます。
The audio redundancy mechanism described in RFC 2198 [6] MAY be used to recover from packet loss across events. The effective data rate is r times 64 bits (32 bits for the redundancy header and 32 bits for the telephone-event payload) every 50 ms or r times 1280 bits/second, where r is the number of redundant events carried in each packet. The value of r is an implementation trade-off, with a value of 5 suggested.
RFC 2198に記載のオーディオ冗長機構[6]イベントを横切るパケット損失から回復するために使用されるかもしれません。 rは各パケットで運ばれた冗長イベントの数である有効データレートは1280ビット/秒r回64ビット（冗長ヘッダの32ビットと電話イベントペイロードの32ビット）毎に50ミリ秒またはR倍です。 Rの値は5の値を示唆して、実装のトレードオフです。
The timestamp offset in this redundancy scheme has 14 bits, so that it allows a single packet to "cover" 2.048 seconds of telephone events at a sampling rate of 8000 Hz. Including the starting time of previous events allows precise reconstruction of the tone sequence at a gateway. The scheme is resilient to consecutive packet losses spanning this interval of 2.048 seconds or r digits, whichever is less. Note that for previous digits, only an average loudness can be represented.
それは、単一のパケットは8000ヘルツのサンプリングレートで電話イベントの2.048秒を「カバー」することを可能にするように、この冗長方式でのオフセットタイムスタンプは、14ビットを有します。以前のイベントの開始時間を含めてゲートウェイでトーンシーケンスの正確な再構成を可能にします。スキームは、小さい方2.048秒またはr桁のこの間隔にまたがる連続したパケット損失に弾性です。前の数字のために、唯一の平均ラウドネスを表すことができることに留意されたいです。
An encoder MAY treat the event payload as a highly-compressed version of the current audio frame. In that mode, each RTP packet during an event would contain the current audio codec rendition (say, G.723.1 or G.729) of this digit as well as the representation described in Section 3.5, plus any previous events seen earlier.
エンコーダは、現在の音声フレームの高圧縮バージョンとしてイベントペイロードを扱うかもしれ。このモードでは、イベント中に各RTPパケットは、この桁の現在のオーディオコーデックレンディション（例えば、G.723.1またはG.729）並びにセクション3.5に記載表現、プラス以前見た以前のイベントを含むであろう。
This approach allows dumb gateways that do not understand this format to function. See also the discussion in Section 1.
このアプローチは、関数にこの形式を理解していないダムゲートウェイを可能にします。また、第1節での議論を参照してください。
A typical RTP packet, where the user is just dialing the last digit of the DTMF sequence "911". The first digit was 200 ms long (1600 timestamp units) and started at time 0, the second digit lasted 250 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp units), the third digit was pressed at time 1.4 s (11,200 timestamp units) and the packet shown was sent at 1.45 s (11,600 timestamp units). The frame duration is 50 ms. To make the parts recognizable, the figure below ignores byte alignment. Timestamp and sequence number are assumed to have been zero at the beginning of the first digit. In this example, the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the telephone event payload, respectively.
ユーザーは単にDTMFシーケンス「911」の最後の桁をダイヤルしている典型的なRTPパケット。最初の数字は、200ミリ秒の長い（1600タイムスタンプユニット）であり、時間0で開始し、第二の数字は250ミリ秒（2000タイムスタンプユニット）続き、（6400タイムスタンプユニット）、3桁目は1.4秒時点で押された時間800ミリ秒で開始しました（11,200タイムスタンプ単位）および1.45秒（11,600タイムスタンプユニット）で送信されたパケットを示します。フレーム持続時間は50ミリ秒です。部品が認識できるようにするには、以下の図は、バイトアラインメントを無視します。タイムスタンプとシーケンス番号は、最初の数字の先頭にゼロをされているものとされています。この例では、ダイナミックペイロードタイプ96及び97は、それぞれ、冗長機構と電話イベントペイロードのために割り当てられています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example RTP packet after dialing "911"
図2：「911」をダイヤルした後の例RTPパケット
Receivers MAY indicate which named events they can handle, for example, by using the Session Description Protocol (RFC 2327 [7]). The payload formats use the following fmtp format to list the event values that they can receive:
レシーバは、例えば、セッション記述プロトコル（RFC 2327 [7]）を使用することによって、彼らが扱うことができるイベントを命名するかを示すかもしれません。ペイロード形式は、彼らが受け取ることができるイベント値をリストするには、次のfmtpの形式を使用します。
a=fmtp:<format> <list of values>
=のfmtp：<フォーマット>は<値リスト>
The list of values consists of comma-separated elements, which can be either a single decimal number or two decimal numbers separated by a hyphen (dash), where the second number is larger than the first. No whitespace is allowed between numbers or hyphens. The list does not have to be sorted.
値のリストは、単一の10進数または第二の番号が最初より大きいハイフン（ダッシュ）で区切られた2つの小数のいずれかとすることができるカンマ区切りの要素から構成されています。空白文字は、数字やハイフンの間で許可されていません。リストをソートする必要はありません。
For example, if the payload format uses the payload type number 100, and the implementation can handle the DTMF tones (events 0 through 15) and the dial and ringing tones, it would include the following description in its SDP message:
例えば、ペイロード・フォーマットは、ペイロードタイプ番号100を使用し、実装はDTMFトーン（イベント0〜15）とダイヤルと着信音を扱うことができるならば、それはそのSDPメッセージ内の次の説明を含むであろう。
a=fmtp:100 0-15,66,70
=のfmtp：100 0-15,66,70
Since all implementations MUST be able to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL.
すべての実装は、A =のfmtpラインにこれらのイベントをリスト、0〜15のイベントを受け取ることができなければならないので任意です。
The corresponding MIME parameter is "events", so that the following sample media type definition corresponds to the SDP example above:
次のサンプル・メディア・タイプ定義が上記のSDPの一例に相当するように、対応するMIMEパラメータは、「イベント」であります
audio/telephone-event;events="0-11,66,67";rate="8000"
オーディオ/電話イベント;イベント= "0-11,66,67";割合= "8000"
Table 1 summarizes the DTMF-related named events within the telephone-event payload format.
表1は、電話イベントペイロードフォーマット内DTMF関連という名前のイベントをまとめたもの。
Event encoding (decimal)
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16
Table 1: DTMF named events
表1：DTMFという名前のイベント
Table 3.11 summarizes the events and tones that can appear on a subscriber line serving a fax machine or modem. The tones are described below, with additional detail in Table 7.
表3.11は、ファックスまたはモデムを提供する加入者線で表示されますイベントやトーンをまとめたもの。トーンは、表7にさらに詳細と共に、以下に記載されています。
ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for data transmission [8,9]. For fax machines, Recommendation T.30 [9] refers to this tone as called terminal identification (CED) answer tone.
ANS：この2100 +/- 15 Hzのトーンは、データ伝送[8,9]のために、エコー抑制を無効にするために使用されます。ファックスため、勧告T.30 [9]と呼ばれる端末識別（CED）応答トーンとしてトーンを指します。
/ANS: This is the same signal as ANS, except that it reverses phase at an interval of 450 +/- 25 ms. It disables both echo cancellers and echo suppressors. (In the ITU Recommendation V.25 [8], this signal is rendered as ANS with a bar on top.)
/ ANS：これは450 +/- 25ミリ秒の間隔で位相を反転させることを除いて、ANSと同じ信号です。これは、エコーキャンセラとエコー抑制の両方を無効にします。 （ITU勧告V.25に[8]、この信号は上バー付きANSとしてレンダリングされています。）
ANSam: The modified answer tone (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz without phase reversals, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone is sent by modems if network echo canceller disabling is not required.
ANSamの：修飾された応答トーン（ANSamの）[3]位相反転無し2100 +/- 1 Hzでの正弦波信号は、振幅変調15 +/- 0.1 Hzで正弦波によって。ネットワークエコーキャンセラ無効化が必要とされていない場合は、このトーンがモデムによって送信されます。
/ANSam: The modified answer tone with phase reversals (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz with phase reversals at intervals of 450 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11] and faxes to disable echo suppressors.
/ ANSamの：位相反転を有する改変応答トーン（ANSamの）[3] 450 +/- 25ミリ秒の間隔で位相反転の2100 +/- 1 Hzでの正弦波信号である振幅変調15で正弦波によって+ / - 0.1ヘルツ。このトーン[10,8]は、エコー抑制を無効にするには、モデム、[11]やファックスで送信されます。
CNG: After dialing the called fax machine's telephone number (and before it answers), the calling Group III fax machine (optionally) begins sending a CalliNG tone (CNG) consisting of an interrupted tone of 1100 Hz. [9]
CNGは：（とそれが応答する前に）と呼ばれるファックス機の電話番号をダイヤルした後、呼び出し元のグループIIIファックス機は（オプション）1100ヘルツの中断されたトーンからなる呼出音（CNG）を送信を開始します。 [9]
CRdi: Capabilities Request (CRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRdi is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to a CRe or MRe."
CRDI：機能要求（CRD）、側面を開始する、[12] 1375ヘルツと100ミリ1900 Hzの単一トーンに続く400ミリ秒、2002 Hzのトーンとデュアルトーン信号です。 「この信号は、情報転送モードに電話モードから遠隔局遷移を要求し、遠隔局によって機能リストメッセージの送信を要求する。特に、CRDIは、コールの過程で開始ステーションによって送信されるか、またはCREまたはMREに応じて、呼確立の駅を呼び出します。」
CRdr: CRdr is the response tone to CRdi (see above). It consists of a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms.
CRdr：CRdrはCRDIへの応答トーン（上記参照）です。それは100ミリ1900 Hzでシングルトーンが続く1529ヘルツと400ミリ秒間2225 Hzのトーンとデュアルトーン信号、から構成されています。
CRe: Capabilities Request (CRe) [12] is a dual-tone signal with tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 400 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRe is sent by an automatic answering station at call establishment."
CRE：機能要求（CRE）[12]は、100ミリ秒、400 Hzの単一トーンに続く1375ヘルツと400ミリ2002 Hzのトーンにおけるトーン、デュアルトーン信号です。 「この信号は、情報転送モードに電話モードから遠隔局遷移を要求し、遠隔局によって機能リストメッセージの送信を要求する。具体的には、CREは、呼確立時自動応答局によって送信されます。」
CT: "The calling tone [8] consists of a series of interrupted bursts of binary 1 signal or 1300 Hz, on for a duration of not less than 0.5 s and not more than 0.7 s and off for a duration of not less than 1.5 s and not more than 2.0 s." Modems not starting with the V.8 call initiation tone often use this tone.
CT：「呼出音[8]が1.5以上の期間以上0.5秒の持続時間以上、0.7秒間オンとオフ、バイナリ1信号又は1300ヘルツの中断バーストの系列から成り秒以上、2.0秒。」モデムは、多くの場合、このトーンを使うV.8コール開始口調で始まりません。
ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode. signal ESi is sent by the initiating station."
ESI：エスケープ信号（ESI）[12]は1375ヘルツと100ミリ秒間980 Hzの単一トーンに続く400ミリ秒、2002 Hzのトーンとデュアルトーン信号です。 「この信号は、情報転送モードに電話モードから遠隔局の移行を要求する。ESIは、開始ステーションによって送信される信号。」
ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1650 Hz for 100 ms. Same as ESi, but sent by the responding station.
ESR：エスケープ信号（ESR）[12]は1529ヘルツと100ミリ1650 Hzの単一トーンに続く400ミリ秒のための2225 Hzのトーンとデュアルトーン信号です。 ESIと同じですが、応答ステーションによって送られました。
MRdi: Mode Request (MRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms followed by a single tone at 1150 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRd is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to an MRe." [12]
MRdi：モード要求（MRD）は、サイドを開始する、[12] 1375ヘルツと100ミリ1150 Hzでシングルトーン続いて400ミリ2002 Hzのトーンとデュアルトーン信号です。 「この信号は、情報転送モードに電話モードから遠隔局遷移を要求し、遠隔局によってモード選択メッセージの送信を要求する。特に、MRDは、コールの過程で開始ステーションによって送信された、またはされた信号MREに応答した呼確立で発呼局。」 [12]
MRdr: MRdr is the response tone to MRdi (see above). It consists of a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1150 Hz for 100 ms.
MRdr：MRdrはMRdiへの応答トーン（上記参照）です。それは100ミリ1150 Hzでシングルトーンが続く1529ヘルツと400ミリ秒間2225 Hzのトーンとデュアルトーン信号、から構成されています。
MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRe is sent by an automatic answering station at call establishment." [12]
MRE：モード要求（MRE）[12]は1375ヘルツと100ミリ秒間650 Hzの単一トーンに続く400ミリ秒、2002 Hzのトーンとデュアルトーン信号です。 「この信号は情報転送モードに電話モードから遠隔局遷移を要求し、遠隔局によってモード選択メッセージの送信を要求する。具体的には、信号MREは、呼確立時自動応答局によって送信されます。」 [12]
V.21: V.21 describes a 300 b/s full-duplex modem that employs frequency shift keying (FSK). It is used by Group 3 fax machines to exchange T.30 information. The calling transmits on channel 1 and receives on channel 2; the answering modem transmits on channel 2 and receives on channel 1. Each bit value has a distinct tone, so that V.21 signaling comprises a total of four distinct tones.
V.21：V.21は、周波数シフトキーイング（FSK）を用い300 B / sの全二重モデムを記述する。 T.30情報を交換するために、グループ3ファックス機で使用されています。呼び出し側は、チャネル1上で送信し、チャンネル2で受信します。応答モデムは、チャネル2上で送信し、チャンネル1で受信V.21シグナリングは、4つの異なるトーンの合計を含むように、各ビットの値は、異なるトーンを有します。
In summary, procedures in Table 2 are used.
要約すると、表2の手順が使用されています。
Procedure indications
___________________________________________________
V.25 and V.8 ANS
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam
V.8, echo canceller disabled /ANSam
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations
表2：V.x勧告でANSの使用、ANSamのおよび/ ANSamの
Event encoding (decimal)
___________________________________________________
Answer tone (ANS) 32
/ANS 33
ANSam 34
/ANSam 35
Calling tone (CNG) 36
V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRdi 41
CRdr 42
CRe 43
ESi 44
ESr 45
MRdi 46
MRdr 47
MRe 48
CT 49
Table 3: Data and fax named events
表3：データとファックスという名前のイベント
Table 4 summarizes the events and tones that can appear on a subscriber line.
表4は、加入者線上に現れることができ、イベントやトーンをまとめたもの。
ITU Recommendation E.182 [13] defines when certain tones should be used. It defines the following standard tones that are heard by the caller:
ITU勧告E.182 [13]特定のトーンが使用されるべき場合を定義します。これは、発信者によって聞かれ、次の標準的なトーンを定義しています。
Dial tone: The exchange is ready to receive address information.
トーンダイヤル：交換は、アドレス情報を受信する準備ができています。
PABX internal dial tone: The PABX is ready to receive address information.
PABX内部ダイヤルトーン：PABXは、アドレス情報を受信する準備ができています。
Special dial tone: Same as dial tone, but the caller's line is subject to a specific condition, such as call diversion or a voice mail is available (e.g., "stutter dial tone").
特別なダイヤルトーン：な着信転送やボイスメールなどのダイヤルトーンと同じですが、呼び出し側のラインは、特定の条件の対象となるには、利用可能である（例えば、「スタッターダイヤルトーン」）。
Second dial tone: The network has accepted the address information, but additional information is required.
2番目のダイヤルトーン：ネットワークアドレス情報を受け入れているが、追加の情報が必要です。
Ring: This named signal event causes the recipient to generate an alerting signal ("ring"). The actual tone or other indication used to render this named event is left up to the receiver. (This differs from the ringing tone, below, heard by the caller
リング：この名前の信号イベントは、受信者が警告信号（「リング」）を発生させます。この名前付きイベントをレンダリングするために使用される実際のトーンまたは他の表示は、受信機に委ねられています。 （これは、発信者が聞く、以下、呼出音とは異なり
Ringing tone: The call has been placed to the callee and a calling signal (ringing) is being transmitted to the callee. This tone is also called "ringback".
着信音：呼び出しが呼び出し先に置かれていると、呼び出し信号（リンギング）が呼び出し先に送信されています。このトーンはまた、「リングバック」と呼ばれています。
Special ringing tone: A special service, such as call forwarding or call waiting, is active at the called number.
特別な着信音：特別なサービスは、そのような着信転送やコールウェイティングなどは、着信番号でアクティブです。
Busy tone: The called telephone number is busy.
ビジートーン：呼び出された電話番号が使用中です。
Congestion tone: Facilities necessary for the call are temporarily unavailable.
輻輳トーン：コールのために必要な施設が一時的に利用できません。
Calling card service tone: The calling card service tone consists of 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone), decaying exponentially with a time constant of 200 ms.
、（米国はダイヤルトーン）コーリングカードサービストーンが350ヘルツと440ヘルツの940ミリ秒に続いて941 Hzから1477 Hzのトーン（DTMF「＃」）の合計の60ミリ秒、で構成されて指数関数的に減衰する：カードサービストーンを呼び出します200ミリ秒の時定数。
Special information tone: The callee cannot be reached, but the reason is neither "busy" nor "congestion". This tone should be used before all call failure announcements, for the benefit of automatic equipment.
特別な情報トーン：呼び出し先に到達することはできませんが、その理由は「忙しい」や「渋滞」もありません。このトーンは、自動化装置の利益のために、すべてのコールの失敗の発表の前に使用する必要があります。
Comfort tone: The call is being processed. This tone may be used during long post-dial delays, e.g., in international connections.
コンフォートトーン：コールが処理されています。このトーンは、国際的な接続では、例えば、長いポストダイヤル遅延の際に使用することができます。
Hold tone: The caller has been placed on hold.
トーンをホールド：呼び出し側が保留にされています。
Record tone: The caller has been connected to an automatic answering device and is requested to begin speaking.
レコードの音：呼び出し側が自動応答デバイスに接続されていたと話して開始するように要求されています。
Caller waiting tone: The called station is busy, but has call waiting service.
発信者ウェイティングトーン：相手局がビジー状態であるが、キャッチホンサービスを提供しています。
Pay tone: The caller, at a payphone, is reminded to deposit additional coins.
トーンを支払う：呼び出し側は、公衆電話で、追加のコインを堆積させるために思い出されます。
Positive indication tone: The supplementary service has been activated.
正のインディケーショントーン：付加サービスが活性化されています。
Negative indication tone: The supplementary service could not be activated.
負のインディケーショントーン：付加サービスを起動することができませんでした。
Off-hook warning tone: The caller has left the instrument off-hook for an extended period of time.
オフフック警告音：呼び出し側は、長時間のオフフック楽器を残しています。
The following tones can be heard by either calling or called party during a conversation:
次のトーンは、会話中にいずれかの呼び出しによって聞かやパーティー呼び出すことができます。
Call waiting tone: Another party wants to reach the subscriber.
トーンを待っているコール：別のパーティは、加入者に到達したいと考えています。
Warning tone: The call is being recorded. This tone is not required in all jurisdictions.
警告音：通話が録音されています。このトーンは、すべての国で必要とされていません。
Intrusion tone: The call is being monitored, e.g., by an operator.
侵入トーン：コールは、オペレータによって、例えば、監視されています。
CPE alerting signal: A tone used to alert a device to an arriving in-band FSK data transmission. A CPE alerting signal is a combined 2130 and 2750 Hz tone, both with tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE alerting signal is used with ADSI services and Call Waiting ID services [14].
CPE警告信号：到着インバンドFSKデータ伝送にデバイスを警告するために使用されるトーン。 CPEアラート信号は、0.5％の公差及び80の持続時間との両方を合わせ2130および2750 Hzのトーンです。 80ミリ秒。 CPE警告信号は、ADSIサービスとキャッチホンIDサービス[14]で使用されています。
The following tones are heard by operators:
次のトーンはオペレータが聞かれます。
Payphone recognition tone: The person making the call or being called is using a payphone (and thus it is ill-advised to allow collect calls to such a person).
公衆電話認識トーン：人は電話をかけるか、公衆電話を使用している（したがって、そのような人に呼び出しを収集できるように無分別される）と呼ばれています。
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Table 4: E.182 line events
表4：E.182ラインイベント
Table 5 summarizes country-specific events and tones that can appear on a subscriber line.
表5は、加入者回線上で表示されることが国固有のイベントやトーンをまとめたもの。
Table 6 summarizes the events and tones that can appear on a trunk. Note that trunk can also carry line events (Section 3.12), as MF signaling does not include backward signals [15].
表6は、トランクの上に表示されますイベントやトーンをまとめたもの。 MFシグナリングは逆方向信号[15]を含まないように、そのトランクは、ラインイベント（3.12）を運ぶことができます。
ABCD transitional: 4-bit signaling used by digital trunks. For N-state signaling, the first N values are used.
ABCD過渡：デジタルトランクで使用される4ビットのシグナリング。 N状態のシグナリングのために、最初のN個の値が使用されています。
Event encoding (decimal)
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112
Table 5: Country-specific Line events
表5：国別のラインイベント
The T1 ESF (extended super frame format) allows 2, 4, and 16 state signaling bit options. These signaling bits are named A, B, C, and D. Signaling information is sent as robbed bits in frames 6, 12, 18, and 24 when using ESF T1 framing. A D4 superframe only transmits 4-state signaling with A and B bits. On the CEPT E1 frame, all signaling is carried in timeslot 16, and two channels of 16-state (ABCD) signaling are sent per frame.
T1 ESF（拡張スーパーフレームフォーマット）は、2を許可4、及び16の状態シグナリングビットオプション。これらのシグナリングビットは、A、B、Cと命名され、ESF T1フレーミングを使用する場合D.シグナリング情報を奪われ、フレーム6のビット、12、18、及び24として送信されます。 D4スーパーフレームは、4状態は、AとBビットでシグナリングを送信します。 CEPT E1フレームに、すべてのシグナリングは、タイムスロット16で運ばれ、16状態（ABCD）シグナリングの二つのチャンネルは、フレームごとに送信されます。
Since this information is a state rather than a changing signal, implementations SHOULD use the following triple-redundancy mechanism, similar to the one specified in ITU-T Rec. I.366.2 [16], Annex L. At the time of a transition, the same ABCD information is sent 3 times at an interval of 5 ms. If another transition occurs during this time, then this continues. After a period of no change, the ABCD information is sent every 5 seconds.
この情報は状態ではなく変化する信号であるため、実装は、ITU-T勧告で指定されたものと同様、以下の三重の冗長機構を使用する必要があります。 I.366.2 [16]、附属書L.遷移時に、同じABCD情報は、5ミリ秒の間隔で3回送信されます。別の遷移がこの期間中に発生した場合、これは継続します。変更なしの期間の後、ABCDの情報は、5秒ごとに送信されます。
Wink: A brief transition, typically 120-290 ms, from on-hook (unseized) to off-hook (seized) and back to onhook, used by the incoming exchange to signal that the call address signaling can proceed.
ウインク：短い遷移、典型的にオンフック（unseized）120から290ミリ秒、オフフックコールアドレスシグナリングを進めることができることを通知するために、着信交換機によって使用されるバックオンフックに（押収）と、。
Incoming seizure: Incoming indication of call attempt (off-hook).
着信発作：コールの試み（オフフック）の着信表示。
Event encoding (decimal)
__________________________________________________
MF 0... 9 128...137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142...143
ABCD signaling (see below) 144...159
Wink 160
Wink off 161
Incoming seizure 162
Seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173
Table 6: Trunk events
表6：トランクのイベント
Seizure: Seizure by answering exchange, in response to outgoing seizure.
発作：送信発作に応じて、交換を答えることによって押収。
Unseize circuit: Transition of circuit from off-hook to on-hook at the end of a call.
Unseize回路：コールの終了時にオフフックからオンフックに回路の変遷。
Wink off: A brief transition, typically 100-350 ms, from off-hook (seized) to on-hook (unseized) and back to off-hook (seized). Used in operator services trunks.
ウィンクオフ：バックオフ・フックに簡単に移行、典型的には100~350ミリ秒、オフ・フックから（押収）オンフックに（unseized）及び（押収）。オペレータサービストランクで使用されます。
Continuity tone send: A tone of 2010 Hz.
継続トーンが送信：2010ヘルツの音を。
Continuity tone detect: A tone of 2010 Hz.
継続トーンが検出：2010ヘルツの音を。
Continuity test send: A tone of 1780 Hz is sent by the calling exchange. If received by the called exchange, it returns a "continuity verified" tone.
導通テストセンド：1780ヘルツの音を呼び出し交換により送信されます。呼ばれる交換によって受け取った場合、それは「継続性検証」のトーンを返します。
Continuity verified: A tone of 2010 Hz. This is a response tone, used in dual-tone procedures.
継続性を検証：2010ヘルツの音を。これは、デュアルトーンの手順で使用される応答トーン、です。
4 RTP Payload Format for Telephony Tones
テレフォニートーンのための4 RTPペイロードフォーマット
As an alternative to describing tones and events by name, as described in Section 3, it is sometimes preferable to describe them by their waveform properties. In particular, recognition is faster than for naming signals since it does not depend on recognizing durations or pauses.
名前によってトーンおよびイベントを記述する代わりに、セクション3で説明したように、彼らの波形特性によって、それらを記述することが好ましい場合があります。特に、認識は、それが継続時間やポーズの認識に依存しないため、信号に名前を付けるよりも高速です。
There is no single international standard for telephone tones such as dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones or some of the other special tones, such as payphone recognition, call waiting or record tone. However, across all countries, these tones share a number of characteristics [17]:
そのようなダイヤルトーン、リンギング（リングバック）、忙しい、輻輳（「速いビジー」）、特別な告知音や、公衆電話認識などの他の特殊なトーンの一部として電話トーンのための単一の国際規格はありませんが、呼び出しが待っているかの記録トーン。しかし、すべての国を横切って、これらのトーンは、多くの特性を共有する[17]。
o Telephony tones consist of either a single tone, the addition of two or three tones or the modulation of two tones. (Almost all tones use two frequencies; only the Hungarian "special dial tone" has three.) Tones that are mixed have the same amplitude and do not decay.
Oテレフォニートーンは、単一のトーン、2個または3個のトーンまたは2つのトーンの変調の添加のいずれかから成ります。 （ほとんどすべてのトーンが二つの周波数を使用し、唯一のハンガリーの「特別なダイヤルトーン」は、3を持っている。）と混合されているトーンが同じ振幅を持ち、減衰しません。
o Tones for telephony events are in the range of 25 (ringing tone in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz. The telephone frequency range is limited to 3,400 Hz. (The piano has a range from 27.5 to 4186 Hz.)
Oテレフォニーイベントのトーン1800ヘルツ25（アンゴラ着信音）の範囲です。 CEDは、2100 Hzで、最高使用トーンです。電話周波数範囲は、3,400ヘルツに制限されています。 （ピアノは27.5から4186ヘルツまでの範囲を有します。）
o Modulation frequencies range between 15 (ANSam tone) to 480 Hz (Jamaica). Non-integer frequencies are used only for frequencies of 16 2/3 and 33 1/3 Hz. (These fractional frequencies appear to be derived from older AC power grid frequencies.)
O変調周波数は、480ヘルツ（ジャマイカ）15（ANSamのトーン）の範囲です。非整数周波数はわずか16 2/3 33 1/3ヘルツの周波数のために使用されます。 （これらの端数の周波数は、旧式のAC電力網の周波数に由来すると思われます。）
o Tones that are not continuous have durations of less than four seconds.
連続していないOトーンは4秒以下の持続時間を有します。
o ITU Recommendation E.180 [18] notes that different telephone companies require a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%.
O ITU勧告E.180 [18]異なる電話会社は、0.5〜1.5％の階調精度を必要とすることに留意します。勧告は、1％の周波数公差を示唆しています。
As an aid to the implementor, Table 7 summarizes some common tones. The rows labeled "ITU ..." refer to the general recommendation of Recommendation E.180 [18]. Note that there are no specific guidelines for these tones. In the table, the symbol "+" indicates addition of the tones, without modulation, while "*" indicates amplitude modulation. The meaning of some of the tones is described in Section 3.12 or Section 3.11 (for V.21).
実装者への援助として、表7には、いくつかの一般的なトーンをまとめたもの。標識された行「ITUは...」勧告E.180 [18]の一般的な推薦を指します。これらのトーンのための具体的なガイドラインが存在しないことに注意してください。 「*」振幅変調を示している表では、記号「+」は、変調なしで、トーンの添加を示します。トーンの一部の意味は、3.12または（V.21用）セクション3.11に記載されています。
Tone name frequency on period off period
______________________________________________________
CNG 1100 0.5 3.0
V.25 CT 1300 0.5 2.0
CED 2100 3.3 --
ANS 2100 3.3 --
ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
ITU dial tone 425 -- --
U.S. dial tone 350+440 -- --
______________________________________________________
ITU ringing tone 425 0.67--1.5 3--5
U.S. ringing tone 440+480 2.0 4.0
ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
Table 7: Examples of telephony tones
表7：テレフォニートーンの例
Timestamp: The RTP timestamp reflects the measurement point for
the current packet. The event duration described in Section
3.5 extends forwards from that time.
Based on the characteristics described above, this document defines an RTP payload format called "tone" that can represent tones consisting of one or more frequencies. (The corresponding MIME type is "audio/tone".) The default timestamp rate is 8,000 Hz, but other rates may be defined. Note that the timestamp rate does not affect the interpretation of the frequency, just the durations.
上述の特性に基づいて、この文書は、1つ以上の周波数からなるトーンを表すことができる「トーン」と呼ばれるRTPペイロードフォーマットを定義します。 （対応するMIMEタイプが「オーディオ/トーン」である。）デフォルトのタイムスタンプレートは8,000ヘルツであるが、他のレートが定義されてもよいです。ちょうど期間、タイムスタンプ率は周波数の解釈に影響を与えないことに注意してください。
In accordance with current practice, this payload format does not have a static payload type number, but uses a RTP payload type number established dynamically and out-of-band.
現在の慣行に従って、このペイロードフォーマットは、静的なペイロードタイプ番号を有するが、動的に帯域外確立されたRTPペイロードタイプ番号を使用しません。
It is shown in Fig. 3.
なお、図3に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Payload format for tones
図3：トーンのためのペイロード・フォーマット
The payload contains the following fields:
ペイロードには、次のフィールドがあります。
modulation: The modulation frequency, in Hz. The field is a 9-bit unsigned integer, allowing modulation frequencies up to 511 Hz. If there is no modulation, this field has a value of zero.
変調：変調周波数、ヘルツです。フィールドは、511ヘルツまでの変調周波数を可能にする、9ビットの符号なし整数です。何の変調がない場合、このフィールドはゼロの値を持っています。
T: If the "T" bit is set (one), the modulation frequency is to be divided by three. Otherwise, the modulation frequency is taken as is.
Tは：「T」ビットが1に設定されている場合、変調周波数は、3で除算します。そうでない場合には、変調周波数であるとします。
This bit allows frequencies accurate to 1/3 Hz, since
modulation frequencies such as 16 2/3 Hz are in practical
use.
volume: The power level of the tone, expressed in dBm0 after dropping the sign, with range from 0 to -63 dBm0. (Note: A preferred level range for digital tone generators is -8 dBm0 to -3 dBm0.)
体積：トーンの電力レベルは、dBm0で0から-63の範囲で、符号を落とした後にdBm0でで発現しました。 （注：デジタル音源のための好ましいレベルの範囲は-8〜-3 dBm0でdBm0で）。
duration: The duration of the tone, measured in timestamp units. The tone begins at the instant identified by the RTP timestamp and lasts for the duration value.
所要時間：タイムスタンプ単位で測定されたトーンの期間、。トーンは、RTPタイムスタンプによって特定された瞬間から始まり、期間値の間続きます。
The definition of duration corresponds to that for sample-
based codecs, where the timestamp represents the sampling
point for the first sample.
frequency: The frequencies of the tones to be added, measured in Hz and represented as a 12-bit unsigned integer. The field size is sufficient to represent frequencies up to 4095 Hz, which exceeds the range of telephone systems. A value of zero indicates silence. A single tone can contain any number of frequencies.
周波数：トーンの周波数は、添加Hzで測定され、12ビットの符号なし整数として表現されます。フィールドサイズは、電話システムの範囲を超え4095ヘルツ、までの周波数を表すのに十分です。ゼロの値は、沈黙を示します。シングルトーンは周波数の任意の数を含めることができます。
R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it.
R：このフィールドは、将来の使用のために予約されています。送信側は受信側がそれを無視しなければなりません、それをゼロに設定しなければなりません。
This payload format uses the reliability mechanism described in Section 3.7.
このペイロード形式は、セクション3.7で説明した信頼性メカニズムを使用します。
5 Combining Tones and Named Events
5トーンと名前付きイベントを組み合わせます
The payload formats in Sections 3 and 4 can be combined into a single payload using the method specified in RFC 2198. Fig. 4 shows an example. In that example, the RTP packet combines two "tone" and one "telephone-event" payloads. The payload types are chosen arbitrarily as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the redundancy format has the dynamic payload type 96.
セクション3と4におけるペイロード・フォーマットは、RFC 2198.図1に指定された方法を使用して単一のペイロードに組み合わせることができる。4例を示しています。その例では、RTPパケットは、二つの「トーン」と一つの「電話-イベント」ペイロードを兼ね備えています。ペイロードタイプは8000ヘルツのサンプルレートで、それぞれ、97及び98として任意に選択されています。ここで、冗長形式は、ダイナミックペイロードタイプ96を有します。
The packet represents a snapshot of U.S. ringing tone, 1.5 seconds (12,000 timestamp units) into the second "on" part of the 2.0/4.0 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) into the ring cycle. The 440 + 480 Hz tone of this second cadence started at RTP timestamp 48,000. Four seconds of silence preceded it, but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds (16383 timestamp units) can be represented. Even though the tone sequence is not complete, the sender was able to determine that this is indeed ringback, and thus includes the corresponding named event.
パケットは、2.0 / 4.0秒リズム、すなわち、リングサイクルに7.5秒（60,000タイムスタンプユニット）の総数の一部「の」第二に1.5秒（12,000タイムスタンプユニット）、米国着信音のスナップショットを表します。この第二のリズムの440 + 480 Hzのトーンは、RTPタイムスタンプ48,000で開始しました。沈黙の4秒間は、それに先行するが、RFC 2198のみ14ビットがオフセットしているので、唯一の2.05秒（16383タイムスタンプユニット）で表すことができます。トーンシーケンスが完了していないにもかかわらず、送信者は、これがリングバック確かであり、したがって、対応するというイベントが含まれていることを決定することができました。
6 MIME Registration
6 MIME登録
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: telephone-event
MIMEサブタイプ名：電話-イベント
Required parameters: none.
必須パラメータ：なし。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Combining tones and events in a single RTP packet
図4：単一のRTPパケットにトーンやイベントを組み合わせます
Optional parameters: The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can either be a single integer or two integers separated by a hyphen. No white space is allowed in the argument. The integers designate the event numbers supported by the implementation. All implementations MUST support events 0 through 15, so that the parameter can be omitted if the implementation only supports these events.
オプションのパラメータ：「イベント」パラメータが実装によってサポートされるイベントを示しています。イベントは、一つ以上のコンマで区切られた要素として記載されています。各要素は、単一の整数またはハイフンで区切られた2つの整数とすることができます。いかなるホワイトスペースを引数に許可されていません。整数は、実装によってサポートされているイベント番号を指定します。実装が唯一のこれらのイベントをサポートしている場合、パラメータを省略することができるように、すべての実装は、15を通じてイベント0をサポートしなければなりません。
The "rate" parameter describes the sampling rate, in Hertz.
The number is written as a floating point number or as an
integer. If omitted, the default value is 8000 Hz.
Encoding considerations: This type is only defined for transfer via RTP [1].
符号化の考慮事項：このタイプのみRTPを介して転送するために定義されている[1]。
Security considerations: See the "Security Considerations" (Section 7) section in this document.
セキュリティの考慮事項：この文書で「セキュリティに関する考慮事項」（7節）を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: This document.
公開された仕様：このドキュメント。
Applications which use this media: The telephone-event audio subtype supports the transport of events occurring in telephone systems over the Internet.
このメディアを使用するアプリケーション：電話イベントオーディオサブタイプは、インターネット上で電話システムで発生するイベントの転送をサポートしています。
Additional information:
追加情報：
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: tone
MIMEサブタイプ名：トーン
Required parameters: none
必須パラメータ：なし
Optional parameters: The "rate" parameter describes the sampling rate, in Hertz. The number is written as a floating point number or as an integer. If omitted, the default value is 8000 Hz.
オプションのパラメータ：「率」パラメータはヘルツで、サンプリングレートを記述する。数値は、浮動小数点数として、または整数として書き込まれます。省略した場合、デフォルト値は8000 Hzです。
Encoding considerations: This type is only defined for transfer via RTP [1].
符号化の考慮事項：このタイプのみRTPを介して転送するために定義されている[1]。
Security considerations: See the "Security Considerations" (Section 7) section in this document.
セキュリティの考慮事項：この文書で「セキュリティに関する考慮事項」（7節）を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: This document.
公開された仕様：このドキュメント。
Applications which use this media: The tone audio subtype supports the transport of pure composite tones, for example those commonly used in the current telephone system to signal call progress.
このメディアを使用するアプリケーション：トーン・オーディオ・サブタイプは、一般的に進捗状況を呼び出す知らせるために、現在の電話システムで使用されるもの、たとえば、純粋な複合トーンの輸送をサポートしています。
Additional information:
追加情報：
7 Security Considerations
7つのセキュリティの考慮事項
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification (RFC 1889 [1]), and any appropriate RTP profile (for example RFC 1890 [19]).This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様で議論したセキュリティ問題を受けることである（RFCは1889 [1]）、および任意の適切なRTPプロファイル（例えば、RFC 1890のための[19]）。これが意味ことの機密メディアストリームを暗号化することにより達成されます。このペイロードフォーマットに使用されるデータ圧縮は、エンドツーエンドで適用されるので、二つの操作の間に競合がないので、暗号化は、圧縮後に行ってもよいです。
This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
このペイロードタイプは、潜在的なサービス拒否の脅威を引き起こすために、パケット処理のために受信機側計算の複雑さに重大な不均一性を示しません。
In older networks employing in-band signaling and lacking appropriate tone filters, the tones in Section 3.14 may be used to commit toll fraud.
インバンドシグナリングと適切なトーンフィルタを欠く採用し、古いネットワークでは、3.14節でのトーンは料金詐欺をコミットするために使用することができます。
Additional security considerations are described in RFC 2198 [6].
追加のセキュリティ上の考慮事項は、RFC 2198に記述されている[6]。
8 IANA Considerations
8つのIANAの考慮事項
This document defines two new RTP payload formats, named telephone-event and tone, and associated Internet media (MIME) types, audio/telephone-event and audio/tone.
この文書では、2つの電話イベントとトーンという名前の新しいRTPペイロードフォーマット、および関連するインターネットメディア（MIME）タイプ、オーディオ/電話イベントおよびオーディオ/トーンを定義します。
Within the audio/telephone-event type, additional events MUST be registered with IANA. Registrations are subject to approval by the current chair of the IETF audio/video transport working group, or by an expert designated by the transport area director if the AVT group has closed.
オーディオ/電話・イベント型の中では、追加のイベントは、IANAに登録しなければなりません。登録はIETFオーディオ/ビデオ輸送ワーキンググループの現在の議長によって、またはAVTグループが閉じている場合、トランスポート・エリア・ディレクターで指定された専門家の承認を受けています。
The meaning of new events MUST be documented either as an RFC or an equivalent standards document produced by another standardization body, such as ITU-T.
新しいイベントの意味は、いずれかのRFCや、ITU-Tなどの別の標準化団体によって作ら同等の規格文書として文書化されなければなりません。
9 Acknowledgements
9つの謝辞
The suggestions of the Megaco working group are gratefully acknowledged. Detailed advice and comments were provided by Fred Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins.
Megacoのワーキンググループの提案は深く感謝しています。詳細なアドバイスやコメントはフレッドブルク、スティーブCasner、ファティErdin、ビル・フォスター、マイク・フォックス、グンナー・ヘルストローム、テリー・ライオンズ、スティーブMagnell、バーン・パクソンとコリンパーキンスによって提供されました。
10 Authors' Addresses
10本の著者のアドレス
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Scott Petrack MetaTel 45 Rumford Avenue Waltham, MA 02453 USA
スコット2000 PetrackとMetaTel 45ランフォードアベニューウォルサム、MA 02453 USA
EMail: scott.petrack@metatel.com
メールアドレス：scott.petrack@metatel.com
11 Bibliography
11参考文献
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network," Recommendation V.8, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[3]国際電気通信連合、「公共上のデータ伝送のセッションを開始するための手順は、交換電話網、」勧告V.8、ITU、ジュネーブ、スイス、1998年2月の電気通信標準化部門。
[4] R. Kocen and T. Hatala, "Voice over frame relay implementation agreement", Implementation Agreement FRF.11, Frame Relay Forum, Foster City, California, Jan. 1997.
[4] R. KocenとT. Hatala、「ボイスのフレームリレー上の実装協定」、実装合意書FRF.11、フレームリレーフォーラム、フォスターシティ、カリフォルニア州、1997年1月。
[5] International Telecommunication Union, "Multifrequency push-button signal reception," Recommendation Q.24, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1988.
[5]国際電気通信連合を、「多周波プッシュボタン信号受信、」勧告Q.24、ITU、ジュネーブ、スイス、1988年の電気通信標準化部門。
[6] 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.
[6]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.及びS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月。
[7] Handley M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7]ハンドレーM.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[8] International Telecommunication Union, "Automatic answering equipment and general procedures for automatic calling equipment on the general switched telephone network including procedures for disabling of echo control devices for both manually and automatically established calls," Recommendation V.25, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996.
[8]国際電気通信連合は、「自動応答装置や一般の自動呼び出し機器のための一般的な手順は、両方の手動および自動で確立されたコールのためのエコー制御装置を無効にするための手順を含む交換電話網」勧告V.25の電気通信標準化部門ITU、ジュネーブ、スイス、1996年10月。
[9] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network," Recommendation T.30, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 1996.
[9]国際電気通信連合は、「一般的に、文書ファクシミリ送信のための手順は、交換電話網、」勧告T.30、ITU、ジュネーブ、スイス、1996年7月の電気通信標準化部門。
[10] International Telecommunication Union, "Echo cancellers," Recommendation G.165, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.
[10]国際電気通信連合、「エコーキャンセラー、」勧告G.165、ITU、ジュネーブ、スイス、1993年3月の電気通信標準化部門。
[11] International Telecommunication Union, "A modem operating at data signaling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits," Recommendation V.34, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[11]国際電気通信連合、「データは、一般的に使用するために最大33 600ビット/秒の信号速度で動作するモデムは、電話網および専用のポイントツーポイント2線電話型回路で、」推奨V 0.34、ITUの電気通信標準化部門、ジュネーブ、スイス、1998年2月。
[12] International Telecommunication Union, "Procedures for the identification and selection of common modes of operation between data circuit-terminating equipments (DCEs) and between data terminal equipments (DTEs) over the public switched telephone network and on leased point-to-point telephone-type circuits," Recommendation V.8bis, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998.
[12]国際電気通信連合を、「データ回路終端機器（のDCE）との間、およびデータ端末装置（のDTE）間の動作の共通モードの識別および選択のための手順は、公衆交換電話網および専用のポイントツーポイントで上電話型回路、」勧告V.8bis、ITU、ジュネーブ、スイス、1998年9月の電気通信標準化部門。
[13] International Telecommunication Union, "Application of tones and recorded announcements in telephone services," Recommendation E.182, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1998.
[13]国際電気通信連合、「トーンのアプリケーションおよび電話サービスで記録発表、」勧告E.182、ITU、ジュネーブ、スイス、1998年3月の電気通信標準化部門。
[14] Bellcore, "Functional criteria for digital loop carrier systems," Technical Requirement TR-NWT-000057, Telcordia (formerly Bellcore), Morristown, New Jersey, Jan. 1993.
[14]ベルコア、 "デジタルループキャリアシステムのための機能的基準、" 技術要件TR-NWT-000057、のTelcordia（以前のベルコア）、モリスタウン、ニュージャージー州、1993年1月。
[15] J. G. van Bosse, Signaling in Telecommunications Networks Telecommunications and Signal Processing, New York, New York: Wiley, 1998.
[15] J. G.バンボッセ、通信ネットワーク通信や信号処理、ニューヨーク、ニューヨークでシグナリング：ワイリー、1998。
[16] International Telecommunication Union, "AAL type 2 service specific convergence sublayer for trunking," Recommendation I.366.2, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1999.
[16]国際電気通信連合、「トランキングのためのAALタイプ2サービス特定収束サブレイヤ、」勧告I.366.2、ITU、ジュネーブ、スイス、1999年2月の電気通信標準化部門。
[17] International Telecommunication Union, "Various tones used in national networks," Recommendation Supplement 2 to Recommendation E.180, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
[17]国際電気通信連合、「国家のネットワークで使用される様々なトーン、」勧告E.180、ITU、ジュネーブ、スイス、1994年1月の電気通信標準化部門への勧告補足2。
[18] International Telecommunication Union, "Technical characteristics of tones for telephone service," Recommendation Supplement 2 to Recommendation E.180, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
[18]国際電気通信連合、「電話サービスのためのトーンの技術的特性、」勧告E.180、ITU、ジュネーブ、スイス、1994年1月の電気通信標準化部門への勧告補足2。
[19] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[19] Schulzrinneと、H.、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 1890、1996年1月。
12 Full Copyright Statement
12完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。