[要約] RFC 2833は、DTMFダイヤル、電話音、電話信号のためのRTPペイロードを定義しています。このRFCの目的は、リアルタイム通信プロトコル（RTP）を使用して、音声通信セッションでDTMFダイヤルや電話音を伝送するための標準化を提供することです。
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.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
このメモでは、RTPパケットでデュアルトーンマルチフェアエクセンション（DTMF）シグナル、その他のトーン信号、テレフォニーイベントを運ぶ方法について説明します。
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.
このメモは、2つのペイロード形式を定義します。1つは、デュアルトーンの多requency（DTMF）数字、その他のラインとトランクシグナル（セクション3）、およびRTP [1]パケットの一般的な多周波トーンの2番目のペイロード形式（セクション3）（セクション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つのアプリケーションで役立つ場合があります：ゲートウェイとエンドシステムのDTMF処理、および「RTPトランク」。最初のアプリケーションでは、インターネットテレフォニーゲートウェイは、着信回路のDTMFを検出し、通常のオーディオパケットではなくここで説明するRTPペイロードを送信します。ゲートウェイには、2段階のダイヤルの場合、DTMFを検出する必要があることが多いため、必要なデジタル信号プロセッサとアルゴリズムがある可能性があります。ゲートウェイの検出トーンを使用すると、受信インターネットエンドシステムがこの作業を行わなければならないことを軽減し、G.723.1のような低いレートコーデックを回避することも避けます。第二に、「インターネット電話」などのインターネットエンドシステムは、正確なトーンペアを生成することを懸念せずに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トーンの位相反転などのトーン特性は、音声コーディングに耐えられません。したがって、ゲートウェイは、ビットストリームから帯域内の信号情報を削除する必要があります。これで、まだ定義されていないシグナル伝達輸送メカニズムで帯域外に携帯するか、この覚書に記載されているメカニズムを使用できます。（2つのトランクエンドポイントが同じメディアゲートウェイコントローラーの範囲内にある場合、メディアゲートウェイコントローラーもシグナリングを処理できます。）バンド内の搭載により、オーディオパケットとトーンまたは信号情報間の時間同期が簡素化される場合があります。これは、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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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つのトーンがあります。ANSAMトーン[3]は、定期的な位相反転を使用する音声ライン上のデータ伝送を示すために使用されます。）
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.
2番目のオプションとして、ゲートウェイはトーンを認識し、リンギングやビジートーンなどの名前に変換できます。その後、受信機は、信号に適したトーン信号またはその他の表示を生成します。
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セットアップメッセージを送信する場合があります。端末が党の数字と呼ばれることなくセットアップメッセージを送信するだけの場合、スイッチは端子によってキーパッドメッセージとして提供され、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.
リンギングトーン（リングバックトーンとも呼ばれます）は、Calleeのローカルスイッチによって生成され、Calleeの電話が鳴るとすぐに一方向の音声パスが開きます。（これにより、回答の直後に呼び出された党の応答を切り取る可能性が低くなります。また、リンギングトーンの前または代わりに発信者に到達する前の発表またはバンドのコールプログレスの適応症を許可します。）混雑のトーンと特別な情報トーン途中のスイッチのいずれかによって生成でき、受信した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で定義された冗長機構を使用して、名前付き信号（セクション3）とトーン表現（セクション4）の両方を単一のRTPセッションとして送信する場合があります。レシーバーが適切なレンダリングを選択できるようにするため、両方を送信することをお勧めします。
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 Hzですが、動的なペイロードタイプを割り当てるときにクロック周波数を再定義できます。
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.
エンドシステムがインターネットに直接接続されており、再度トーン信号を生成する必要がない場合、時間のアライメントとパワーレベルは関連しません。これらのシステムは、PSTNゲートウェイまたはインターネットエンドシステムに依存してDTMFイベントを生成し、独自のオーディオ波形分析を実行しません。このようなシステムの例は、インターネットインタラクティブな音声応答（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例など、データがUnicastが送信される状況では、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;
o 国固有のサブスクライバーライントーン（セクション3.13）および;
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.10および3.12で説明されているイベントをサポートする必要がありますが、トランクシグナリングを受け取るシステムをセクション3.10、3.11、3.12、および3.14に実装する必要があります。「信号。FAXまたはモデムの機能をサポートしないシステムは、セクション3.11で説明されているFAX関連のイベントをレンダリングする必要はありません。
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.
タイムスタンプ：RTPタイムスタンプは、現在のパケットの測定ポイントを反映しています。セクション3.5で説明されているイベント期間は、その時点から前進します。受信機は、特定のタイムスタンプを持つすべてのパケットに基づいて、RTCPレシーバーレポートのジッターを計算します。注：ジッター値は、主に、絶対的な尺度としてではなく、2人または2人の時間期間間の受信品質を比較するための手段として使用する必要があります。
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.10から3.14に示すように、イベントはエンコードされています。
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〜 -63 dBM0です。有効な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.
8000 Hzのサンプリングレートの場合、このフィールドは、最大約8秒のイベント期間を表現するのに十分です。
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つを含む、異なるアルゴリズムを使用してトーンを作成する場合があります。最初に、レシーバーは、タイムスタンプが示す場所にあるオーディオプレイアウトバッファーに指定された期間のトーンを配置するだけです。同じトーンを拡張する追加のパケットが受信されると、それに応じてプレイアウトバッファーの波形が拡張されます。（オーディオが混合されている場合、つまり、単にコピーするのではなく、プレイアウトバッファーで合計された場合は注意が必要です。）したがって、パケット間の到着時間よりも長く続くトーンのパケットのパケットが失われ、プレイアウトの遅延が短い場合、トーンのギャップが発生する可能性があります。あるいは、レシーバーはトーンを起動し、「E」ビットセット、次のトーンでパケットを受け取るまで再生できます。これはパケットの損失に対してより堅牢ですが、イベントでの最後のパケットのすべての再送信が失われた場合、トーンを拡張する可能性があります。トーンを拡張する期間を制限することは、トーンが「立ち往生する」ことを避けるために必要です。使用されるアルゴリズムに関係なく、トーンを3つ以上のパケット間登録時間によって拡張しないでください。トーン持続時間のわずかな延長と一時停止の短縮は、一般に無害です。
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.)
オーディオソースは、イベントを認識したらすぐにイベントパケットの送信を開始する必要があります。その後50ミリ秒ごとに、またはこのセッションに使用されるオーディオコーデックのパケット間隔（既知であれば）。（送信者は、タイミング情報がタイムスタンプに含まれているため、正確なイベント間時間を維持するために、イベントパケット間で正確な時間間隔を維持する必要はありません。）
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は、調査対象のすべての管理者が40ミリ秒の最小信号持続時間を使用しており、シグナリング速度（トーンと一時停止）が93ミリ秒以上を使用していることを示しています。
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]に記載されているオーディオ冗長機構は、イベント間のパケット損失から回復するために使用できます。効果的なデータレートは、50ミリ秒またはr時間1280ビット/秒ごとに、r時間64ビット（冗長ヘッダーの場合は32ビット、電話 - イベントペイロードで32ビット）です。ここで、各パケットで課される冗長イベントの数です。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.
この冗長性スキームのタイムスタンプのオフセットには14ビットがあるため、1つのパケットが8000 Hzのサンプリングレートで2.048秒の電話イベントを「カバー」できます。以前のイベントの開始時間を含めることで、ゲートウェイでトーンシーケンスを正確に再構築できます。このスキームは、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で開始され、2桁目は250ミリ秒（2000タイムスタンプユニット）に続き、時間800ミリ秒（6400タイムスタンプユニット）で開始され、3番目の数字は1.4秒で押されました。（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>
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進数またはハイフン（DASH）で区切られた2つの小数数字のいずれかで、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
A = 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.
すべての実装はイベント0〜15を受信できる必要があるため、これらのイベントをa = fmtp行にリストすることはオプションです。
The corresponding MIME parameter is "events", so that the following sample media type definition corresponds to the SDP example above:
対応するMIMEパラメーターは「イベント」であるため、次のサンプルメディアタイプ定義は上記のSDP例に対応しています。
audio/telephone-event;events="0-11,66,67";rate="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：これはANSと同じ信号ですが、450 /-25 msの間隔で位相を逆転させることを除きます。エコーキャンセラーとエコーサプレッサーの両方を無効にします。（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]は、15 /-0.1 Hzの正弦波により振幅変調された、相反転なしで2100 /-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]は、2100 /-1 Hzの正弦波信号であり、15 /-0.1 Hzの正弦波により振幅変調された450 /-25 msの間隔で位相反転があります。。このトーン[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 Hzの中断されたトーンで構成される通話トーン（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 Hzと2002 Hzのトーンを400ミリ秒間トーンで備えたデュアルトーン信号であり、その後、1900 Hzで100ミリ秒間単一トーンが続きます。「この信号は、テレフォニーモードから情報転送モードへのリモートステーションの移行を要求し、リモートステーションによる機能リストメッセージの送信をリクエストします。特に、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に対する応答トーンです（上記参照）。これは、1529 Hzと2225 Hzのトーンを400ミリ秒のトーンを備えたデュアルトーン信号で構成され、その後、1900 Hzで100ミリ秒間単一のトーンが続きます。
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]は、1375 Hzのトーンでトーン、2002 Hzで400ミリ秒のトーンでトーンを備えたデュアルトーン信号であり、その後400 Hzで100ミリ秒間単一トーンが続きます。「この信号は、テレフォニーモードから情報転送モードへのリモートステーションの移行を要求し、リモートステーションによる機能リストメッセージの送信を要求します。特に、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信号または1300 Hzの一連の中断されたバーストで構成されています。S、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：Escase Signal（ESI）[12]は、1375 Hzと2002 Hzで400ミリ秒のトーンを備えたデュアルトーン信号であり、その後980 Hzで100ミリ秒間単一のトーンが続きます。「この信号は、テレフォニーモードから情報転送モードへのリモートステーションの移行を要求します。信号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：Escape Signal（ESR）[12]は、1529 Hz、2225 Hzで400ミリ秒のトーンを備えたデュアルトーン信号で、その後1650 Hzで100 msで単一のトーンが続きます。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 Hzおよび2002 Hzのトーンを400ミリ秒間トーンとともにトーンを備えたデュアルトーン信号であり、その後、1150 Hzで100ミリ秒でシングルトーンが続きます。「この信号は、テレフォニーモードから情報転送モードへのリモートステーションの移行を要求し、リモートステーションによるモード選択メッセージの送信を要求します。特に、信号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への応答トーンです（上記参照）。これは、1529 Hzと2225 Hzのトーンを400ミリ秒のトーンを備えたデュアルトーン信号で構成され、その後1150 Hzで100ミリ秒間単一のトーンが続きます。
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 Hzと2002 Hzで400ミリ秒のトーンを備えたデュアルトーン信号で、その後650 Hzで100ミリ秒間単一トーンが続きます。「この信号は、テレフォニーモードから情報転送モードへのリモートステーションの移行を要求し、リモートステーションによるモード選択メッセージの送信をリクエストします。特に、信号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の全二重モデムについて説明しています。グループ3ファックスマシンでT.30情報を交換するために使用されます。呼び出しはチャンネル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：データとFAXという名前のイベント
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.
ダイヤルトーン：Exchangeはアドレス情報を受信する準備ができています。
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").
特別なダイヤルトーン：ダイヤルトーンと同じですが、発信者のラインは、通話転換やボイスメールなどの特定の条件の対象となります（たとえば、「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.
コーリングカードサービストーン：コーリングカードサービスのトーンは、941 Hzと1477 Hzトーン（DTMF '＃'）の合計60ミリ秒で構成され、その後940ミリ秒の350 Hzおよび440 Hz（米国のダイヤルトーン）が続き、指数関数的に減衰します。 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アラート信号は、2130と2750 Hzの合計トーンであり、どちらも0.5％と80の持続時間があります。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]。
ABCD transitional: 4-bit signaling used by digital trunks. For N-state signaling, the first N values are used.
ABCD Transitional：デジタルトランクが使用する4ビットシグナル伝達。N-Stateシグナル伝達の場合、最初の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、およびDと名付けられています。SFT1フレーミングを使用すると、フレーム6、12、18、および24の盗まれたビットとして送信されます。D4スーパーフレームは、AおよびBビットを使用して4状態のシグナルを送信します。CEPT E1フレームでは、すべてのシグナル伝達がTimeslot 16で運ばれ、16状態（ABCD）シグナルの2つのチャネルがフレームごとに送信されます。
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 Recで指定されているものと同様に、次のトリプル冗長機構を使用する必要があります。i.366.2 [16]、付録L.移行時に、同じABCD情報が5 msの間隔で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.
Wink：通常、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.
Unsize Circuit：コールの終了時に、オフフックからオンフックへの回路の遷移。
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ミリ秒、オフフック（押収）からオンフック（未解除）、オフフック（押収）までの短い移行。オペレーターサービストランクで使用されます。
Continuity tone send: A tone of 2010 Hz.
連続トーン送信：2010 Hzのトーン。
Continuity tone detect: A tone of 2010 Hz.
連続トーン検出：2010 Hzのトーン。
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 Hzのトーンが通話交換によって送信されます。呼び出された交換で受け取った場合、「連続検証済み」トーンを返します。
Continuity verified: A tone of 2010 Hz. This is a response tone, used in dual-tone procedures.
連続性検証：2010 Hzのトーン。これは、デュアルトーン手順で使用される応答トーンです。
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つのトーンの変調で構成されています。（ほとんどすべてのトーンは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 テレフォニーイベントのトーンは、25（アンゴラのリンギングトーン）から1800 Hzの範囲です。CEDは、2100 Hzで最も使用されているトーンです。電話の周波数範囲は3,400 Hzに制限されています。（ピアノの範囲は27.5〜4186 Hzです。）
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 変調頻度は、15（ANSAMトーン）から480 Hz（ジャマイカ）の範囲です。非整数周波数は、16 2/3および33 1/3 Hzの周波数にのみ使用されます。（これらの分数周波数は、古い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またはセクション3.11（v.21の場合）で説明されています。
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.
タイムスタンプ：RTPタイムスタンプは、現在のパケットの測定ポイントを反映しています。セクション3.5で説明されているイベント期間は、その時点から前進します。
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 Hzですが、他のレートが定義される場合があります。タイムスタンプのレートは、頻度の解釈に影響を与えないことに注意してください。
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.
変調：Hzの変調周波数。フィールドは9ビットの署名されていない整数であり、最大511 Hzまでの変調周波数が可能になります。変調がない場合、このフィールドにはゼロの値があります。
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.
16 2/3 Hzなどの変調周波数が実際に使用されているため、このビットは1/3 Hzまで正確になることができます。
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 dBM0〜 -3 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 Hzまでの周波数を表すのに十分であり、これは電話システムの範囲を超えています。ゼロの値は沈黙を示します。単一のトーンには、任意の数の周波数を含めることができます。
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で指定されたメソッドを使用して単一のペイロードに結合できます。図4は例を示しています。その例では、RTPパケットは、2つの「トーン」と1つの「電話のイベント」ペイロードを組み合わせています。ペイロードタイプは、それぞれ97と98として任意に選択され、サンプルレートは8000 Hzです。ここで、冗長性形式には動的なペイロードタイプ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秒のケイデンスの一部である2番目の「タイムスタンプユニット）の1.5秒（12,000タイムスタンプユニット）のスナップショットを表しています。この2番目のケイデンスの440 480 Hzトーンは、RTPタイムスタンプ48,000で始まりました。4秒の沈黙が先行しましたが、RFC 2198には4ビットオフセットしかないため、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.
オプションのパラメーター：「イベント」パラメーターには、実装によってサポートされているイベントがリストされています。イベントは、1つ以上のコンマ区切り要素としてリストされています。各要素は、ハイフンで区切られた単一の整数または2つの整数のいずれかです。議論には空白は許可されていません。整数は、実装によってサポートされているイベント番号を指定します。すべての実装は、イベント0から15をサポートする必要があるため、実装がこれらのイベントのみをサポートする場合はパラメーターを省略できます。
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.
「レート」パラメーターは、Hertzのサンプリングレートを記述します。数値は、浮動小数点数または整数として記述されています。省略すると、デフォルト値は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:
追加情報：
1. Magic number(s): N/A
1. マジック番号：n/a
2. File extension(s): N/A
2. ファイル拡張子：n/a
3. Macintosh file type code: N/A
3. Macintoshファイルタイプコード：n/a
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.
オプションのパラメーター：「レート」パラメーターは、Hertzのサンプリングレートを記述します。数値は、浮動小数点数または整数として記述されています。省略すると、デフォルト値は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:
追加情報：
1. Magic number(s): N/A
1. マジック番号：n/a
2. File extension(s): N/A
2. ファイル拡張子：n/a
3. Macintosh file type code: N/A
3. Macintoshファイルタイプコード：n/a
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]）で説明されているセキュリティ考慮事項の対象となります。メディアストリームは暗号化によって達成されます。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮後に暗号化が実行される可能性があるため、2つの操作間に競合がありません。
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.
メガコワーキンググループの提案は感謝されています。詳細なアドバイスとコメントは、フレッドバーグ、スティーブキャスナー、ファティフエルディン、ビルフォスター、マイクフォックス、グンナーヘルストロム、テリーライオンズ、スティーブマグネル、ヴァーンパクソン、コリンパーキンスによって提供されました。
10 Authors' Addresses
10著者の住所
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピューターサイエンスコロンビア大学のヘニングシュルツリン部1214アムステルダムアベニューニューヨーク、ニューヨーク10027 USA
EMail: schulzrinne@cs.columbia.edu
Scott Petrack MetaTel 45 Rumford Avenue Waltham, MA 02453 USA
スコットペトラックメタテル45ラムフォードアベニューウォルサム、マサチューセッツ州02453 USA
EMail: 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.、Frederick、R。and 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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、1998年2月、スイス、ジュネーブのITUの電気通信標準化部門。
[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、「Voice Over Relay実装契約」、実装契約Frf.11、Frame Relay Forum、Foster City、California、1997年1月。
[5] International Telecommunication Union, "Multifrequency push-button signal reception," Recommendation Q.24, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1988.
[5] 1988年、スイス、ジュネーブの電気通信標準化セクター、1988年、「多面的なプッシュボタン信号受信」、推奨事項Q.24、推奨Q.24、国際電気通信ユニオン。
[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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。and S. Fosse-Parisis、 "RTPペイロード冗長なオーディオデータのペイロード"、RFC 2198、1997年9月。
[7] Handley M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley M. and 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] 1996年7月、スイス、ジュネーブのITUの電気通信標準化部門、推奨T.30、推奨T.30、「一般的な切り替え網にある文書ファクシミリ送信の手順」。
[10] International Telecommunication Union, "Echo cancellers," Recommendation G.165, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.
[10] 国際電気通信ユニオン、「エコーキャンセラー」、推奨G.165、1993年3月、スイス、ジュネーブのITUの電気通信標準化セクター。
[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] International Telecommunication Union、「一般的な切り替えの電話ネットワークで使用するための最大33 600ビット/sのデータシグナリングレートで動作するモデムA式およびリースされたポイントツーポイント2線電話タイプの回路」、推奨v.34、1998年2月、スイス、ジュネーブ、ITUの電気通信標準化セクター。
[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）間の一般的なスイッチ式電話ネットワーク上およびリースされたポイントツーポイント電話タイプの間の一般的な動作モードの識別と選択の手順Circuits、「推奨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、1998年3月、スイス、ジュネーブのITUの電気通信標準化セクター。
[14] Bellcore, "Functional criteria for digital loop carrier systems," Technical Requirement TR-NWT-000057, Telcordia (formerly Bellcore), Morristown, New Jersey, Jan. 1993.
[14] Bellcore、「デジタルループキャリアシステムの機能基準」、技術的要件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. Van Bosse、Telecommunications Networksのシグナル伝達通信および信号処理、ニューヨーク、ニューヨーク：Wiley、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] 国際電気通信ユニオン、「TrunkingのためのAALタイプ2サービス固有のコンバージェンスサブレイヤー」、推奨I.366.2、1999年2月、スイス、ジュネーブのITUの電気通信標準化セクター。
[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] 国際電気通信連合、「国家ネットワークで使用されるさまざまなトーン」、推奨サプリメント2の推奨e.180、1994年1月、スイス、ジュネーブのITUの電気通信標準化セクター。
[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] 国際電気通信連合、「電話サービスのためのトーンの技術的特性」、推奨サプリメント2の推奨事項E.180、1994年1月、スイス、ジュネーブのITUの電気通信標準化セクター。
[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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。