[要約] RFC 4734は、モデム、ファックス、テキスト電話信号のイベントの定義に関する規格です。このRFCの目的は、これらの信号のイベントを一貫した方法で定義し、通信プロトコルの開発や実装に役立つことです。
Network Working Group H. Schulzrinne
Request for Comments: 4734 Columbia U.
Obsoletes: 2833 T. Taylor
Updates: 4733 Nortel
Category: Standards Track December 2006
Definition of Events for Modem, Fax, and Text Telephony Signals
モデム、ファックス、テキストテレフォニーシグナルのイベントの定義
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 IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833.
このメモは、RFC 4733を更新して、テレフォニーイベントRTPペイロードで運ばれたときにモデム、FAX、およびテキストテレフォニー信号のイベントコードを追加します。RFC 2833のこの目的のためのイベントコードの割り当てに取って代わるため、RFC 2833の一部が廃止されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Overview ...................................................3
2. Definitions of Events for Control of Data, Fax, and Text
Telephony Sessions ..............................................5
2.1. V.8 bis Events .............................................5
2.1.1. Handling of Congestion ..............................9
2.2. V.21 Events ...............................................10
2.2.1. Handling of Congestion .............................11
2.3. V.8 Events ................................................12
2.3.1. Handling of Congestion .............................15
2.4. V.25 Events ...............................................15
2.4.1. Handling of Congestion .............................17
2.5. V.32/V.32bis Events .......................................18
2.5.1. Handling of Congestion .............................19
2.6. T.30 Events ...............................................19
2.6.1. Handling of Congestion .............................23
2.7. Events for Text Telephony .................................23
2.7.1. Signal Format Indicators for Text Telephony ........23
2.7.2. Use of Events with V.18 Modems .....................27
2.8. A Generic Indicator .......................................28
3. Strategies for Handling Fax and Modem Signals ..................29
4. Example of V.8 Negotiation .....................................30
4.1. Simultaneous Transmission of Events and
Retransmitted Events Using RFC 2198 Redundancy ............35
4.2. Simultaneous Transmission of Events and Voice-Band
Data Using RFC 2198 Redundancy ............................37
5. Security Considerations ........................................39
6. IANA Considerations ............................................40
7. Acknowledgements ...............................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................44
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 [1].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [1]に記載されているように解釈されるべきです。
In addition to those defined for specific events, this document uses the following abbreviations:
特定のイベントで定義されたものに加えて、このドキュメントでは、次の略語を使用します。
Fax facsimile
ファックスファクシミリ
HDLC High-level Data Link Control
HDLC高レベルのデータリンク制御
PSTN Public Switched (circuit) Telephone Network
PSTN Public Switched（Circuit）電話ネットワーク
This document extends the set of telephony events defined within the framework of RFC 4733 [5] to include the control events and tones that can appear on a subscriber line serving a fax machine, a modem, or a text telephony device. The events are organized into several groups, corresponding to the ITU-T Recommendation in which they are defined. Their purpose is to support negotiation, start-up and takedown of fax, modem, or text telephony sessions and transitions between operating modes. The actual fax, modem, and text payload is typically carried by other payload types (e.g., V.150.1 [32] modem relay, voice-band data as formalized in ITU-T Rec. V.152 [33], Clearmode [17] for digital data, T.38 [21] for fax, or RFC 4103 [18] for character-mode text).
このドキュメントは、RFC 4733 [5]のフレームワーク内で定義されたテレフォニーイベントのセットを拡張して、ファックスマシン、モデム、またはテキストテレフォニーデバイスを提供するサブスクライバーラインに表示できるコントロールイベントとトーンを含めます。イベントは、それらが定義されているITU-Tの推奨に対応するいくつかのグループに編成されます。彼らの目的は、FAX、モデム、またはテキストテレフォニーセッションとオペレーティングモード間の移行の交渉、スタートアップ、テイクダウンをサポートすることです。実際のファックス、モデム、およびテキストペイロードは、通常、他のペイロードタイプによって運ばれます（例：v.150.1 [32]モデムリレー、V.152 [33]、ClearMode [17]デジタルデータの場合、FAXのT.38 [21]、またはキャラクターモードテキストのRFC 4103 [18]）。
NOTE: implementers SHOULD NOT rely on the descriptions of the various modem protocols described below without consulting the original references (generally ITU-T Recommendations). The descriptions are provided in this document to give a context for the use of the events defined here. They frequently omit important details needed for implementation.
注：実装者は、元の参照を参照せずに以下で説明するさまざまなモデムプロトコルの説明に依存してはなりません（一般的にITU-Tの推奨事項）。このドキュメントで説明は、ここで定義されているイベントを使用するためのコンテキストを提供するために提供されています。彼らは頻繁に実装に必要な重要な詳細を省略します。
The typical application of these events is to allow the Internet to serve as a bridge between terminals operating on the PSTN. This application is characterized as follows:
これらのイベントの典型的なアプリケーションは、インターネットがPSTNで動作する端子間のブリッジとして機能するようにすることです。このアプリケーションは次のように特徴付けられます。
o each gateway will act both as sender and as receiver;
o 各ゲートウェイは、送信者と受信者の両方として機能します。
o time constraints apply to the exchange of signals, making the early identification and reporting of events desirable so that receiver playout can proceed in a timely fashion;
o 時間の制約は、信号の交換に適用され、受信者のプレイアウトがタイムリーに進行できるように、イベントの早期識別とレポートを望ましいものにします。
o the receiver must play out events in their proper order;
o 受信者は、適切な順序でイベントをプレイする必要があります。
o transfer of the events must be reliable. Applications will vary in their ability to recover from missing events.
o イベントの転送は信頼できる必要があります。アプリケーションは、欠落しているイベントから回復する能力が異なります。
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 2.4.1 of RFC 4733 [5] specifies how an implementation can use the Session Description Protocol (SDP) "fmtp" parameter within an SDP description [4] to indicate which events it is prepared to handle.
場合によっては、実装は、特定の環境では意味をなさないファックストーンなどの特定のイベントを単に無視する場合があります。RFC 4733 [5]のセクション2.4.1は、実装がSDP説明[4]内でセッション説明プロトコル（SDP）「FMTP」パラメーターを使用して、どのイベントを処理するかを示す方法を指定します。
Regardless of which events they support, implementations MUST be prepared to send and receive data signals using payload types other than telephone-event, simultaneously with the use of the latter. This is discussed further in Section 3.
サポートするイベントに関係なく、実装は、後者の使用と同時に、電話 - イベント以外のペイロードタイプを使用してデータ信号を送信および受信するために準備する必要があります。これについては、セクション3でさらに説明します。
In many cases, continuity of playout is critical. In principle, this is achieved through buffering at the receiving end. It is generally desirable to minimize such buffering to reduce round-trip response times. Maintenance of a constant packetization interval at the sending end while reporting events is helpful for this purpose.
多くの場合、プレイアウトの継続性が重要です。原則として、これは受信側でのバッファリングによって達成されます。一般に、このようなバッファリングを最小限に抑えて、往復応答時間を短縮することが望ましいです。この目的のために、レポートイベント中の送信端での一定のパケット化間隔のメンテナンスが役立ちます。
A further word on time constraints is in order. Time constraints governing the duration of tones do not pose a problem when using the telephone-event payload type: the payload specifies the duration and the receiving gateway can play out the tones accordingly. Problems occur when time constraints are specified for the duration of silence between tones. A silent period of "at least x ms" is not a problem -- event notifications can be received late, but they can still be played out at their specified durations.
時間の制約に関するさらなる単語が適切です。トーンの持続時間を管理する時間の制約は、電話のイベントペイロードタイプを使用する場合、問題を引き起こしません。ペイロードは期間を指定し、受信ゲートウェイはそれに応じてトーンを再生できます。問題は、トーン間の沈黙の期間中に時間の制約が指定されている場合に発生します。「少なくともx ms」の静かな期間は問題ではありません。イベント通知は遅れて受信できますが、指定された期間で再生できます。
The problem occurs if silence must last for a specific duration or at most some specific period. The most general constraint of the latter type has to do with the operation of echo suppressors (ITU-T Rec. G.164 [6]) and echo cancellers (ITU-T Rec. G.165 [7]). These devices may re-activate after as little as 100 ms of no signal on the line. As a result, in any situation where echo suppressors or cancellers must be disabled for signalling to work, tone events must be reported quickly enough to ensure that these devices do not become re-enabled.
問題は、特定の期間、または最大の特定の期間にわたって沈黙が続く必要がある場合に発生します。後者のタイプの最も一般的な制約は、エコーサプレッサー（ITU-TRec。G.164[6]）およびエコーキャンセラー（ITU-TRec。G.165[7]）の操作に関係しています。これらのデバイスは、ライン上のわずか100ミリ秒の信号なしで再起動する場合があります。その結果、エコーサプレッサーまたはキャンセラーを無効にする必要がある状況では、シグナリングを機能させるために、これらのデバイスが再有効にならないようにトーンイベントを十分に迅速に報告する必要があります。
Recommendation V.8 bis [10] is a general procedure for two endpoints to establish each other's capabilities and to transition between different operating modes, both at call startup and after the call has been established. It supports many of the same terminals as V.8 [9] (Section 2.3 below), but allows more detailed parameter negotiation. It lacks support for some of the older V-series modems defined in V.8, but adds capabilities for simultaneous or alternating voice and data, H.324 [20] multilink, and T.120 [23] conferencing.
推奨V.8 BIS [10]は、2つのエンドポイントが互いの機能を確立し、コールの起動時と通話が確立された後の両方で、異なるオペレーティングモード間を移行するための一般的な手順です。v.8 [9]（以下のセクション2.3）と同じ端子の多くをサポートしますが、より詳細なパラメーターネゴシエーションが可能になります。V.8で定義されている古いVシリーズモデムのサポートはありませんが、同時または交互の音声とデータ、H.324 [20] Multilink、およびT.120 [23]会議の機能を追加します。
Following V.8 bis capability negotiations, if the terminals have negotiated a modem-based operating mode, they initiate the actual modem session using either V.8, a truncated version of V.8 (preferred), or V.25 start-up. V.25 is described in Section 2.4.
V.8 BIS機能の交渉に続いて、端子がモデムベースの動作モードをネゴシエートした場合、V.8（優先）の切り捨てられたバージョン、またはV.25の起動のいずれかを使用して実際のモデムセッションを開始します。。V.25はセクション2.4で説明されています。
V.8 bis distinguishes between "signals" and "messages". The V.8 bis signals -- ESi/ESr, MRe/MRd, and CRe/CRd -- consist of tones, as described in the next few paragraphs. The V.8 bis messages -- MS, CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4) -- consist of sequences of bits transported over V.21 [12] modulation.
v.8ビスは、「信号」と「メッセージ」を区別します。V.8 BISシグナル - ESI/ESR、MRE/MRD、およびCRE/CRD-は、次のいくつかの段落で説明されているように、トーンで構成されています。V.8 BISメッセージ - MS、CL、CLR、ACK（1）、ACK（2）、Nak（1）、Nak（2）、Nack（3）、およびNack（4） - のシーケンスで構成されていますv.21 [12]変調で輸送されたビット。
Signals are intended to be comprehensible at the receiver even in the presence of voice content. They consist of two tone segments. The first segment consists of a dual-frequency tone held for 400 ms, and has the function of preparing the receiver and any in-line echo suppressor or canceller for what follows. The specific frequencies depend only on whether the signal is from the initiator or the responder in a transaction. When using the telephone-event payload, the V8bISeg and V8bRSeg events in Table 1 represent the first segment of any V.8 bis signal in the initiating and responding case, respectively.
信号は、音声コンテンツが存在する場合でも、受信機で理解できることを目的としています。それらは2つのトーンセグメントで構成されています。最初のセグメントは、400ミリ秒間保持されている二重周波数トーンで構成されており、レシーバーとインラインエコーサプレッサーまたはキャンセラーを次のように準備する機能があります。特定の周波数は、信号がトランザクションのイニシエーターまたはレスポンダーからのものであるかどうかのみに依存します。電話のイベントペイロードを使用する場合、表1のV8BisegおよびV8Brsegイベントは、それぞれ開始および応答の場合のV.8 BIS信号の最初のセグメントを表しています。
The complete V.8 bis strategy for dealing with echo suppressors or cancellers is described in Rec. V.8 bis Appendix III. The only silent period constraints imposed are of the "at least" type, posing no difficulties for the use of the telephone-event payload.
エコーサプレッサーまたはキャンセラーを扱うための完全なV.8 BIS戦略については、Rec。v.8 BIS付録III。課せられる唯一のサイレント期間の制約は、「少なくとも」タイプであり、電話 - イベントペイロードの使用に困難はありません。
The second segment follows immediately after the first, and is a single tone held for 100 ms. The frequency used indicates the specific signal of the six signals defined. When using the telephone-event payload, the second segment of a V.8 bis signal is represented by the applicable event: CRdSeg, CReSeg, MRdSeg, MReSeg, ESiSeg, or ESrSeg, as defined in Table 1. ESiSeg and ESrSeg use the same frequencies as V.21 low and high channel '1' bits, respectively (see Table 2), and are therefore assigned the same event codes.
2番目のセグメントは、最初のセグメントの直後に続き、100ミリ秒間保持されている単一のトーンです。使用される周波数は、定義された6つの信号の特定の信号を示します。電話のイベントペイロードを使用する場合、V.8 BIS信号の2番目のセグメントは、該当するイベントで表されます：CRDSEG、CRSEG、MRDSEG、MRSEG、ESISEG、またはESRSEG、表1に定義されています。v.21低および高チャネル '1'ビットなどの周波数（表2を参照）であるため、同じイベントコードが割り当てられます。
V.8 bis messages use V.21 [12] frequency-shift signalling to transfer message content. V.21 is described in the next section. V.8 bis uses V.21 in half-duplex mode at 300 bits/s, with the lower channel assigned to the initiator and the upper channel to the responder.
V.8 BISメッセージは、V.21 [12] Frequency-Shiftシグナル伝達を使用してメッセージコンテンツを転送します。V.21は次のセクションで説明します。V.8 BISは、300ビット/sのハーフデュアルモードでV.21を使用し、下部チャネルはイニシエーターに割り当てられ、上部チャネルがレスポンダーに割り当てられます。
Each V.8 bis message is preceded by a 100-ms preamble of continuous V.21 marking frequency except if it was immediately preceded by an ESi or ESr signal (the second segment of which is that same V.21 marking frequency). The sender SHALL NOT report this preamble tone using the ESiSeg or ESrSeg events; these are to be used only for the V.8 bis signals to which they pertain.
各V.8 BISメッセージの前には、ESIまたはESR信号の直前の場合を除き、連続V.21マーキング周波数の100 msプリアンブルが先行します（その2番目のセグメントは同じV.21マーキング周波数です）。送信者は、ESISEGまたはESRSEGイベントを使用してこの前文のトーンを報告してはなりません。これらは、それらが関係するV.8 BIS信号にのみ使用されます。
Spelling this out, continuous V.21 marking tone immediately following V8bISeg and V8bRSeg is reported as ESiSeg or ESrSeg, respectively. Continuous V.21 marking tone occurring in any other context, and particularly after CRdSeg, CReSeg, MRdSeg, or MReSeg, is reported by other means such as a different payload type or using the V.21 '1' bit events defined in Section 2.2.
これを綴り、V8bisegとV8brsegの直後に連続するV.21マークトーンは、それぞれESISEGまたはESRSEGとして報告されます。他のコンテキストで発生する連続V.21マーキングトーン、特にCrdseg、Creseg、Mrdseg、またはMresegの後に、別のペイロードタイプなどの他の手段によって報告されているか、セクション2.2で定義されたV.21 '1'ビットイベントを使用して報告されます。。
No events are defined for V.8 bis messages, but a brief description follows.
V.8 BISメッセージのイベントは定義されていませんが、簡単な説明が続きます。
o the V.8 bis CL message describes the sending terminal's capabilities;
o v.8 bis clメッセージは、送信端末の機能を説明しています。
o the CLR message also describes capabilities, but indicates that the sender wants to receive a CL in return;
o CLRメッセージは機能も説明しますが、送信者が見返りにCLを受信したいことを示します。
o the MS establishes a particular operating mode;
o MSは特定の動作モードを確立します。
o the ACK and NAK messages are used to terminate the message transactions.
o ACKおよびNAKメッセージは、メッセージトランザクションを終了するために使用されます。
The V.8 bis messages are organized as a sequence of octets. The first two to five octets are HDLC flags (0x7E). Then comes a message type identifier (four bits), a V.8 bis version identifier (four bits), zero to two more octets of identifying information, followed by zero or more information field parameters in the form of bit maps. An individual bit map is one to five octets in length. Up to 64 octets of non-standard information may also be present. The information fields are followed by a checksum and one to three HDLC flags. Because of limits on the size of any one information field, V.8 bis defines segmentation procedures. Excess data is sent in an additional message, but only after prompting from the receiving end.
V.8 BISメッセージは、オクテットのシーケンスとして編成されています。最初の2〜5オクテットはHDLCフラグ（0x7e）です。次に、メッセージタイプ識別子（4ビット）、v.8 BISバージョン識別子（4ビット）、さらに2オクターの識別情報があり、その後、ビットマップの形でゼロ以上の情報フィールドパラメーターが続きます。個々のビットマップの長さは1〜5オクテットです。非標準情報の最大64オクテットも存在する場合があります。情報フィールドの後にチェックサムと1〜3つのHDLCフラグが続きます。1つの情報フィールドのサイズの制限があるため、v.8 Bisはセグメンテーション手順を定義します。余分なデータは追加のメッセージで送信されますが、受信側からプロンプトを送信した後にのみ送信されます。
Applications supporting V.8 bis signalling using the telephone-event payload MAY transfer V.8 bis messages in the form of sequences of bits, using the V.21 bit events defined in the next section. If they do so, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, and the terminating HDLC flags.
電話とイベントのペイロードを使用したV.8 BISシグナル伝達をサポートするアプリケーションは、次のセクションで定義されているV.21ビットイベントを使用して、ビットのシーケンスの形でV.8 BISメッセージを転送できます。そうすれば、送信された情報には、メッセージの完全な内容、最初のHDLCフラグ、情報フィールド、チェックサム、および終了HDLCフラグを含める必要があります。
Transmission MUST also include the extra '0' bits added according to the procedures of Rec. V.8 bis, clause 7.2.8, to prevent false recognition of HDLC flags at the receiver. Implementers should note that these extra '0' bits mean that in general V.8 bis messages as transmitted on the wire will not come out to an even multiple of octets. Sending implementations MAY choose to vary the packetization interval to include exactly one octet of information plus any extra '0' bits inserted into that octet; the resulting variation will be insignificant compared with the amount of buffering required to guard against network delays in delivery of packets to the receiver (see below).
トランスミッションには、Recの手順に従って追加された追加の「0」ビットも含める必要があります。V.8 BIS、条項7.2.8、レシーバーでのHDLCフラグの誤った認識を防ぐ。実装者は、これらの余分な「0」ビットは、ワイヤーに送信された一般的なv.8ビスメッセージがオクテットの倍数に出てこないことを意味することに注意する必要があります。実装の送信は、パケット化間隔を変更することを選択して、そのオクテットに挿入された情報と余分な「0」ビットを正確に1つ含めることができます。結果として生じる変動は、受信機へのパケットの配信におけるネットワーク遅延を防ぐために必要なバッファリングの量と比較して重要ではありません（以下を参照）。
One reason for reporting the V.21 bits exactly as presented on the wire is to match the corresponding content if it is also carried by other means, such as voice-band data.
ワイヤーで表示されているとまったく同じV.21ビットを報告する理由の1つは、音声帯域データなどの他の手段によっても運ばれる場合、対応するコンテンツと一致することです。
The power levels of the V.8 bis and V.21 signals are subject to national regulation. Thus, it seems suitable to model V.8 bis events as tones for which the volumes SHOULD be specified by the sender. If the receiver is rendering the V.8 bis tones as audio content for onward transmission, the receiver MAY use the volumes contained in the event reports, or MAY modify the volumes to match downstream national requirements.
V.8 BISおよびV.21信号の電力レベルは、国家規制の対象となります。したがって、送信者がボリュームを指定するトーンとしてV.8 BISイベントをモデル化するのに適していると思われます。レシーバーがV.8 BISトーンをオンワード送信のオーディオコンテンツとしてレンダリングしている場合、レシーバーはイベントレポートに含まれるボリュームを使用するか、下流の国家要件に合わせてボリュームを変更する場合があります。
Table 1 summarizes the event codes defined for V.8 bis signalling in this document. The individual events are described following the table. Each event begins when the beginning of the tone segment is detected and ends when the tone is no longer detected.
表1は、このドキュメントのV.8 BISシグナル伝達に対して定義されたイベントコードをまとめたものです。個々のイベントについては、テーブルに従って説明されています。各イベントは、トーンセグメントの開始が検出され、トーンが検出されなくなったときに終了するときに始まります。
+---------+-------------+-----------+------------+------+---------+
| Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? |
+---------+-------------+-----------+------------+------+---------+
| ESiSeg | 980 | 100 | 38 | tone | yes |
| | | | | | |
| ESrSeg | 1650 | 100 | 40 | tone | yes |
| | | | | | |
| CRdSeg | 1900 | 100 | 23 | tone | yes |
| | | | | | |
| CReSeg | 400 | 100 | 24 | tone | yes |
| | | | | | |
| MRdSeg | 1150 | 100 | 25 | tone | yes |
| | | | | | |
| MReSeg | 650 | 100 | 26 | tone | yes |
| | | | | | |
| V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes |
| | | | | | |
| V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes |
+---------+-------------+-----------+------------+------+---------+
Table 1: Events for V.8 bis Signals
表1：V.8 BIS信号のイベント
ESiSeg:
esiseg：
The second segment of a V.8 bis initiating Escape Signal (ESi). The complete ESi signal is represented by events V8bISeg followed by ESiSeg. ESi will be followed by an MS, CL, or CLR message from the same terminal. A 1.5-s silent interval may come between the ESi signal and the transmission of the MS, CL, or CLR message to accommodate network echo suppressors.
a v.8 BIS開始エスケープ信号（ESI）の2番目のセグメント。完全なESI信号は、イベントv8bisegに続いてesisegがそれに続きます。ESIの後に、同じ端末からMS、CL、またはCLRメッセージが続きます。1.5秒のサイレント間隔は、ESI信号とMS、CL、またはCLRメッセージの送信の間に、ネットワークエコーサプレッサーに対応することができます。
ESrSeg:
esrseg：
The second segment of a V.8 bis responding Escape Signal (ESr). The complete ESr signal is represented by events V8bRSeg followed by ESrSeg. ESr is always sent by the calling terminal in response to an MRe or CRe from an automatic answering station. It will be followed by an MS, CL, or CLR message. The ESr signal turns off any announcement being generated by the automatic answering station.
v.8 BIS応答エスケープ信号（ESR）の2番目のセグメント。完全なESR信号は、イベントv8brsegに続いてESRSEGが次に表されます。ESRは、自動回答ステーションからのMREまたはCREに応じて、常に呼び出し端子によって送信されます。その後、MS、CL、またはCLRメッセージが続きます。ESR信号は、自動回答ステーションによって生成される発表をオフにします。
CRdSeg:
crdseg：
The second segment of a V.8 bis Capabilities Request signal (CRd). The first segment of the CRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a capabilities list (CL or CLR message).
V.8 BIS機能要求信号（CRD）の2番目のセグメント。CRD信号の最初のセグメントは、コンテキストに応じて、V8BisegまたはV8Brsegで表されます。もう一方の端は、機能リスト（CLまたはCLRメッセージ）を返します。
CReSeg:
クリーゼ：
The second segment of a V.8 bis Capabilities Request signal (CRe) initiated by an automatic answering terminal. The complete CRe signal is represented by events V8bISeg followed by CReSeg. The calling terminal will respond with a CRd signal or a CL or CLR message.
自動回答端末によって開始されたV.8 BIS機能要求信号（CRE）の2番目のセグメント。完全なCRE信号は、イベントv8bisegに続いてCresegが表されます。呼び出し端子は、CRD信号またはCLまたはCLRメッセージで応答します。
MRdSeg:
Mrdseg：
The second segment of a V.8 bis Mode Request signal (MRd). The first segment of the MRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a CRd signal or an MS message.
V.8 BISモード要求信号（MRD）の2番目のセグメント。MRD信号の最初のセグメントは、コンテキストに応じて、v8bisegまたはv8brsegで表されます。もう一方の端は、CRD信号またはMSメッセージを返します。
MReSeg:
Mreseg：
The second segment of a V.8 bis Mode Request signal (MRe) initiated by an automatic answering terminal. The complete MRe signal is represented by events V8bISeg followed by MReSeg. The calling terminal will respond with an MRd or CRd signal or an MS message.
自動応答端末によって開始されたV.8 BISモード要求信号（MRE）の2番目のセグメント。完全なMRE信号は、イベントv8bisegに続いてMresegがそれに続きます。呼び出し端子は、MRDまたはCRD信号、またはMSメッセージで応答します。
V8bISeg:
v8biseg：
The first segment of an initiating V.8 bis signal, which may be one of ESi, CRd, CRe, MRd, or MRe.
V8bRSeg:
v8brseg：
The first segment of a responding V.8 bis signal, which may be one of ESr, CRd, or MRd.
応答するV.8 BIS信号の最初のセグメントは、ESR、CRD、またはMRDの1つである可能性があります。
V.8 bis implementations are unlikely to tolerate gaps or extensions in playout times due to congestion-caused packet delay. At a minimum, the current transaction is liable to be reset when these defects in playout occur. As a result, careful management of the playout buffer is required at the receiver to increase robustness in the face of possible lost or delayed packets. The playout algorithm should also be such as not to cause event playout to exceed the nominal duration of the event.
V.8 BISの実装は、混雑が原因でパケットの遅延のために、プレイアウト時にギャップや拡張機能を容認する可能性は低いです。少なくとも、プレイアウトのこれらの欠陥が発生した場合、現在のトランザクションはリセットされる義務があります。その結果、紛失または遅延パケットに直面して堅牢性を高めるために、受信機でプレイアウトバッファーの慎重な管理が必要です。また、プレイアウトアルゴリズムは、イベントプレイアウトにイベントの名目期間を超えないようにするなどのものである必要があります。
V.8 bis does not appear to offer opportunities for dynamic adaptation to congestion through manipulation of the packetization interval.
V.21 [12] is a modem protocol offering data transmission at a maximum rate of 300 bits/s. Two channels are defined, supporting full duplex data transmission if required. The low channel uses frequencies 980 Hz for '1' (mark) and 1180 Hz for '0' (space); the high channel uses frequencies 1650 Hz for '1' and 1850 Hz for '0'. The modem can operate synchronously or asynchronously.
v.21 [12]は、最大300ビット/sの最大レートでデータ送信を提供するモデムプロトコルです。2つのチャネルが定義されており、必要に応じて完全な二重データ送信をサポートします。低いチャネルは、「1」（マーク）に980 Hz、「0」（スペース）に1180 Hzの周波数を使用します。高チャネルは、「1」で1650 Hz、「0」には1850 Hzの周波数を使用します。モデムは同期または非同期に動作できます。
V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) for transmission of control data, and is also used in its own right between text terminals. The V.21 events are summarized in Table 2.
V.21は、制御データの送信に他のプロトコル（v.8 Bis、v.18、T.30）で使用され、テキスト端子間で独自の権利でも使用されます。V.21イベントを表2にまとめます。
Sending implementations SHOULD report a completed event for every bit transmitted (i.e., rather than at transitions between '0' and '1'). Bit events are assumed to begin and end with the clock interval for the event, neglecting the rise and fall times between bit transitions. Thus, it is important for a gateway to determine the actual bit rate in use before beginning to report V.21 events.
実装を送信するには、送信されるごとに完了したイベントを報告する必要があります（つまり、「0」と「1」の間の移行ではなく）ではなく）。ビットイベントは、イベントのクロック間隔で開始および終了すると想定されており、ビット移行間の上昇時間と下降時間を無視します。したがって、ゲートウェイがV.21イベントを報告する前に実際のビットレートを決定することが重要です。
Sometimes determination of the bit rate is not immediately possible, as in the case of the 100-ms training signal at V.21 mark frequency used before V.8 bis messages. Transmission of a single longer-duration V.21 event is reasonable under these circumstances and should not cause any difficulties at the receiving end.
V.8 BISメッセージの前に使用されるV.21マーク周波数での100 msトレーニング信号の場合のように、ビットレートの決定がすぐには不可能です。これらの状況下では、単一の長期V.21イベントの送信は合理的であり、受信側で困難を引き起こすことはありません。
Implementations SHOULD pack multiple events into one packet, using the procedures of Section 2.5.1.5 of RFC 4733 [5]. Eight to ten bits is a reasonable packetization interval.
実装は、RFC 4733 [5]のセクション2.5.1.5の手順を使用して、複数のイベントを1つのパケットに梱包する必要があります。8〜10ビットは、合理的なパケット化間隔です。
Reliable transmission of V.21 events is important, to prevent data corruption. Reporting an event per bit rather than per transition increases reporting redundancy and thus reporting reliability, since each event completion is transmitted three times as described in Section 2.5.1.4 of RFC 4733 [5]. To reduce the number of packets required for reporting, implementations SHOULD carry the retransmitted events using RFC 2198 [2] redundancy encoding. This is illustrated in the example in Section 4.1.
データの腐敗を防ぐために、V.21イベントの信頼できる送信が重要です。トランジションごとではなくビットあたりのイベントを報告すると、RFC 4733のセクション2.5.1.4で説明されているように、各イベントの完了が3回送信されるため、報告の冗長性が増加し、信頼性を報告します。レポートに必要なパケットの数を減らすには、実装ではRFC 2198 [2]冗長エンコードを使用して再送信されたイベントを搭載する必要があります。これは、セクション4.1の例に示されています。
The time to transmit one V.21 bit at the nominal rate of 300 bits/s is 3.33 ms, or 26.67 timestamp units at the default 8000-Hz sampling rate for the telephone-event payload type. Because this duration is not an integral number of timestamp units, accurate reporting of the beginning of the event and the event duration is impossible. Sending gateways SHOULD round V.21 event starting times to the nearest whole timestamp unit.
300ビット/sの公称レートで1つのV.21ビットを送信する時間は3.33ミリ秒、または電話 - イベントペイロードタイプのデフォルトの8000Hzサンプリングレートで26.67のタイムスタンプユニットです。この期間はタイムスタンプユニットの不可欠な数ではないため、イベントの開始とイベント期間の正確な報告は不可能です。ゲートウェイを送信するには、V.21イベントの開始時間を最も近いタイムスタンプユニット全体に回します。
When sending multiple consecutive V.21 events in a succession of packets, the sending gateway MUST ensure that individual event durations reported do not cause the last event of one packet to overlap with the first event of the next, taking into account the respective initial event timestamps. To accomplish this, the sending gateway MUST derive the individual event durations as the succession of differences between the event starting times (so that, at 8000 Hz, every third event has reported duration 26 units, the remainder 27 units).
複数の連続したV.21イベントを一連のパケットで送信する場合、送信ゲートウェイは、それぞれのパケットの最後のイベントが次のイベントの最初のイベントとオーバーラップすることを保証する必要があります。タイムスタンプ。これを達成するために、送信ゲートウェイは、イベントの開始時間間の違いの連続として個々のイベント期間を導き出す必要があります（8000 Hzで、3分の1のイベントが期間26ユニット、残り27単位を報告しました）。
Where a receiving gateway recognizes that a packet reports a consecutive series of V.21 bit events, it SHOULD play them out at a uniform rate despite the possible one-timestamp-unit discrepancies in their reported spacing and duration.
受信ゲートウェイが、パケットがV.21ビットイベントの連続したシリーズを報告することを認識している場合、報告された間隔と期間に1つのタンパンプユニットの不一致の可能性にもかかわらず、均一な速度でそれらを再生する必要があります。
+--------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------------------+----------------+------------+------+---------+
| V.21 channel 1, | 1180 | 37 | tone | yes |
| '0' bit | | | | |
| | | | | |
| V.21 channel 1, | 980 | 38 | tone | yes |
| '1' bit | | | | |
| | | | | |
| V.21 channel 2, | 1850 | 39 | tone | yes |
| '0' bit | | | | |
| | | | | |
| V.21 channel 2, | 1650 | 40 | tone | yes |
| '1' bit | | | | |
+--------------------+----------------+------------+------+---------+
Table 2: Events for V.21 Signals
表2：V.21信号のイベント
Implementations that choose to transmit V.21 content using a different payload type may wish to use one of the indicator events defined in Table 7 to alert the receiver to the nature of the content. It is not expected that an implementation will send both one of these indicator events and the V.21 bit events defined above for the same content.
異なるペイロードタイプを使用してV.21コンテンツを送信することを選択する実装は、表7で定義されているインジケータイベントの1つを使用して、コンテンツの性質を受信者に警告することをお勧めします。実装により、これらのインジケータイベントの1つと、同じコンテンツに対して上記のV.21ビットイベントの両方が送信されることは予想されません。
The duration of V.21 bits cannot be extended from its nominal value (which depends on the transmission rate). The playout algorithm at the receiver should take this constraint into account when compensating for the delay or loss of packets due to congestion.
V.21ビットの持続時間は、その名目値から延長することはできません（これは伝送速度に依存します）。受信機のプレイアウトアルゴリズムは、輻輳によるパケットの遅延または損失を補う際に、この制約を考慮に入れる必要があります。
Other congestion-related considerations depend on the specific application for which the V.21 bit events are being used.
他の混雑関連の考慮事項は、V.21ビットイベントが使用されている特定のアプリケーションに依存します。
V.8 [9] is an older general negotiation and control protocol, supporting startup for the following terminals: H.324 [20] multimedia, V.18 [11] text, T.101 [22] videotext, T.30 [8] send or receive fax, and a long list of V-series modems including V.34 [28], V.90 [29], V.91 [30], and V.92 [31]. In contrast to V.8 bis [10], in V.8 only the calling terminal can determine the operating mode.
v.8 [9]は古い一般的な交渉と制御プロトコルであり、次の端子のスタートアップをサポートしています。H.324[20] Multimedia、V.18 [11] Text、T.101 [22] VideoText、T.30 [8] v.34 [28]、v.90 [29]、v.91 [30]、v.92 [31]を含むVシリーズモデムの長いリストを送信または受け取ります。V.8 BIS [10]とは対照的に、V.8では、呼び出し端子のみが動作モードを決定できます。
V.8 does not use the same terminology as V.8 bis. Rather, it defines four signals that consist of bits transferred by V.21 [12] at 300 bits/s: the call indicator signal (CI), the call menu signal (CM), the CM terminator (CJ), and the joint menu signal (JM). In addition, it uses tones defined in V.25 [13] and T.30 [8] (described below), and one tone (ANSam) defined in V.8 itself. The calling terminal sends using the V.21 low channel; the answering terminal uses the high channel.
v.8は、v.8 bisと同じ用語を使用しません。むしろ、v.21 [12]によって300ビット/sで転送されたビットで構成される4つの信号を定義します。コールインジケーター信号（CI）、コールメニュー信号（CM）、CMターミネーター（CJ）、およびジョイントを定義します。メニュー信号（JM）。さらに、V.25 [13]およびT.30 [8]（以下で説明）で定義されたトーンを使用し、V.8自体で定義された1つのトーン（ANSAM）を使用します。呼び出し端子は、V.21ローチャネルを使用して送信します。応答端末はハイチャネルを使用します。
The basic protocol sequence is subject to a number of variations to accommodate different terminal types. A pure V.8 sequence is as follows:
基本的なプロトコルシーケンスは、さまざまな端子タイプに対応するための多くのバリエーションの対象となります。純粋なV.8シーケンスは次のとおりです。
1. After an initial period of silence, the calling terminal transmits the V.8 CI signal. It repeats CI at least three times, continuing with occasional pauses until it detects ANSam tone. The CI indicates whether the calling terminal wants to function as H.324, V.18, T.30 send, T.30 receive, or a V-series modem.
1. 沈黙の初期期間の後、呼び出し端子はV.8 CI信号を送信します。CIを少なくとも3回繰り返し、ANSAMトーンを検出するまで時折一時停止し続けます。CIは、呼び出し端子がH.324、v.18、T.30 Send、T.30受信、またはVシリーズモデムとして機能するかどうかを示します。
2. The answering terminal transmits ANSam after detecting CI. ANSam will disable any G.164 [6] echo suppressors on the circuit after 400 ms and any G.165 [7] echo cancellers after one second of ANSam playout.
2. 回答端末は、CIを検出した後、ANSAMを送信します。ANSAMは、400ミリ秒後に回路上のG.164 [6]エコーサプレッサーを無効にし、ANSAMプレイアウトの1秒後にG.165 [7]エコーキャンセラーを無効にします。
3. On detecting ANSam, the calling terminal pauses at least half a second, then begins transmitting CM to indicate detailed capabilities within the chosen mode.
3. ANSAMを検出すると、呼び出し端子が少なくとも半秒は一時停止し、CMの送信を開始して、選択したモード内で詳細な機能を示します。
4. After detecting at least two identical sequences of CM, the answering terminal begins to transmit JM, indicating its own capabilities (or offering an alternative terminal type if it cannot support the one requested).
4. CMの少なくとも2つの同一のシーケンスを検出した後、応答端末はJMの送信を開始し、独自の機能を示します（または、要求されたものをサポートできない場合は代替端末タイプを提供します）。
5. After detecting at least two identical sequences of JM, the calling terminal completes the current octet of CM, then transmits CJ to acknowledge the JM signal. It pauses exactly 75 ms, then starts operating in the selected mode.
5. JMの少なくとも2つの同一のシーケンスを検出した後、呼び出し端子はCMの現在のオクテットを完了し、CJを送信してJM信号を認めます。正確に75ミリ秒を一時停止し、選択したモードで動作を開始します。
6. The answering terminal transmits JM until it has detected CJ. At that point, it stops transmitting JM immediately, pauses exactly 75 ms, then starts operating in the selected mode.
6. 応答端末は、JMがCJを検出するまで送信します。その時点で、JMの送信をすぐに停止し、正確に75ミリ秒を一時停止し、選択したモードで動作を開始します。
The CI, CM, and JM signals all consist of a fixed sequence of ten '1' bits followed by a signal-dependent pattern of ten synchronization bits, followed by one or more octets of variable information. Each octet is preceded by a '0' start bit and followed by a '1' stop bit. The combination of the synchronization pattern and V.21 channel uniquely identifies the message type. The CJ signal consists of three successive octets of all zeros with stop and start bits but without the preceding '1's and synchronizing pattern of the other signals.
CI、CM、およびJMシグナルはすべて、10個の '1'ビットの固定シーケンスで構成され、その後10個の同期ビットの信号依存パターンが続き、その後に1オクテットの可変情報が続きます。各オクテットの前に「0」の開始ビットが続き、その後に「1」の停止ビットが続きます。同期パターンとv.21チャネルの組み合わせは、メッセージタイプを一意に識別します。CJ信号は、すべてのゼロの3つの連続したオクテットで構成され、停止および開始ビットがありますが、他の信号の前の「1」と同期パターンがありません。
Applications MAY report each instance of a CM, JM, and CJ signal, respectively, as a series of V.21 bit events (Section 2.2), or may use another payload type to carry this information. Applications supporting V.8 signalling using the telephone-event payload MAY report the synchronization part of the CI signal (ten '1's followed by '00000 00001') both as a series of V.21 bit events and, when it has been recognized, as a single CI event.
アプリケーションは、それぞれCM、JM、およびCJ信号の各インスタンスを、一連のV.21ビットイベント（セクション2.2）として報告するか、この情報を携帯するために別のペイロードタイプを使用する場合があります。v.8のシグナリングをサポートするアプリケーション電話 - イベントペイロードを使用すると、V.21ビットイベントのシリーズとして、およびそれが認識されている場合、CI信号の同期部分（10 '1に続いて「00000 00001」）を報告できます。単一のCIイベントとして。
Note that the CI event covers only the synchronization part of the CI signal. The remaining call function octet and its start and stop bits need to be transmitted also, either as a series of V.21 bit events or in some other payload format. Presumably, the calling end gateway will use the same format for the CM and CJ signals.
CIイベントは、CI信号の同期部分のみをカバーすることに注意してください。残りのコール関数Octetとその開始および停止ビットは、一連のV.21ビットイベントまたは他のペイロード形式のいずれかとしても送信する必要があります。おそらく、呼び出しエンドゲートウェイは、CMおよびCJ信号に同じ形式を使用します。
The overlapping nature of V.8 signalling means that there is no risk of silence exceeding 100 ms once ANSam has disabled any echo control circuitry. However, the 75-ms pause before entering operation in the selected data mode will require both the calling and the answering gateways to recognize the completion of CJ, so they can change from playout of telephone-event to playout of the data-bearing payload after the 75-ms period.
V.8シグナル伝達の重複性は、ANSAMがエコー制御回路を無効にすると、100ミリ秒を超える沈黙のリスクがないことを意味します。ただし、選択したデータモードで操作を入力する前に75 msが一時停止するには、CJの完了を認識するために通話と応答ゲートウェイの両方が必要なため、電話 - イベントの再生からデータを含むペイロードの再生に変更できます。75 msの期間。
+--------+----------------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------+----------------------+------------+------+---------+
| ANSam | 2100 x 15 | 34 | tone | yes |
| | | | | |
| /ANSam | 2100 x 15 phase rev. | 35 | tone | yes |
| | | | | |
| CI | (V.21 bits) | 53 | tone | yes |
+--------+----------------------+------------+------+---------+
Table 3: Events for V.8 Signals
表3：V.8信号のイベント
ANSam:
The modified answer tone ANSam consists of a sinewave signal at 2100 Hz, amplitude-modulated by a sine wave at 15 Hz. The beginning of the event is at the beginning of the tone. The end of the event is at the sooner of the ending of the tone or the occurrence of a phase reversal (marking the beginning of a /ANSam event). Phase reversals are used to disable echo cancellation; if they are being applied, they occur at 450-ms intervals.
修正された回答トーンANSAMは、2100 Hzの正弦波信号で構成され、15 Hzの正弦波によって振幅されます。イベントの始まりは、トーンの始まりです。イベントの終了は、トーンの終了または相反転の発生の早い時期にあります（A /ANSAMイベントの始まりをマークします）。相反転は、エコーキャンセルを無効にするために使用されます。それらが適用されている場合、それらは450 ms間隔で発生します。
An ANSam event packet SHOULD NOT be sent until it is possible to discriminate between an ANSam event and an ANS event (see V.25 events, below).
The modulated envelope for the ANSam tone ranges in amplitude between 0.8 and 1.2 times its average amplitude. The average transmitted power is governed by national regulations. Thus, it makes sense to indicate the volume of the signal.
ANSAMトーンの変調エンベロープは、その平均振幅が0.8〜1.2倍の振幅の範囲です。平均伝達された電力は、国家規制によって支配されています。したがって、信号の体積を示すことは理にかなっています。
/ANSam:
/ansam：
/ANSam reports the same physical signal as ANSam, but is reported following the first phase reversal in that signal. It begins with the phase reversal and ends at the end of the tone. The receiver of /ANSam MUST reverse the phase of the tone at the beginning of playout of /ANSam and every 450 ms thereafter until the end of the tone is reached.
/ANSAMは、ANSAMと同じ物理信号を報告しますが、その信号の最初の相逆転に続いて報告されています。それは位相の反転から始まり、トーンの最後で終わります。/ansamのレシーバーは、 /ansamのプレイアウトの開始時にトーンの位相を逆転させ、その後450ミリ秒ごとにトーンの終了に達するまで逆転する必要があります。
CI:
CI：
CI reports the occurrence of the V.21 bit pattern '11111 11111 00000 00001' indicating the beginning of a V.8 CI signal. The event begins at the beginning of the first bit and ends at the end of the last one. This event MUST NOT be reported except in a context where a V.8 CI signal might be expected (i.e., at the calling end during call setup). Note that if the calling modem sends the CI signal at all, it will typically repeat the signal several times.
CIは、V.21ビットパターン '11111 11111 00000 00001'の発生を報告しています。イベントは最初のビットの最初から始まり、最後のビットの終わりに終わります。このイベントは、V.8 CI信号が予想されるコンテキスト（つまり、コールセットアップ中の呼び出し端）を除き、報告してはなりません。呼び出しモデムがCI信号をまったく送信した場合、通常、信号を数回繰り返すことに注意してください。
It is expected that the CI event will be most useful when the modem content is being transmitted primarily using another payload type. The event acts as a commentary on that content, allowing the receiver to recognize that V.8 signalling is in progress.
モデムコンテンツが主に別のペイロードタイプを使用して送信されている場合、CIイベントが最も役立つと予想されます。このイベントは、そのコンテンツの解説として機能し、受信者がV.8シグナリングが進行中であることを認識できるようにします。
The tolerances built into V.8 suggest that it may be mostly robust in the face of packet losses or delays. Playout of ANSam and /ANSam can be extended for multiple packetization periods without harm, provided that phase reversals occur on schedule at 450-ms intervals during playout of the latter.
v.8に組み込まれた許容範囲は、パケットの損失または遅延に直面してほとんど堅牢である可能性があることを示唆しています。ANSAMおよび /ANSAMのプレイアウトは、後者の再生中に位相の反転が450 ms間隔でスケジュール通りに発生すると、害のない複数のパケット化期間の間延長できます。
To increase robustness of transmission of the V.21-based signals, sending applications using the V.21 events SHOULD include an integral number of octets, including start and stop bits, in each packet. The presence of start and stop bits provides some hope that receiving implementations can withstand unavoidable gaps in playout between octets. When a message is being repeated (as is possible for CI, CM, and JM), an even stronger robustness measure would be for the receiver to retain a copy of the message when it is first received, and when a packet is delayed or lost to continue playing out the current message instance and commence a new repetition as if packets had continued to arrive on schedule.
V.21ベースの信号の送信の堅牢性を高めるには、V.21イベントを使用してアプリケーションを送信するには、各パケットに開始および停止ビットを含むオクテットの積分数を含める必要があります。スタートビットとストップビットの存在は、実装を受信することでオクテット間のプレイアウトで避けられないギャップに耐えることができるという希望を提供します。メッセージが繰り返されている場合（CI、CM、およびJMの可能性があるように）、さらに強い堅牢性の尺度は、受信者が最初に受信したときにメッセージのコピーを保持し、パケットが遅延または紛失したときにメッセージのコピーを保持することです。現在のメッセージインスタンスの再生を続け、パケットがスケジュール通りに到着し続けたかのように新しい繰り返しを開始するために。
V.25 [13] is a start-up protocol predating V.8 [9] and V.8 bis [10]. It specifies the exchange of two tone signals: CT and ANS.
v.25 [13]は、v.8 [9]およびv.8 Bis [10]に先立つスタートアッププロトコルです。CTとANSの2つのトーン信号の交換を指定します。
CT (calling tone) consists of a series of interrupted bursts of 1300-Hz tone, 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. [13]. Modems not starting with the V.8 CI signal often use this tone.
CT（呼び出しトーン）は、1300 Hzのトーンの一連の中断されたバーストで構成されており、0.5秒以上、0.7秒以下、1.5秒以上、2.0以下の期間でオフになります。s。[13]。v.8 CI信号から始まっていないモデムは、しばしばこのトーンを使用します。
ANS (Answer tone) is a 2100-Hz tone used to disable echo suppression for data transmission [13], [8]. For fax machines, Recommendation T.30 [8] refers to this tone as called terminal identification (CED) answer tone. ANS differs from V.8 ANSam in that, unlike the latter, it has constant amplitude.
ANS（回答トーン）は、データ送信のエコー抑制を無効にするために使用される2100 Hzのトーンです[13]、[8]。ファックスマシンの場合、推奨T.30 [8]は、ターミナル識別（CED）と呼ばれるこのトーンを指します。ANSは、後者とは異なり、v.8 Ansamとは異なり、一定の振幅を持っています。
V.25 specifically includes procedures for disabling echo suppressors as defined by ITU-T Rec. G.164 [6]. However, G.164 echo suppressors have now for the most part been replaced by G.165 [7] echo cancellers, which require phase reversals in the disabling tone (see ANSam above). As a result, Recommendation V.25 was modified in July 2001 to say that phase reversal in the ANS tone is required if echo cancellers are to be disabled.
One possible V.25 sequence is as follows:
可能なv.25シーケンスの1つは次のとおりです。
1. The calling terminal starts generating CT as soon as the call is connected.
1. 呼び出し端子は、呼び出しが接続されるとすぐにCTの生成を開始します。
2. The called terminal waits in silence for 1.8 to 2.5 s after answer, then begins to transmit ANS continuously. If echo cancellers are on the line, the phase of the ANS signal is reversed every 450 ms. ANS will not reach the calling terminal until the echo control equipment has been disabled. Since this takes about a second, it can only happen in the gap between one burst of CT and the next.
2. 呼び出された端子は、回答後1.8〜2.5秒間沈黙して待機し、その後ANSを継続的に送信し始めます。エコーキャンセラーがライン上にある場合、ANS信号の位相は450ミリ秒ごとに逆転します。ANSは、エコー制御機器が無効になるまで呼び出し端子に到達しません。これには約1秒かかるため、CTのバーストと次のバーストの間のギャップでのみ発生する可能性があります。
3. Following detection of ANS, the calling terminal may stop generating CT immediately or wait until the end of the current burst to stop. In any event, it must wait at least 400 ms (at least 1 s if phase reversal of ANS is being used to disable echo cancellers) after stopping CT before it can generate the calling station response tone. This tone is modem-specific, not specified in V.25.
3. ANSの検出後、呼び出し端子はすぐにCTの生成を停止するか、現在のバーストの終了まで停止することができます。いずれにせよ、CTを停止した後、CTを停止した後、少なくとも400ミリ秒（ANSの位相逆転がエコーキャンセラーを無効にする場合は少なくとも1秒）を待つ必要があります。このトーンはモデム固有であり、v.25で指定されていません。
4. The called terminal plays out ANS for 2.6 to 4.0 seconds or until it has detected calling station response for 100 ms. It waits 55-95 ms (nominal 75 ms) in silence. (Note that the upper limit of 95 ms is rather close to the point at which echo control may reestablish itself.) If the reason for ANS termination was timeout rather than detection of calling station response, the called terminal begins to play out ANS again to maintain disabling of echo control until the calling station responds.
4. 呼び出された端末は、ANSを2.6〜4.0秒間、または100ミリ秒間通話ステーション応答を検出するまで再生します。沈黙して55〜95ミリ秒（名目75ミリ秒）を待ちます。（95ミリ秒の上限は、エコー制御がそれ自体を再確立する可能性のあるポイントにかなり近いことに注意してください。）ANS終了の理由が通話ステーション応答の検出ではなくタイムアウトであった場合、呼び出された端末は再びANSを再生し始めます呼び出しステーションが応答するまで、エコー制御の無効化を維持します。
The events defined for V.25 signalling are shown in Table 4.
+-------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+-------------------+----------------+------------+------+---------+
| Answer tone (ANS) | 2100 | 32 | tone | yes |
| | | | | |
| /ANS | 2100 ph. rev. | 33 | tone | yes |
| | | | | |
| CT | 1300 | 49 | tone | yes |
+-------------------+----------------+------------+------+---------+
Table 4: Events for V.25 Signals
表4：V.25信号のイベント
ANS:
The beginning of the event is at the beginning of the 2100-Hz tone. The end of the event is at the sooner of the ending of the tone or the occurrence of a phase reversal (marking the beginning of a /ANS event).
イベントの開始は、2100 Hzのトーンの開始です。イベントの終了は、トーンの終了または位相反転の発生（A /ANSイベントの始まりをマークする）の早い時期にあります。
An initial ANS event packet SHOULD NOT be sent until it is possible to discriminate between an ANS event and an ANSam event (see V.8 events, above).
最初のANSイベントパケットは、ANSイベントとANSAMイベントを区別できるまで送信しないでください（上記のv.8イベントを参照）。
/ANS:
/ans：
/ANS reports the same physical signal as ANS, but is reported following the first phase reversal in that signal. It begins with the phase reversal and ends at the end of the tone. The receiver of /ANS MUST reverse the phase of the tone at the beginning of playout of /ANS and every 450 ms thereafter until the end of the tone is reached.
/ANSはANSと同じ物理信号を報告しますが、その信号の最初の相逆転に続いて報告されています。それは位相の反転から始まり、トーンの最後で終わります。/ansのレシーバーは、 /ansのプレイアウトの開始時にトーンの位相を逆にし、その後450ミリ秒ごとにトーンの終了に達するまで逆にする必要があります。
CT:
CT：
The beginning of the CT event is at the beginning of an individual burst of the 1300-Hz tone. The end of the event is at the end of that tone burst. The gateway at the calling end SHOULD use a packetization interval smaller than the nominal duration of a CT burst, to ensure that CT playout at the called end precedes the sending of ANS from that end.
CTイベントの開始は、1300 Hzのトーンの個々のバーストの開始です。イベントの終わりは、そのトーンの終わりにあります。呼び出し端のゲートウェイは、CTバーストの公称持続時間よりも小さいパケット化間隔を使用して、呼び出された端でのCTプレイアウトがその端からのANSの送信に先行することを確認する必要があります。
The V.25 sequence appears to be robust in the face of lost or delayed packets, provided that the receiver continues to play out any tone it is in the process of playing until more packets are received. The receiver must play out the phase transitions for /ANS on schedule, at 450-ms intervals, even if updates of the /ANS event have been delayed. It also appears to be possible for the sender to temporarily increase the packetization interval to reduce packet volumes when congestion is encountered. The one risk is that extended playout proceeds past the actual end of the tone (as determined retroactively), and the receiver is forced to continue imposing an additional playout buffering lag in order to meet the constraint on maximum duration of the nominal 75-ms silent period following tone playout.
V.25シーケンスは、レシーバーがより多くのパケットが受信されるまで再生中のトーンを引き続き再生し続けていれば、パケットの紛失または遅延パケットに直面して堅牢であるように見えます。/ansイベントの更新が遅れた場合でも、レシーバーは、450 ms間隔でスケジュール上の /ansの位相遷移を再生する必要があります。また、送信者が一時的にパケット化間隔を増やして、うっ血が発生したときにパケットの量を減らすことができるようです。1つのリスクは、拡張されたプレイアウトがトーンの実際の端を過ぎて（遡及的に決定された）進行し、レシーバーは、公称75 msサイレントの最大期間の制約を満たすために追加のプレイアウトバッファリングラグを課し続けることを余儀なくされることです。トーンプレイアウト後の期間。
ITU-T Recommendation V.32 [14] is a modem using phase-shift keying with quadrature amplitude modification. It operates on a carrier at 1800 Hz, modulated at 2400 symbols/s. The basic data rates for V.32 are 4800 and 9600 bits/s. V.32bis [15] extends the data rates up to 14,400 bits/s. Most or all existing deployments are V.32bis, typically in support of point-of-sale terminals and the like.
One reason V.32bis is still used is because of its relatively rapid start-up sequence, particularly on leased lines. Operating over the public telephone network, the start-up begins as follows:
V.32bisがまだ使用されている理由の1つは、特にリースされたラインでの比較的迅速な起動シーケンスのためです。公衆電話網を介して運営されているこのスタートアップは、次のように始まります。
a. the answering end begins with the V.25 answering procedure (1.8 to 2.5 s of silence followed by continuous ANS tone to a maximum of 3.3 s, with possible phase reversals to disable echo cancelling equipment);
a. 回答の端は、V.25回答手順（1.8〜2.5秒の沈黙に続いて最大3.3秒まで連続ANSトーンが続き、エコーキャンセル機器を無効にする可能性のある位相反転）から始まります。
b. the calling end waits in silence until it has detected ANS for 1 s;
b. 呼び出し端は、ANSを1秒間検出するまで沈黙して待機します。
c. the calling end begins to transmit a V.32/V.32bis pattern designated AA, i.e., a series of '0000' bit sequences transmitted at 4800 bits/s;
c. 呼び出し端は、AAと指定されたV.32/v.32Bisパターン、つまり4800ビット/sで送信される一連の「0000」ビットシーケンスを送信し始めます。
d. upon detecting the AA pattern for at least 100 ms, the called modem is silent for 75 +/- 20 ms, then responds with an AC pattern, which is a series of '0011' bit sequences transmitted at 4800 bits/s.
d. AAパターンを少なくとも100ミリ秒間検出すると、呼び出されたモデムは75 /-20ミリ秒間静かになり、ACパターンで応答します。これは、4800ビット /sで送信される一連の「0011」ビットシーケンスです。
The difference in leased line operation is that the calling modem starts the session by sending AA. After that, the called modem responds with AC, and the rest of the sequence is unchanged.
リースされたライン操作の違いは、呼び出しモデムがAAを送信することによりセッションを開始することです。その後、呼び出されたモデムはACで応答し、残りのシーケンスは変更されません。
In support of V.32/V.32bis operation, Table 5 defines two events, V32AA and V32AC.
v.32/v.32bis操作をサポートして、表5はV32AAとV32ACの2つのイベントを定義しています。
+----------------+------------------+------------+------+---------+
| Event | Bit Pattern | Event Code | Type | Volume? |
+----------------+------------------+------------+------+---------+
| V32AA | b'0000' repeated | 63 | tone | yes |
| | | | | |
| V32AC | b'0011' repeated | 27 | tone | yes |
+----------------+------------------+------------+------+---------+
Table 5: Events for V.32/V.32bis Signals
表5：v.32/v.32bis信号のイベント
V32AA:
V32AA：
Indicates that the AA calling pattern of a V.32/V.32bis terminal has been detected.
v.32/v.32bis端子のAA呼び出しパターンが検出されたことを示します。
V32AC:
V32AC：
Indicates that the AC answering pattern of a V.32/V.32bis terminal has been detected.
v.32/v.32bis端子のAC回答パターンが検出されたことを示します。
Each of these two events begins at the beginning of its pattern, and ends nominally when the pattern stops being received. Following the sending of either of these events the session may continue using V.150.1 modem relay [32] or Clearmode [17] as negotiated or configured in advance. To help make the transition as quickly as possible, the V32AA or V32AC event SHOULD be reported as soon as the corresponding pattern is detected. It seems likely that the implementation will be transmitting the event reports simultaneously with the same data in an alternate form, typically using RFC 2198 [2] redundancy.
これら2つのイベントのそれぞれは、パターンの開始時に始まり、パターンが受信されなくなったときに名目上終了します。これらのイベントのいずれかの送信に続いて、セッションはv.150.1モデムリレー[32]またはClearMode [17]を、事前に交渉または構成し続けることができます。できるだけ早く移行を行うために、対応するパターンが検出されるとすぐにV32AAまたはV32ACイベントを報告する必要があります。実装は、通常、RFC 2198 [2]冗長性を使用して、同じデータと同じデータと同時にイベントレポートを送信する可能性が高いようです。
The primary issue raised by congestion is the loss or undue delay of the initial report. Once the receiver is aware that an AA or AC pattern has been detected, further reports are of no interest. The actual duration of the AC pattern may be as short as 27 ms. On this basis, the appropriate sender behavior may be to send at least three packets reporting the event using normal event updates and end of event retransmission behavior and a fairly short packetization interval (20-30 ms).
輻輳によって提起された主な問題は、最初のレポートの損失または過度の遅延です。受信者がAAまたはACパターンが検出されたことを認識すると、さらなるレポートは興味がありません。ACパターンの実際の持続時間は、27ミリ秒という短い場合があります。これに基づいて、適切な送信者の動作は、通常のイベントの更新とイベントの再送信の終了とかなり短いパケット化間隔（20〜30ミリ秒）を使用して、イベントを報告する少なくとも3つのパケットを送信することです。
ITU-T Recommendation T.30 [8] defines the procedures used by Group III fax terminals. The pre-message procedures for which the events of this section are defined are used to identify terminal capabilities at each end and negotiate operating mode. Post-message procedures are also included, to handle cases such as multiple document transmission. Fax terminals support a wide variety of protocol stacks, so T.30 has a number of options for control protocols and sequences.
ITU-T推奨T.30 [8]は、グループIII FAX端子で使用される手順を定義しています。このセクションのイベントが定義されているメサージ前の手順は、各端で端子機能を識別し、操作モードをネゴシエートするために使用されます。複数のドキュメント送信などのケースを処理するために、メサージ後の手順も含まれています。FAX端子はさまざまなプロトコルスタックをサポートするため、T.30には制御プロトコルとシーケンスのオプションが多数あります。
T.30 defines two tone signals used at the beginning of a call. The CNG signal is sent by the calling terminal. It is a pure 1100-Hz tone played in bursts: 0.5 s on, 3 s off. It continues until timeout or until the calling terminal detects a response. Its primary purpose is to let human operators at the called end know that a fax terminal has been activated at the calling end.
T.30は、呼び出しの開始時に使用される2つのトーン信号を定義します。CNG信号は、呼び出し端子によって送信されます。バーストで再生される純粋な1100 Hzのトーンです：0.5秒オン、3秒オフ。タイムアウトまで、または呼び出し端子が応答を検出するまで続きます。その主な目的は、呼び出された端にある人間のオペレーターに、呼び出し端でファックス端子がアクティブ化されたことを知らせることです。
The called terminal waits in silence for at least 200 ms. It then may return CED tone (which is physically identical to V.25 ANS), or else V.8 ANSam if it has V.8 capability. If called and calling terminals both support V.8, the called terminal will detect CI or more likely CM in response to its ANSam and will continue with V.8 negotiation. Otherwise, the called terminal stops transmitting CED after 2.6 to 4 seconds, waits 75 +/- 20 ms in silence, then enters the T.30 negotiation phase.
呼び出された端子は、少なくとも200ミリ秒間沈黙して待機します。その後、CEDトーン（V.25 Ansと物理的に同一）を返すか、V.8機能がある場合はv.8 Ansamを返します。呼び出しおよび呼び出し端子の両方がV.8をサポートする場合、呼び出された端子は、そのANSAMに応じてCIまたはCMを検出し、V.8交渉を続けます。それ以外の場合、呼び出された端子停止は、2.6〜4秒後にCEDを送信し、沈黙で75 /-20ミリ秒待ち、T.30交渉段階に入ります。
In the T.30 negotiation phase the terminals exchange binary messages using V.21 signals, high channel frequencies only, at 300 bits/s. Each message is preceded by a one-second (nominal) preamble consisting entirely of HDLC flag octets (0x7E). This flag has the function of preparing echo control equipment for the message that follows.
T.30交渉段階では、端子はV.21信号を使用して300ビット/sで高チャネル周波数のみを使用してバイナリメッセージを交換します。各メッセージの前には、完全にHDLCフラグオクテット（0x7e）で構成される1秒（名目）プリアンブルがあります。このフラグには、次のメッセージのエコー制御機器を準備する機能があります。
The pre-transfer messages exchanged using the V.21 coding are:
v.21コーディングを使用して交換される移動前のメッセージは次のとおりです。
Digital Identification Signal (DIS):
デジタル識別信号（DIS）：
Characterizes the standard ITU-T capabilities of the called terminal. This is always the first message sent.
呼び出された端子の標準のITU-T機能を特徴付けます。これは常に最初のメッセージです。
Digital Transmit Command (DTC):
デジタル送信コマンド（DTC）：
A possible response to the DIS signal by the calling terminal. It requests the called terminal to be the transmitter of the fax content.
呼び出し端子によるDIS信号への可能な応答。呼び出された端子がファックスコンテンツの送信機であることを要求します。
Digital Command Signal (DCS):
デジタルコマンド信号（DCS）：
A command message sent by the transmitting terminal to indicate the options to be used in the transmission and request that the other end prepare to receive fax content. This is sent by the calling end if it will transmit, or by the called end in response to a DTC from the calling end. It is followed by a training signal, also sent by the transmitting terminal.
送信端末によって送信されたコマンドメッセージは、送信で使用されるオプションを示し、もう一方の端がファックスコンテンツを受信するために準備することを要求します。これは、通話端が送信される場合、または呼び出し端から呼び出された端によって送信されます。その後、送信端子によって送信されるトレーニング信号が続きます。
Confirmation To Receive (CFR):
受信するための確認（CFR）：
A digital response confirming that the entire pre-message procedure including training has been completed and the message transmissions may commence.
トレーニングを含む前説明前の手順全体が完了し、メッセージの送信が開始されることを確認するデジタル応答があります。
Each message may consist of multiple frames bounded by HDLC flags. The messages are organized as a series of octets, but like V.8 bis, T.30 calls for the insertion of extra '0' bits to prevent spurious recognition of HDLC flags.
各メッセージは、HDLCフラグに囲まれた複数のフレームで構成されている場合があります。メッセージは一連のオクテットとして編成されていますが、v.8 bisと同様に、T.30はHDLCフラグの偽の認識を防ぐために、余分な「0」ビットを挿入する必要があります。
T.30 also provides for the transmission of control messages after document transmission has completed (e.g., to support transmission of multiple documents). The transition to and from the modem used for document transmission (V.17 [24], V.27ter [26], V.29 [27], V.34 [28]) is preceded by 75 ms (nominal) of silence).
T.30は、ドキュメントの送信が完了した後に制御メッセージの送信も提供します（たとえば、複数のドキュメントの送信をサポートするため）。ドキュメント送信に使用されるモデムとの移行（v.17 [24]、v.27ter [26]、v.29 [27]、v.34 [28]）の前には、75ミリ秒（名目）の沈黙があります。）。
Applications supporting T.30 signalling using the telephone-event payload MAY report the preamble preceding each message both as a series of V.21 bit events and, when it has been recognized, as a single V.21 preamble event. The T.30 control message following the preamble MAY be reported in the form of a sequence of V.21 bit events or using some other payload type. If transmitted as bit events, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, the terminating HDLC flags, and the extra '0' bits added to prevent false recognition of HDLC flags at the receiver. Implementers should note that these extra '0' bits mean that in general T.30 messages as transmitted on the wire will not come out to an even multiple of octets.
電話 - イベントペイロードを使用したT.30シグナリングをサポートするアプリケーションは、各メッセージに先行する前のプリアンブルを、一連のV.21ビットイベントとして、そしてそれが認識された場合、単一のV.21 Preambleイベントとして報告する場合があります。プリアンブルに続くT.30コントロールメッセージは、V.21ビットイベントのシーケンスの形で、または他のペイロードタイプを使用して報告される場合があります。ビットイベントとして送信された場合、送信された情報には、最初のHDLCフラグ、情報フィールド、チェックサム、終了HDLCフラグ、およびHDLCフラグの誤認識を防ぐために追加された追加の「0」ビット：メッセージの完全な内容を含める必要があります。レシーバーで。実装者は、これらの余分な「0」ビットを意味することに注意する必要があります。これは、一般的に、ワイヤーに送信されたT.30メッセージがオクテットの倍数に出てこないことを意味します。
The training signal sent by the transmitting terminal after DCS consists of a steady string of V.21 high channel zeros (1850-Hz tone) for 1.5 s. Since the bit rate (nominally 300 bits/s) should have been clearly established when processing the preceding signalling, it is natural that if the telephony-event payload type is being used, this training signal will also be sent as a series of V.21 bit events at that bit rate. However, if the sending gateway is capable of recognizing the transition from the end of the DCS to the start of training, it MAY report the training signal as a single extended V.21 (high channel) '0' event.
DCS後に送信端子によって送信されるトレーニング信号は、1.5秒間のV.21高チャネルゼロ（1850-Hzトーン）の安定したストリングで構成されています。前のシグナリングを処理する際にビットレート（名目上300ビット/s）は明確に確立されるべきであるため、テレフォニーイベントペイロードタイプが使用されている場合、このトレーニング信号は一連のVとしても送信されることは当然です。そのビットレートでの21ビットイベント。ただし、送信ゲートウェイがDCSの終了からトレーニングの開始への移行を認識できる場合、トレーニング信号を単一の拡張V.21（ハイチャネル） '0'イベントとして報告する場合があります。
The events defined for T.30 signalling are shown in Table 6. The CED and /CED events represent exactly the same tone signals as V.25 ANS and /ANS, and are given the same codepoints; they are reproduced here only for convenience.
T.30シグナル伝達で定義されたイベントを表6に示します。CEDおよび /CEDイベントは、V.25 ANSおよび /ANSとまったく同じトーン信号を表し、同じコードポイントが与えられます。ここでは、便利なためにのみ再現されています。
+--------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------------------+----------------+------------+------+---------+
| CED (Called tone) | 2100 | 32 | tone | yes |
| | | | | |
| /CED | 2100 ph. rev. | 33 | tone | yes |
| | | | | |
| CNG (Calling tone) | 1100 | 36 | tone | yes |
| | | | | |
| V.21 preamble flag | (V.21 bits) | 54 | tone | yes |
+--------------------+----------------+------------+------+---------+
Table 6: Events for T.30 Signals
CED:
CED：
The beginning of the event is at the beginning of the 2100-Hz tone. The end of the event is at the sooner of the ending of the tone or the occurrence of a phase reversal (marking the beginning of a /CED event).
イベントの開始は、2100 Hzのトーンの開始です。イベントの終了は、トーンの終了または位相反転の発生（A /CEDイベントの開始をマークする）の早い時期にあります。
An initial CED event packet SHOULD NOT be sent until it is possible to discriminate between a CED event and an ANSam event (see V.8 events, above).
最初のCEDイベントパケットは、CEDイベントとANSAMイベントを区別できるまで送信しないでください（上記のv.8イベントを参照）。
/CED:
/CED：
/CED reports the same physical signal as CED, but is reported following the first phase reversal in that signal. It begins with the phase reversal and ends at the end of the tone. The receiver of /CED MUST reverse the phase of the tone at the beginning of playout of /CED and every 450 ms thereafter until the end of the tone is reached.
/CEDは、CEDと同じ物理信号を報告しますが、その信号の最初の相逆転に続いて報告されています。それは位相の反転から始まり、トーンの最後で終わります。/cedの受信機は、 /cedのプレイアウトの開始時にトーンの位相を逆にし、その後450ミリ秒ごとにトーンの終了に達するまで逆転する必要があります。
CNG:
CNG：
The beginning of the CNG event is at the beginning of an individual burst of the 1100-Hz tone. The end of the event is at the end of that tone burst.
CNGイベントの開始は、1100 Hzのトーンの個々のバーストの開始です。イベントの終わりは、そのトーンの終わりにあります。
V.21 preamble flag:
V.21プリアンブルフラグ：
This event begins with the first V.21 bits transmitted after a period of silence. It ends when a pattern of V.21 bits other than an HDLC flag is observed. This means that the V.21 preamble event absorbs the initial HDLC flags of the following message.
このイベントは、沈黙の期間後に送信された最初のV.21ビットから始まります。HDLCフラグ以外のV.21ビットのパターンが観察されると終了します。これは、V.21プリアンブルイベントが次のメッセージの最初のHDLCフラグを吸収することを意味します。
It is expected that the V.21 preamble flag event will be most useful when the modem content is being transmitted primarily using another payload type. The event acts as a commentary on that content, allowing the receiver to prepare itself to transition to fax mode.
Modemコンテンツが主に別のペイロードタイプを使用して送信されている場合、V.21 Preamble Flagイベントが最も役立つと予想されます。このイベントは、そのコンテンツの解説として機能し、受信機がFAXモードへの移行に備えることができます。
T.30 appears to be an intermediate case in terms of its vulnerability to congestion. Tone playout in the face of packet delay or loss is subject to the same considerations as for V.25 (see Section 2.4.1). Similarly, the receiver may extend playout of the preamble event while waiting for further reports. However, gaps or extended playout of the V.21 sequences are not feasible. This means, as with V.8 bis, that the receiver must manage its playout buffer appropriately to increase robustness in the face of congestion.
T.30は、混雑に対する脆弱性の観点から中級の場合のようです。パケットの遅延または損失に直面したトーンプレイアウトは、V.25と同じ考慮事項の対象となります（セクション2.4.1を参照）。同様に、レシーバーは、さらなるレポートを待っている間、プリアンブルイベントのプレイアウトを延長する場合があります。ただし、V.21シーケンスのギャップまたは拡張プレイアウトは実行不可能です。これは、v.8 BISと同様に、受信者が混雑に直面して堅牢性を高めるために適切にプレイアウトバッファーを管理する必要があることを意味します。
Legacy text telephony uses a wide variety of terminals, with different standards favored in different parts of the world. Going forward, the vision is that new terminals will work directly into the packet network and be based on RFC 4103 [18] packetization of character data. In anticipation of this migration, it is RECOMMENDED that text carried in the PSTN by legacy modem protocols be converted to RFC 4103 packets at the sending gateway.
レガシーテキストテレフォニーは、世界のさまざまな地域でさまざまな基準が好まれており、さまざまな端末を使用しています。今後は、新しい端子がパケットネットワークに直接動作し、RFC 4103 [18]キャラクターデータのパケット化に基づいているというビジョンです。この移行を見越して、レガシーモデムプロトコルによってPSTNに掲載されたテキストは、送信ゲートウェイのRFC 4103パケットに変換することをお勧めします。
During a transitional period, however, gateways of a lesser capability may be able to recognize the nature of incoming content, but may only be able to encode it as voice-band data on the packet side. In such circumstances, it will help to optimize processing of the signal at the receiving end if that end receives an indication of the nature of the voice-encoded data signals. The events defined in this section provide such indications, and MAY be used in conjunction with ITU-T Recommendation V.152 [33], as one example, to carry the content as voice-band data.
ただし、移行期には、より低い機能のゲートウェイが着信コンテンツの性質を認識できる場合がありますが、パケット側のボイスバンドデータとしてのみエンコードできる場合があります。このような状況では、その終わりが音声エンコードされたデータ信号の性質の兆候を受け取る場合、受信側での信号の処理を最適化するのに役立ちます。このセクションで定義されているイベントは、そのような適応症を提供し、一例としてITU-Tの推奨V.152 [33]と併用することができます。
Implementers should take note of an additional class of text terminals not considered in the events below. These terminals use dual tone multi-frequency (DTMF) tones to encode and exchange signals. This application is described in RFC 4733 [5], Section 3.1, in conjunction with the registration of DTMF events.
実装者は、以下のイベントでは考慮されていないテキスト端子の追加クラスに注意する必要があります。これらの端子は、デュアルトーン多周波（DTMF）トーンを使用して、信号をエンコードおよび交換します。このアプリケーションは、DTMFイベントの登録と併せて、RFC 4733 [5]、セクション3.1で説明されています。
The events shown in Table 7 correspond to signals coming from the following modem types:
表7に示すイベントは、次のモデムタイプからの信号に対応しています。
o Baudot [34], a five bit character encoding nominally operating at 45.45 or 50 bits/s with frequencies 1800 Hz = '0', 1400 Hz = '1';
o Baudot [34]、周波数1800 Hz = '0'、1400 Hz = '1'で45.45または50ビット/sで動作する5ビット文字をコードする5ビット文字。
o EDT, which is V.21 [12] operating at 110 bits/s in half-duplex mode (lower channel only); characters are 7-bit IA5 plus initial start bit, trailing parity bit, and two stop bits;
o EDT、これはv.21 [12]は半分二重モードで110ビット/sで動作します（下部チャネルのみ）。文字は、7ビットIA5プラス初期開始ビット、パリティビットの後続、2つのストップビットです。
o Bell 103 mode (documented in Recommendation V.18 Annex D), which is structurally similar to V.21, but uses different frequencies: lower channel, 1070 Hz = '0', 1270 Hz = '1'; upper channel, 2025 Hz = '0', 2225 Hz = '1'; characters are US ASCII framed by one start bit, one trailing parity bit, and one stop bit;
o ベル103モード（推奨v.18付録Dで文書化）。これはv.21に構造的に類似していますが、異なる周波数を使用します。下部チャネル、1070 Hz = '0'、1270 Hz = '1'アッパーチャネル、2025 Hz = '0'、2225 Hz = '1';キャラクターは、1回のスタートビット、1回のパリティビット、および1ストップビットでフレーム化された私たちASCIIです。
o V.23 [25] based videotex, in Minitel and Prestel versions. V.23 offers a forward channel operating at 1200 bits/s if possible (2100 Hz = '0', 1300 Hz = '1') or otherwise at 600 bits/s (1700 Hz = '0', 1300 Hz = '1'), and a 75 bits/s backward channel, which is transmitting 390 Hz (continuous '1's) except when '0' is to be transmitted (450 Hz);
o v.23 [25]ベースのVideoTex、MinitelおよびPrestelバージョン。V.23は、可能であれば1200ビット/s（2100 Hz = '0'、1300 Hz = '1'）で動作するフォワードチャネルを提供します。'）、および75ビット/sの後方チャネル。これは、「0」が送信される場合を除き（450 Hz）390 Hz（連続' 1」を送信します。
o a non-V.18 text terminal using V.21 [12] at 300 bits/s. Characters are 7-bit national (e.g., US ASCII) with a start bit, parity, and one stop bit.
o 300ビット/sでV.21 [12]を使用した非V.18テキスト端末。キャラクターは、スタートビット、パリティ、およびワンストップビットを持つ7ビットナショナル（米国ASCIIなど）です。
+----------+-----------+----------------+---------+-------+---------+
| Event | Bit Rate | Frequency (Hz) | Event | Type | Volume? |
| | bits/s | | Code | | |
+----------+-----------+----------------+---------+-------+---------+
| ANS2225 | N/A | 2225 | 52 | tone | yes |
| | | | | | |
| V21L110 | 110 | 980/1180 | 55 | other | no |
| | | | | | |
| V21L300 | 300 | 980/1180 | 30 | other | no |
| | | | | | |
| V21H300 | 300 | 1650/1850 | 31 | other | no |
| | | | | | |
| B103L300 | 300 | 1070/1270 | 56 | other | no |
| | | | | | |
| V23Main | 600/1200 | 1700-2100/1300 | 57 | other | no |
| | | | | | |
| V23Back | 75 | 450/390 | 58 | other | no |
| | | | | | |
| Baud4545 | 45.45 | 1800/1400 | 59 | other | no |
| | | | | | |
| Baud50 | 50 | 1800/1400 | 60 | other | no |
| | | | | | |
| XCIMark | 1200 | 2100/1300 | 62 | tone | yes |
+----------+-----------+----------------+---------+-------+---------+
Table 7: Indicators for Text Telephony
表7：テキストテレフォニーのインジケーター
ANS2225:
ANS2225：
indicates that a 2225-Hz answer tone has been detected. This is a pure tone with no amplitude modulation and no semantics attached to phase reversals, if there are any. The sender SHOULD report the beginning of the event when the tone is detected. The sender MAY send updates as the tone continues, and MUST report the end of the event when the tone ceases. The tone concerned is generated by a Bell 103-type modem in answer mode. This event MUST NOT be reported outside of the startup context (i.e., on the answering side at the beginning of a call).
2225 Hzの回答トーンが検出されたことを示します。これは、振幅変調がなく、フェーズの反転にセマンティクスが付いていない純粋なトーンであり、もしあれば。送信者は、トーンが検出されたときにイベントの開始を報告する必要があります。送信者は、トーンが続くと更新を送信する場合があり、トーンが停止したときにイベントの終了を報告する必要があります。関係するトーンは、回答モードでベル103タイプのモデムによって生成されます。このイベントは、スタートアップのコンテキストの外で（つまり、コールの開始時に応答側で）報告してはなりません。
V21L110:
indicates that the sender has detected V.21 modulation operating in the lower channel at 110 bits/s. Note that it may take some time to distinguish between 300 bits/s and 110 bits/s operation. It is expected that implementations will not transmit both this event and individual V.21 bit events for the same content.
送信者が110ビット/sで下部チャネルで動作するV.21変調を検出したことを示します。300ビット/sと110ビット/sの動作を区別するのに時間がかかる場合があることに注意してください。実装は、このイベントと同じコンテンツに対して個々のV.21ビットイベントの両方を送信しないことが期待されています。
V21L300:
V21L300：
indicates that the sender has detected V.21 modulation operating in the lower channel at 300 bits/s. Note that it may take some time to distinguish between 300 bits/s and 110 bits/s operation. It is expected that implementations will not transmit both this event and individual V.21 bit events for the same content.
送信者が300ビット/sで下部チャネルで動作するV.21変調を検出したことを示します。300ビット/sと110ビット/sの動作を区別するのに時間がかかる場合があることに注意してください。実装は、このイベントと同じコンテンツに対して個々のV.21ビットイベントの両方を送信しないことが期待されています。
V21H300:
V21H300：
indicates that the sender has detected V.21 modulation operating in the upper channel at 300 bits/s. It is expected that implementations will not transmit both this event and individual V.21 bit events for the same content.
B103L300:
B103L300：
indicates that the sending device has detected Bell 103 class modulation operating in the low channel at 300 bits/s.
送信装置が300ビット/sで低いチャネルで動作するベル103クラス変調が検出されたことを示します。
V23Main:
v23main：
indicates that the sending device has detected V.23 modulation operating in the high-speed channel. As described below, this indicator may alternate with the XCIMark indication.
V23Back:
v23back：
indicates that the sending device has detected V.23 modulation operating in the 75 bit/s back-channel.
送信デバイスが75ビット/sバックチャネルで動作するV.23変調が検出されたことを示します。
Baud4545:
baud4545：
indicates that the sending device has detected Baudot modulation operating at 45.45 bits/s.
送信デバイスが45.45ビット/sで動作するボードモジュレーションが検出されたことを示します。
Baud50:
Baud50：
indicates that the sending device has detected Baudot modulation operating at 50 bits/s.
送信デバイスが50ビット/sで動作するボードモジュレーションが検出されたことを示します。
XCIMark:
xcimark：
Indicates that the sending device has detected the specific bit pattern (0) 1111 1111(1)(0)1111 1111(1) sent at 1200 bits/s using V.23 upper-channel modulation, following a period of V.23 main channel "mark" (1300 Hz).
送信デバイスが特定のビットパターン（0）1111 1111（1）（0）1111 1111（1）がV.23メインの期間に続いてV.23上チャネル変調を使用して1200ビット/sで送信されたことを検出したことを示します。チャネル「マーク」（1300 Hz）。
It is assumed in all cases that the event reports described here are being transmitted in addition to another media encoding, typically G.711 [19] voice-band data, reporting the same information. A natural method to do this is to combine the voice-band data with event reports in an RFC 2198 [2] redundancy payload.
すべての場合において、ここで説明するイベントレポートは、同じ情報を報告する別のメディアエンコーディング、通常はG.711 [19]の音声帯域データに加えて送信されていると想定されています。これを行うための自然な方法は、Voice-BandデータをRFC 2198 [2]冗長ペイロードでイベントレポートと組み合わせることです。
The handling of ANS2225 has been indicated above. Since it is a specific tone, it can be handled like any other tone event.
ANS2225の取り扱いは上記で示されています。特定のトーンであるため、他のトーンイベントと同様に処理できます。
For all of the other indicators, the sender SHOULD generate an initial event report as soon as the nature of the audio content has been recognized. For reliability, the initial event report SHOULD be retransmitted twice at short intervals. (20 ms is a suggested value, although the packetization period of the associated media may be sufficient.) The sender MAY continue to send additional reports of the same indicator event, although these have little value once the receiver has adjusted itself to the type of content it is receiving.
他のすべての指標について、送信者は、オーディオコンテンツの性質が認識されるとすぐに、初期イベントレポートを生成する必要があります。信頼性のために、最初のイベントレポートは短い間隔で2回再送信する必要があります。（20ミリ秒は提案された値ですが、関連するメディアの梱包期間は十分かもしれません。）送信者は、同じインジケーターイベントの追加レポートを送信し続けることができますが、レシーバーが自分自身を調整してもほとんど価値がありません。受信しているコンテンツ。
If the nature of the content changes (e.g., because it is coming from a V.18 terminal in the probing stage), the sender MUST send an event report for the new content type as soon as it is recognized. If the sender has been sending updates for the previous indicator, it SHOULD report the end of that previous indicator event along with the beginning of the new one.
コンテンツの性質が変更された場合（たとえば、プロービング段階のv.18端子から来ているため）、送信者は、認識されたらすぐに新しいコンテンツタイプのイベントレポートを送信する必要があります。送信者が以前のインジケーターの更新を送信している場合、新しいインジケーターイベントの終了と新しいインジケーションイベントの開始を報告する必要があります。
In the face of packet loss or delay, it is appropriate for the receiver to continue to play out the ANS2225 event until further packets are received. For the other events, the issue is loss of the initial event report rather than maintenance of playout continuity. The advice on retransmission of these other events already given above is sufficient to deal with packet loss or delay due to congestion.
ITU-T Recommendation V.18 [11] defines a terminal for text conversation, possibly in combination with voice. V.18 is intended to interoperate with a variety of legacy text terminals, so its start-up sequence can consist of a series of stimuli designed to determine what is at the other end. Two V.18 terminals talking to each other will use V.8 to negotiate startup and continue at the physical level with V.21 at 300 bits/s carrying 7-bit characters bounded by start and stop bits.
The V.18 terminal is also designed to interoperate with the text modems listed in the previous sub-section. The startup sequences for all these different terminal types are naturally quite different. The V.18 initial startup sequence specifically addresses itself to V.8-capable terminals and V.21 terminals and, by the combination of signals, to V.23 videotex terminals. During the initial startup sequence, the V.18 terminal listens for frequency responses characterizing the other terminal types. If it does not make contact in the preliminary step, it probes for each type specifically. By the nature of the application, V.18 has been designed to provide an extremely robust startup capability.
V.18端子は、前のサブセクションにリストされているテキストモデムと相互運用するように設計されています。これらすべての異なる端子タイプのスタートアップシーケンスは、当然とはまったく異なります。V.18の初期起動シーケンスは、v.8対応端子とv.21端子、および信号の組み合わせにより、v.23ビデオテックス端子に特に対処します。最初の起動シーケンス中に、v.18端子は、他の端子タイプを特徴付ける周波数応答のために耳を傾けます。予備ステップで接触しない場合、各タイプのプローブを具体的にプローブします。アプリケーションの性質により、v.18は非常に堅牢なスタートアップ機能を提供するように設計されています。
The handling of the V.18 XCI signal is a specific case of the procedures described in the previous section. XCI is a signal transmitted in high-band V.23 modulation to stimulate V.23 terminals to respond and to allow detection of V.18 capabilities in a DCE. The 3-second XCI signal uses the V.23 upper channel having periods of "mark" (i.e., 1300 Hz) alternating with the XCIMark pattern. The full definition is found in V.18, Section 3.13. The sender SHOULD indicate V23Main during the transmission of the "mark" portion of XCI, and change the indication to XCIMark when that pattern is detected.
V.18 XCI信号の処理は、前のセクションで説明した手順の特定のケースです。XCIは、v.23端子を刺激して応答し、DCEでV.18機能を検出できるように、高帯域V.23変調で送信される信号です。3秒のXCI信号は、XCimarkパターンと交互に「マーク」（つまり、1300 Hz）の周期を持つV.23上部チャネルを使用します。完全な定義は、v.18、セクション3.13にあります。送信者は、XCIの「マーク」部分の送信中にV23mainを示し、そのパターンが検出されたときに表示をXCimarkに変更する必要があります。
Numerous proprietary modem protocols exist, as well as standardized protocols not identified above. Table 8 defines a single indicator event that may be used to identify modem content when a more specific event is unavailable. Typically, this would be sent in combination with another payload type, for example, voice-band data as specified by ITU-T Recommendation V.152 [33].
多数の独自のモデムプロトコルと、上記では特定されていない標準化されたプロトコルが存在します。表8は、より具体的なイベントが利用できない場合にモデムコンテンツを識別するために使用できる単一のインジケータイベントを定義します。通常、これは別のペイロードタイプと組み合わせて送信されます。たとえば、ITU-T推奨V.152 [33]で指定されている音声バンドデータ。
As with the indicators in the previous section, the sender SHOULD generate an initial event report as soon as the nature of the audio content has been recognized. For reliability, the initial event report SHOULD be retransmitted twice at short intervals. (20 ms is a suggested value, although the packetization period of the associated media may be sufficient.) The sender MAY continue to send additional reports of the VBDGen event, although these have little value once the receiver has adjusted itself to the type of content it is receiving.
前のセクションのインジケーターと同様に、送信者は、オーディオコンテンツの性質が認識されるとすぐに、初期イベントレポートを生成する必要があります。信頼性のために、最初のイベントレポートは短い間隔で2回再送信する必要があります。（20ミリ秒は提案された値ですが、関連するメディアの梱包期間で十分かもしれません。）送信者は、VBDGenイベントの追加レポートを引き続き送信することができますが、レシーバーがコンテンツのタイプに調整してもほとんど価値がありません。受け取っています。
+--------+---------------+------------+-----------+-------+---------+
| Event | Bit Rate | Frequency | Event | Type | Volume? |
| | bits/s | (Hz) | Code | | |
+--------+---------------+------------+-----------+-------+---------+
| VBDGen | Variable | Variable | 61 | other | no |
+--------+---------------+------------+-----------+-------+---------+
Table 8: Generic Modem Signal Indicator
表8：一般的なモデム信号インジケーター
VBDGen:
vbdgen：
indicates that the sender has detected tone patterns indicating the operation of some form of modem. This indicator SHOULD NOT be sent if a more specific event is available.
送信者が、何らかの形のモデムの動作を示すトーンパターンを検出したことを示します。より具体的なイベントが利用可能な場合は、このインジケーターを送信しないでください。
As described in Section 1.2, the typical data application involves a pair of gateways interposed between two terminals, where the terminals are in the PSTN. The gateways are likely to be serving a mixture of voice and data traffic, and need to adopt payload types appropriate to the media flows as they occur. If voice compression is in use for voice calls, this means that the gateways need the flexibility to switch to other payload types when data streams are recognized.
セクション1.2で説明したように、典型的なデータアプリケーションには、端子がPSTNにある2つの端子の間に挿入されたゲートウェイのペアが含まれます。ゲートウェイは、音声とデータトラフィックの混合物を提供する可能性が高く、メディアフローに適したペイロードタイプを採用する必要があります。音声圧縮が音声通話に使用されている場合、これはゲートウェイがデータストリームが認識されたときに他のペイロードタイプに切り替える柔軟性を必要とすることを意味します。
Within the established IETF framework, this implies that the gateways must negotiate the potential payloads (voice, telephone-event, tones, voice-band data, T.38 fax [21], and possibly RFC 4103 [18] text and Clearmode [17] octet streams) as separate payload types. From a timing point of view, this is most easily done at the beginning of a call, but results in an over-allocation of resources at the gateways and in the intervening network.
確立されたIETFフレームワーク内で、これは、ゲートウェイが潜在的なペイロード（音声、イベント、トーン、音声バンドデータ、T.38ファックス[21]、およびおそらくRFC 4103 [18]テキストとクリアモード[17] Octet Streams）別々のペイロードタイプとして。タイミングの観点から見ると、これはコールの開始時に最も簡単に行われますが、ゲートウェイと介入ネットワークでのリソースが過剰に配分されます。
One alternative is to use named events to buy time while out-of-band signals are exchanged to update to the new payload type applicable to the session. Thanks to the events defined in this document, this is a viable approach for sessions beginning with V.8, V.8 bis, T.30, or V.25 control sequences.
1つの選択肢は、名前付きイベントを使用して時間を購入することです。帯域外シグナルは、セッションに適用される新しいペイロードタイプに更新するために交換されます。このドキュメントで定義されているイベントのおかげで、これはv.8、v.8 bis、t.30、またはv.25制御シーケンスから始まるセッションの実行可能なアプローチです。
Named data-related events also allow gateways to optimize their operation when data signals are received in a relatively general form. One example is the use of V.8-related events to deduce that the voice-band data being sent in a G.711 payload comes from a higher-speed modem and therefore requires disabling of echo cancellers.
名前付きデータ関連のイベントにより、データ信号が比較的一般的な形式で受信されたときに、ゲートウェイが操作を最適化することもできます。1つの例は、V.8関連のイベントを使用して、G.711ペイロードで送信される音声帯域データが高速モデムから来ているため、エコーキャンセラーの無効化が必要であると推測することです。
All of the control procedures described in the sub-sections of Section 2 eventually give way to data content. As mentioned above, this content will be carried by other payload types. Receiving gateways MUST be prepared to switch to the other payload type within the time constraints associated with the respective applications. (For several of the procedures documented above, the sender provides 75 ms of silence between the initial control signalling and the sending of data content.) In some cases (V.8 bis [10], T.30 [8]), further control signalling may happen after the call has been established.
セクション2のサブセクションで説明されているすべての制御手順は、最終的にデータコンテンツに取って代わります。上記のように、このコンテンツは他のペイロードタイプによって運ばれます。受信ゲートウェイは、それぞれのアプリケーションに関連付けられた時間制約内で他のペイロードタイプに切り替えるために準備する必要があります。（上記のいくつかの手順について、送信者は初期制御シグナル伝達とデータコンテンツの送信との間に75ミリ秒の沈黙を提供します。）場合によっては（v.8 bis [10]、t.30 [8]）、さらに通話が確立された後、コントロールシグナル伝達が発生する可能性があります。
A possible strategy is to send both the telephone-event and the data payload in an RFC 2198 [2] redundancy arrangement. The receiving gateway then propagates the data payload whenever no event is in progress. For this to work, the data payload and events (when present) MUST cover exactly the same content over the same time period; otherwise, spurious events will be detected downstream. An example of this mode of operation is shown below.
可能な戦略は、電話イベントとデータペイロードの両方をRFC 2198 [2]冗長配置で送信することです。受信ゲートウェイは、イベントが進行中の場合はいつでもデータペイロードを伝播します。これが機能するためには、データペイロードとイベント（存在する場合）は、同じ期間にわたってまったく同じコンテンツをカバーする必要があります。それ以外の場合、偽のイベントが下流で検出されます。この動作モードの例を以下に示します。
Note that there are a number of cases where no control sequence will precede the data content. This is true, for example, for a number of legacy text terminal types. In such instances, the events defined in Section 2.7 in particular MAY be sent to help the remote gateway optimize its handling of the alternative payload.
データコンテンツに先行する制御シーケンスがない場合が多いことに注意してください。これは、たとえば、多くのレガシーテキスト端末の型に当てはまります。そのような場合、特にセクション2.7で定義されているイベントは、リモートゲートウェイが代替ペイロードの処理を最適化するのを支援するために送信される場合があります。
This section presents an example of the use of the event codes defined in Section 2. The basic scenario is the startup sequence for duplex V.34 modem operation. It is assumed that once the initial V.8 sequence is complete, the gateways will enter into voice-band data operation using G.711 encoding to transmit the modem signals. The basic packet sequence is indicated in Table 9. Sample packets are then shown in detail for two variants on event transmission strategy:
このセクションでは、セクション2で定義されているイベントコードの使用例を示します。基本シナリオは、デュプレックスv.34モデム操作のスタートアップシーケンスです。初期v.8シーケンスが完了すると、G.711エンコーディングを使用してモデム信号を送信するためにゲートウェイがボイスバンドデータ操作に入ると想定されています。基本的なパケットシーケンスを表9に示します。サンプルパケットは、イベント送信戦略に関する2つのバリアントについて詳細に示されています。
o simultaneous transmission of events and retransmitted events using RFC 2198 [2] redundancy;
o RFC 2198 [2]冗長性を使用したイベントと再送信イベントの同時送信。
o simultaneous transmission of events, retransmitted events, and voice-band data covering the same content using RFC 2198 redundancy.
o RFC 2198冗長性を使用して、同じコンテンツをカバーするイベント、再送信イベント、および音声帯域データの同時送信。
For simplicity and semi-realism, the times shown for the example scenario assume a fixed lag at each gateway of 20 ms between the packet side of the gateway and the local user equipment and vice versa (i.e., minimum of 40 ms between packet received and packet sent specifically in response to the received packet). A propagation delay of 5 ms is assumed between gateways. It is assumed that the event packetization interval is 30 ms, a reasonable compromise between packet volume and buffering delay, particularly for V.21 events.
簡単にするために、例のシナリオに示されている時間は、ゲートウェイのパケット側とローカルユーザー機器の間の20ミリ秒の各ゲートウェイで固定された遅延を想定しています。受信したパケットに応じて特別に送信されたパケット）。ゲートウェイの間には、5ミリ秒の伝播遅延が想定されます。イベントパケット化間隔は30ミリ秒であると想定されており、特にV.21イベントでは、パケットボリュームとバッファリング遅延の合理的な妥協点です。
At the basic V.8 protocol level, the table assumes that the answering modem waits 0.2 s (200 ms) from the beginning of the call to start transmitting ANSam. The calling modem waits 1 s (1000 ms) from the time it begins to receive ANSam until it begins to send the V.8 CM signal. Both modems wait 75 ms from the time they finish sending and receiving CJ, respectively, until they begin sending V.34 modem signals.
基本的なV.8プロトコルレベルでは、テーブルは、回答モデムが呼び出しの先頭から0.2秒（200ミリ秒）で、ANSAMの送信を開始することを前提としています。呼び出しモデムは、ANSAMがv.8 cm信号を送信し始めるまで、ANSAMを受け取り始めてから1秒（1000ミリ秒）待ちます。両方のモデムは、CJの送信と受信がそれぞれv.34モデム信号の送信を開始するまで、それぞれ75ミリ秒待ちます。
+------------+------------------------------------------------------+
| Time (ms) | Event |
+------------+------------------------------------------------------+
| 220.0 | The called gateway detects the start of ANSam from |
| | its end. |
| | |
| 250.0 | The called gateway sends out the first ANSam event |
| | packet. M bit is set, timestamp is ts0 + 1760 |
| | (where ts0 is the timestamp value at the start of |
| | the call). The initial ANSam event continues until |
| | a phase shift is detected at 670.0 ms (see below). |
| | Up to this time, the called gateway sends out |
| | further ANSam event updates, with the same initial |
| | timestamp, M bit off, and cumulative duration |
| | increasing by 240 units each time. |
| | |
| 255.0 | The calling gateway receives the first ANSam event |
| | report and begins playout of ANSam tone at its end. |
| | |
| 275.0 | The calling terminal receives the beginning of ANSam |
| | tone and starts its timer. It will begin sending |
| | the CM signal 1 s later (at 1275.0 ms into the |
| | call). |
| | |
| 670.0 | The called gateway detects a phase shift in the |
| | incoming signal, marking a change from ANSam to |
| | /ANSam. This happens to coincide with the end of a |
| | packetization interval. For the sake of the |
| | example, assume that the called gateway does not |
| | detect this in time for the event report it sends |
| | out. |
| | |
| 700.0 | The called gateway issues its next-scheduled event |
| | report packet, indicating an initial report for |
| | /ANSam (M bit set, timestamp ts0 + 5360, duration |
| | 240 timestamp units). The packet also carries the |
| | first retransmission of the final ANSam report, |
| | total duration 3600 units, this time with the E bit |
| | set. |
| | |
| 1295.0 | The calling gateway begins to receive the CM signal |
| | from the calling modem. |
| | |
| 1325.0 | The calling gateway sends a packet containing the |
| | first 9 bits of the CM signal. |
| | |
| 1445.0 | The calling gateway sends out a packet containing |
| | the last 4 bits of the first CM signal, plus the |
| | first 5 bits of the next repetition of that signal. |
| | CM bits will continue to be transmitted from the |
| | calling gateway until 2015.0 ms (see below), for a |
| | total of 24 packets. (The final packet also carries |
| | the beginning of the CJ signal.) |
| | |
| 1596.7 | The called gateway completes playout of the final |
| | bit of the second occurrence of the CM signal. |
| | |
| 1636.7 | The called gateway detects end of /ANSam (and |
| | beginning of JM) from the called modem. The next |
| | packet is not yet due to go out. |
| | |
| 1660.0 | The called gateway sends out a packet combining the |
| | final /ANSam event report (E bit set and total |
| | duration 533 timestamp units) with the first 7 bits |
| | of the JM signal. The M bit for the packet is set |
| | and the packet timestamp is ts0 + 12560 (the start |
| | of the now-discontinued /ANSam event). |
| | |
| 1690.0 | The called gateway sends out a packet containing the |
| | next nine bits of JM signal. The M bit is set and |
| | the timestamp is ts0 + 13280 (beginning of the first |
| | bit in the packet). JM will continue to be |
| | transmitted until 2170.0 ms (see below), for a total |
| | of 18 packets (plus two for final retransmissions). |
| | |
| 1938.3 | The calling gateway completes playout of the final |
| | packet of the second occurrence of the JM signal. |
| | |
| 1995.0 | The calling gateway begins to receive the initial |
| | bits of the CJ signal. |
| | |
| 2015.0 | The calling gateway sends a packet containing the |
| | final 3 bits of the first decad of a CM signal and |
| | first 6 bits of a CJ signal. |
| | |
| 2095.0 | The calling gateway receives the last bit of the CJ |
| | signal. A period of silence lasting 75-ms begins at |
| | the called end. It is not yet time to send out an |
| | event report. |
| | |
| 2105.0 | The calling gateway sends out a packet containing |
| | the final 6 bits of the CJ signal. |
| | |
| 2130.0 | The called gateway finishes playing out the last CJ |
| | signal bit sent to it. |
| | |
| 2135.0 | The calling gateway sends a packet containing no new |
| | events, but retransmissions of the last 15 bits of |
| | the CJ signal (in two generations). |
| | |
| 2165.0 | The calling gateway sends out a packet containing no |
| | new events, but retransmissions of the final 6 bits |
| | of the CJ signal. |
| | |
| 2170.0 | The called gateway sends out the last packet |
| | containing bits of the JM signal (except for |
| | retransmissions). Note that according to the V.8 |
| | specification these bits do not in general complete |
| | a JM signal or even an "octet" of that signal |
| | (although they happen to do so in this example). A |
| | 75 ms period of silence begins at the called end. |
| | |
| 2170.0 | The calling gateway begins to receive V.34 |
| | signalling from the called modem. |
| | |
| 2175.0 | The calling gateway finishes playing out the last JM |
| | signal bit sent to it. |
| | |
| 2195.0 | The calling gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17360 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 200 8-bit samples. Packetization interval |
| | is shown here as continuing to be 30 ms. It could |
| | be less, but MUST NOT be more because that would |
| | make the silent period too long. |
| | |
| 2200.0 | The called gateway sends a packet containing no new |
| | events, but retransmissions of the last 18 bits of |
| | the JM signal (in two generations). |
| | |
| 2225.0 | The calling gateway sends out the second packet of |
| | V.34 signalling as voice-band data (PCMU). |
| | Timestamp is ts0 + 17560 and M bit is not set. The |
| | packet contains 240 8-bit samples. |
| | |
| 2230.0 | The called gateway sends out a packet containing no |
| | new events, but retransmissions of the final 9 bits |
| | of the JM signal. |
| | |
| 2245.0 | The called gateway begins to receive V.34 signalling |
| | from the called modem. |
| | |
| 2255.0 | The calling gateway sends out a third packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17800 and M bit is not set. The packet |
| | contains 240 8-bit samples. |
| | |
| 2260.0 | The called gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17960 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 120 samples. Packetization interval is |
| | shown here as continuing to be 30 ms. It could be |
| | less, but MUST NOT be more because that would make |
| | the silent period too long. |
| | |
| . . . | . . . |
+------------+------------------------------------------------------+
Table 9: Events for Example V.8 Scenario
表9：たとえば、v.8シナリオなどのイベント
Negotiation of the transmission mode being described in this section would use SDP similar to the following:
このセクションで説明されている送信モードの交渉は、以下と同様にSDPを使用します。
m=audio 12343 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12345 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
This indicates two media streams, the first for G.711 (i.e., voice or voice-band data), the second for triply-redundant telephone events. As RFC 2198 notes, it is also possible for the sender to send telephone-event payloads without redundancy in the second stream, although the redundant form is the primary transmission mode. (It would be reasonable to send the interim ANSam reports without redundancy.) The set of telephone events supported includes the DTMF events (not relevant in this example), and all of the data events defined in this document. In fact, only event codes 34-35 and 37-40 are used in the example.
これは、G.711の最初のメディアストリーム（つまり、音声または音声帯域データ）で、2番目のメディアストリームが、2番目のメディアが、Triply-Redantの電話イベントの場合は2番目です。RFC 2198が指摘しているように、送信者は冗長なフォームがプライマリ送信モードであるにもかかわらず、2番目のストリームで冗長性なしに電話とイベントのペイロードを送信することも可能です。（冗長性なしに暫定ANSAMレポートを送信することは合理的です。）サポートされている一連の電話イベントには、DTMFイベント（この例には関係ありません）、およびこのドキュメントで定義されているすべてのデータイベントが含まれます。実際、この例では、イベントコード34-35と37-40のみが使用されています。
For the purpose of illustrating the use of RFC 2198 redundancy as well as showing the basic composition of the event reports, the second packet reporting JM signal bits (sent by the called gateway at 1690.0 ms) seems to be a good choice. This packet will also carry the second retransmission of the final /ANSam event report and the first retransmission of the initial 7 bits of the JM signal. The detailed content of the packet is shown in Figure 1. To see the contents of the successive generations more clearly, they are presented as if they were aligned on successive 32-bit boundaries. In fact, they are all offset by one octet, following on consecutively from the RFC 2198 header.
RFC 2198冗長性の使用とイベントレポートの基本的な構成を示す目的のために、JM信号ビット（1690.0ミリ秒で呼び出されたゲートウェイによって送信）を報告する2番目のパケットレポートは良い選択のようです。このパケットには、最終 /ANSAMイベントレポートの2回目の再送信と、JM信号の最初の7ビットの最初の再送信も伴います。パケットの詳細な内容を図1に示します。連続した世代の内容をより明確に確認するために、それらは連続した32ビット境界に整合されているかのように提示されます。実際、RFC 2198ヘッダーから連続して続いて、それらはすべて1オクテットによって相殺されます。
The M bit is set in the RTP header for the packet, as required for the coding of multiple events in the primary block of data. In fact, RFC 2198 implies that this is the correct behavior, but does not say so explicitly. The E bit is set for every event. It is possible that it would not be set for the final event in the primary block.
Mビットは、データのプライマリブロックでの複数のイベントのコーディングに必要なパケット用のRTPヘッダーに設定されています。実際、RFC 2198は、これが正しい動作であることを暗示していますが、それほど明示的ではありません。Eビットはすべてのイベントに設定されています。プライマリブロックでの最終イベントに設定されない可能性があります。
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=0 |1| PT=100 | sequence number = seq0 + 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp = ts0 + 13280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 720 | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 267 | block length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=101| (begin block for /ANSam ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel) (first retransmission)
jmの最初の7ビット（= "1111111" in v.21ハイチャネル）（最初の再送信）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel) (new content)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet Contents, Redundant Events Only
図1：パケットコンテンツ、冗長イベントのみ
Since all of the events in the above packet are consecutive and adjacent, it would have been permissible according to the telephone-event payload specification to carry them as a simple event payload without the RFC 2198 header. The advantage of the latter is that the receiving gateway can skip over the retransmitted events when processing the packet, unless it needs them.
上記のパケットのすべてのイベントは連続しており、隣接しているため、RFC 2198ヘッダーなしで簡単なイベントペイロードとしてそれらを携帯するために、電話とイベントのペイロード仕様に従って許可されていました。後者の利点は、受信ゲートウェイがパケットを必要としない限り、パケットを処理するときに再送信されたイベントをスキップできることです。
Negotiation of the transmission mode being described in this section would use SDP similar to the following:
このセクションで説明されている送信モードの交渉は、以下と同様にSDPを使用します。
m=audio 12343 RTP/AVP 99 100 101
a=rtpmap:99 red/8000/1
a=fmtp:99 100/101/101/101
a=rtpmap:100 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
This indicates one media stream, with G.711 (i.e., voice or voice-band data) as the primary content, along with three blocks of telephone events. RFC 2198 requires that the more voluminous representation (i.e., the G.711) be the primary one. The most recent block of events covers the same time period as the voice-band data. The other two streams provide the first and second retransmissions of the events as in the previous example. Because G.711 is the primary content, the M bit for the packets will in general not be set, except after periods of silence.
これは、1つのメディアストリームを示しており、G.711（つまり、音声または音声バンドデータ）がプライマリコンテンツとして、3つのブロックの電話イベントを示しています。RFC 2198では、より膨大な表現（つまり、G.711）が主要な表現であることが必要です。イベントの最新のブロックは、音声バンドデータと同じ期間をカバーしています。他の2つのストリームは、前の例のように、イベントの最初と2番目の再送信を提供します。G.711は主要なコンテンツであるため、沈黙の期間後を除き、パケットのMビットは一般に設定されません。
Figure 2 shows the detailed packet content for the same sample point as in the previous figure, but including the G.711 content.
図2は、前の図と同じサンプルポイントの詳細なパケットコンテンツを示していますが、G.711コンテンツを含みます。
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=0 |0| PT=99 | sequence number = seq0 + 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp = ts0 + 13280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 720 | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 267 | block length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 0 | block length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=100| (begin block for /ANSam ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
/ANSAMブロック（2回目の再送信）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel) (first retransmission)
jmの最初の7ビット（= "1111111" in v.21ハイチャネル）（最初の再送信）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel) (new content)
次の9ビットのjm（= "111000000" in v.21ハイチャネル）（新しいコンテンツ）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30 ms of G.711-encoded voice-band data (240 samples)
30ミリ秒のG.711エンコードされた音声バンドデータ（240サンプル）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 1 | Sample 2 | Sample 3 | Sample 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 237 | Sample 238 | Sample 239 | Sample 240 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Packet Contents with Voice-Band Data Combined with Events
図2：イベントと組み合わせたボイスバンドデータを備えたパケットコンテンツ
The V.21 bit events defined in this document may be used to transmit user-sensitive data. This could include initial log-on sequences and application-level protocol exchanges as well as user content. As a result, such a usage of V.21 bit events entails, in the terminology of [16], threats to both communications and system security. The attacks of concern are:
このドキュメントで定義されているV.21ビットイベントは、ユーザーに敏感なデータを送信するために使用できます。これには、初期ログオンシーケンスとアプリケーションレベルのプロトコル交換、およびユーザーコンテンツが含まれます。その結果、[16]の用語では、V.21ビットイベントのこのような使用には、通信とシステムのセキュリティの両方に対する脅威が必要です。懸念の攻撃は次のとおりです。
o confidentiality violations and password sniffing;
o 機密性違反とパスワードのスニッフィング。
o hijacking of data sessions through message insertion;
o メッセージ挿入によるデータセッションのハイジャック。
o modification of the transmitted content through man-in-the-middle attacks;
o 中間の攻撃による送信コンテンツの変更。
o denial of service by means of message insertion, deletion, and modification aimed at interference with the application protocol.
o アプリケーションプロトコルへの干渉を目的としたメッセージ挿入、削除、および変更によるサービスの拒否。
To prevent these attacks, the transmission of V.21 bit events MUST be given confidentiality protection. Message authentication and the protection of message integrity MUST also be provided. These address the threats posed by message insertion and modification. With these measures in place, RTP sequence numbers and the redundancy provided by the RFC 4733 procedures for transmission of events add protection against and some resiliency in the face of message deletion.
The other events defined in this document (and V.21 bit events within control sequences) are used only for the setup and control of sessions between data terminals or fax devices. While disclosure of these events would not expose user-sensitive data, it can potentially expose capabilities of the user equipment that could be exploited by attacks in the PSTN domain. Thus, confidentiality protection SHOULD be provided. The primary threat is denial of service, through injection of inappropriate signals at vulnerable points in the control sequence or through alteration or blocking of enough event packets to disrupt that sequence. To meet the injection threat, message authentication and integrity protection MUST be provided.
このドキュメントで定義されている他のイベント（および制御シーケンス内のV.21ビットイベント）は、データ端子またはFAXデバイス間のセッションのセットアップと制御にのみ使用されます。これらのイベントの開示はユーザーに敏感なデータを公開しませんが、PSTNドメインの攻撃によって悪用される可能性のあるユーザー機器の機能を潜在的に公開する可能性があります。したがって、機密保護を提供する必要があります。主な脅威は、制御シーケンスの脆弱なポイントでの不適切な信号を注入すること、またはそのシーケンスを破壊するのに十分なイベントパケットの変更またはブロッキングを通じて、サービスの拒否です。インジェクションの脅威を満たすには、メッセージ認証と整合性の保護を提供する必要があります。
The Secure Real-time Transport Protocol (SRTP) [3] meets the requirements for protection of confidentiality, message integrity, and message authentication described above. It SHOULD therefore be used to protect media streams containing the events described in this document.
安全なリアルタイムトランスポートプロトコル（SRTP）[3]は、上記の機密性、メッセージの整合性、およびメッセージ認証の保護の要件を満たしています。したがって、このドキュメントに記載されているイベントを含むメディアストリームを保護するために使用する必要があります。
Note that the appropriate method of key distribution for SRTP may vary with the specific application.
SRTPの重要な分布の適切な方法は、特定のアプリケーションによって異なる場合があることに注意してください。
In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP.
一部の展開では、SRTPが提供するものと同等の保護を提供するために、他の手段を使用することが望ましい場合があります。
This document adds the events in Table 10 to the registry established by RFC 4733 [5].
このドキュメントは、表10のイベントをRFC 4733 [5]によって確立されたレジストリに追加します。
+-------+--------------------------------------------+--------------+
| Event | Event Name | Reference |
| Code | | |
+-------+--------------------------------------------+--------------+
| 23 | CRdSeg: second segment of V.8 bis CRd | RFC 4734 |
| | signal | |
| | | |
| 24 | CReSeg: second segment of V.8 bis CRe | RFC 4734 |
| | signal | |
| | | |
| 25 | MRdSeg: second segment of V.8 bis MRd | RFC 4734 |
| | signal | |
| | | |
| 26 | MReSeg: second segment of V.8 bis MRe | RFC 4734 |
| | signal | |
| | | |
| 27 | V32AC: A pattern of bits modulated at 4800 | RFC 4734 |
| | bits/s, emitted by a V.32/V.32bis | |
| | answering terminal upon detection of the | |
| | AA pattern. | |
| | | |
| 28 | V8bISeg: first segment of initiating V.8 | RFC 4734 |
| | bis signal | |
| | | |
| 29 | V8bRSeg: first segment of responding V.8 | RFC 4734 |
| | bis signal | |
| | | |
| 30 | V21L300: 300 bits/s low channel V.21 | RFC 4734 |
| | indication | |
| | | |
| 31 | V21H300: 300 bits/s high channel V.21 | RFC 4734 |
| | indication | |
| | | |
| 32 | ANS (V.25 Answer tone). Also known as CED | RFC 4734 |
| | (T.30 Called tone). | |
| | | |
| 33 | /ANS (V.25 Answer tone after phase shift). | RFC 4734 |
| | Also known as /CED (T.30 Called tone after | |
| | phase shift) | |
| | | |
| 34 | ANSam (V.8 amplitude modified Answer tone) | RFC 4734 |
| | | |
| 35 | /ANSam (V.8 amplitude modified Answer tone | RFC 4734 |
| | after phase shift) | |
| | | |
| 36 | CNG (T.30 Calling tone) | RFC 4734 |
| | | |
| 37 | V.21 channel 1 (low channel), '0' bit | RFC 4734 |
| | | |
| 38 | V.21 channel 1, '1' bit. Also used for | RFC 4734 |
| | ESiSeg (second segment of V.8 bis ESi | |
| | signal). | |
| | | |
| 39 | V.21 channel 2, '0' bit | RFC 4734 |
| | | |
| 40 | V.21 channel 2, '1' bit. Also used for | RFC 4734 |
| | ESrSeg (second segment of V.8 bis ESr | |
| | signal). | |
| | | |
| 49 | CT (V.25 Calling Tone) | RFC 4734 |
| | | |
| 52 | ANS2225: 2225-Hz indication for text | RFC 4734 |
| | telephony | |
| | | |
| 53 | CI (V.8 Call Indicator signal preamble) | RFC 4734 |
| | | |
| 54 | V.21 preamble flag (T.30) | RFC 4734 |
| | | |
| 55 | V21L110: 110 bits/s V.21 indication for | RFC 4734 |
| | text telephony | |
| | | |
| 56 | B103L300: Bell 103 low channel indication | RFC 4734 |
| | for text telephony | |
| | | |
| 57 | V23Main: V.23 main channel indication for | RFC 4734 |
| | text telephony | |
| | | |
| 58 | V23Back: V.23 back channel indication for | RFC 4734 |
| | text telephony | |
| | | |
| 59 | Baud4545: 45.45 bits/s Baudot indication | RFC 4734 |
| | for text telephony | |
| | | |
| 60 | Baud50: 50 bits/s Baudot indication for | RFC 4734 |
| | text telephony | |
| | | |
| 61 | VBDGen: Tone patterns indicative of use of | RFC 4734 |
| | an unidentified modem type | |
| | | |
| 62 | XCIMark: A pattern of bits modulated in | RFC 4734 |
| | the V.23 main channel, emitted by a V.18 | |
| | calling terminal. | |
| | | |
| 63 | V32AA: A pattern of bits modulated at 4800 | RFC 4734 |
| | bits/s, emitted by a V.32/V.23bis calling | |
| | terminal. | |
+-------+--------------------------------------------+--------------+
Table 10: Data-Related Additions to RFC 4733 Telephony Event Registry
表10：RFC 4733テレフォニーイベントレジストリへのデータ関連の追加
Scott Petrack was the original author of RFC 2833. Henning Schulzrinne later loaned his expertise to complete the document, but Scott must be credited with the energy behind the idea of a compact encoding of tones over IP.
スコット・ペトラックはRFC 2833の元の著者でした。ヘニング・シュルツリンヌは後に文書を完成させるために彼の専門知識を貸しましたが、スコットはIPよりもトーンのコンパクトなエンコードのアイデアの背後にあるエネルギーを認めなければなりません。
Gunnar Hellstrom and Keith Chu provided particularly useful comments helping to shape the present document. Amiram Allouche and Ido Benda drew the authors' attention to the value of including events for V.32/V.32bis in the document, and Yaakov Stein confirmed details of operation of this modem.
Gunnar HellstromとKeith Chuは、現在の文書の形成に役立つ特に有用なコメントを提供しました。Amiram AlloucheとIdo Bendaは、文書にV.32/V.32bisのイベントを含めることの価値に著者の注意を引き、Yaakov Steinはこのモデムの操作の詳細を確認しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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.
[2] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTP Payload for Redundant Audioデータ」、RFC 2198、1997年9月。
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[3] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[4] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[5] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[5] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 4733、2006年12月。
[6] International Telecommunication Union, "Echo suppressors", ITU-T Recommendation G.164, November 1988.
[6] 国際電気通信連合、「エコーサプレッサー」、ITU-T推奨G.164、1988年11月。
[7] International Telecommunication Union, "Echo cancellers", ITU-T Recommendation G.165, March 1993.
[7] 国際電気通信連合、「エコーキャンセラー」、ITU-Tの推奨G.165、1993年3月。
[8] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, July 2003.
[8] 国際電気通信ユニオン、「一般的な切り替えの電話網における文書ファクシミリ送信の手順」、ITU-T勧告T.30、2003年7月。
[9] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000.
[9] 国際電気通信ユニオン、「公共の切り替えた電話網を介したデータ送信のセッションを開始する手順」、ITU-T勧告v.8、2000年11月。
[10] 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", ITU-T Recommendation V.8 bis, November 2000.
[10]
[11] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000.
[11] 国際電気通信ユニオン、「テキスト電話モードで動作するDCESの運用およびインターワーキング要件」、ITU-T推奨v.18、2000年11月。
See also Recommendation V.18 Amendment 1, Nov. 2002.
2002年11月、推奨v.18修正1も参照してください。
[12] International Telecommunication Union, "300 bits per second duplex modem standardized for use in the general switched telephone network", ITU-T Recommendation V.21, November 1988.
[12] 国際電気通信ユニオン、「一般的な切り替えの電話ネットワークで使用するために標準化された1秒あたり300ビットモデム」、ITU-T推奨V.21、1988年11月。
[13] 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", ITU-T Recommendation V.25, October 1996.
[13] International Telecommunication Union、「手動および自動的に確立されたコールの両方のエコー制御デバイスの無効化手順を含む、一般的な切り替え型電話ネットワーク上の自動留守装置の自動応答機器および一般的な手順」、ITU-T推奨V.25、1996年10月。
See also Corrigendum 1 to Recommendation V.25, Jul. 2001.
Corrigendum 1から推奨V.25、2001年7月も参照してください。
[14] International Telecommunication Union, "A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use on the general switched telephone network and on leased telephone-type circuits", ITU-T Recommendation V.32, March 1993.
[14] International Telecommunication Union、「一般的な切り替えの電話ネットワークおよびリースした電話型回路で使用するために、最大9600ビット/sのデータシグナリングレートで動作する2線のファミリー、二重モデムのファミリー」、ITU-Tの推奨v.32、1993年3月。
[15] International Telecommunication Union, "A duplex modem operating at data signalling rates of up to 14 400 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits", ITU-T Recommendation V.32bis, February 1991.
[15] International Telecommunication Union、「一般的な切り替えの電話ネットワークおよびリースしたポイントツーポイント2線電話タイプ回路で使用するための最大14 400ビット/sのデータシグナル伝達レートで動作する二重モデム」、ITU-Tの推奨v.32bis、1991年2月。
[16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[16] Rescorla、E。and B. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[17] Kreuter、R。、「64 Kbit/s透明コールのRTPペイロード形式」、RFC 4040、2005年4月。
[18] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[18] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
[19] 国際電気通信ユニオン、「音声周波数のパルスコード変調（PCM）」、ITU-T推奨G.711、1988年11月。
[20] International Telecommunication Union, "Terminal for low bit-rate multimedia communication", ITU-T Recommendation H.324, March 2002.
[20] International Telecommunication Union、「BITレートの低いマルチメディア通信のためのターミナル」、ITU-T推奨H.324、2002年3月。
[21] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
[21] International Telecommunication Union、「IPネットワーク上のリアルタイムグループ3ファクシミリ通信の手順」、ITU-T推奨T.38、2003年7月。
[22] International Telecommunication Union, "International interworking for videotex services", ITU-T Recommendation T.101, November 1994.
[22] 国際電気通信ユニオン、「VideoTex Servicesのための国際的なインターワーキング」、ITU-T勧告T.101、1994年11月。
[23] International Telecommunication Union, "Data protocols for multimedia conferencing", ITU-T Recommendation T.120, July 1996.
[23] 国際電気通信ユニオン、「マルチメディア会議のためのデータプロトコル」、ITU-T推奨T.120、1996年7月。
[24] International Telecommunication Union, "A 2-wire modem for facsimile applications with rates up to 14 400 bit/s", ITU-T Recommendation V.17, February 1991.
[24] International Telecommunication Union、「最大14 400ビット/sのレートのファクシミリアプリケーション用の2線式モデム」、ITU-T推奨V.17、1991年2月。
[25] International Telecommunication Union, "600/1200-baud modem standardized for use in the general switched telephone network", ITU-T Recommendation V.23, November 1988.
[25] 国際電気通信ユニオン、「一般的な切り替えの電話ネットワークで使用するために標準化された600/1200-ボーモデム」、ITU-T推奨v.23、1988年11月。
[26] International Telecommunication Union, "4800/2400 bits per second modem standardized for use in the general switched telephone network", ITU-T Recommendation V.27ter, November 1988.
[26] 国際電気通信ユニオン、「一般的な切り替えの電話網で使用するために標準化された4800/2400モデムあたりのビット」、ITU-T勧告v.27ter、1988年11月。
[27] International Telecommunication Union, "9600 bits per second modem standardized for use on point-to-point 4-wire leased telephone-type circuits", ITU-T Recommendation V.29, November 1988.
[27] 国際電気通信ユニオン、「ポイントツーポイント4ワイヤリースの電話タイプ回路での使用のために標準化された9600ビットあたり9600ビット」、ITU-T推奨V.29、1988年11月。
[28] International Telecommunication Union, "A modem operating at data signalling 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", ITU-T Recommendation V.34, February 1998.
[28] International Telecommunication Union、「一般的な切り替えの電話ネットワークおよびリースしたポイントツーポイント2線電話タイプの回路で使用するために、最大33 600ビット/sのデータシグナル伝達率で動作するモデムA」、ITU-Tの推奨v.34、1998年2月。
[29] International Telecommunication Union, "A digital modem and analogue modem pair for use on the Public Switched Telephone Network (PSTN) at data signalling rates of up to 56 000 bit/s downstream and up to 33 600 bit/s upstream", ITU-T Recommendation V.90, September 1998.
[29] International Telecommunication Union、「最大56 000ビット/s下流、最大33 600ビット/sアップストリームのデータシグナリングレートで公開された電話ネットワーク（PSTN）で使用するデジタルモデムおよびアナログモデムペア」、ITU-T推奨v.90、1998年9月。
[30] International Telecommunication Union, "A digital modem operating at data signalling rates of up to 64 000 bit/s for use on a 4-wire circuit switched connection and on leased point-to-point 4-wire digital circuits", ITU-T Recommendation V.91, May 1999.
[30] International Telecommunication Union、「4線回路スイッチ付き接続およびリースポイントツーポイント4線デジタルサーキットで使用するために、最大64 000ビット/sのデータシグナリングレートで動作するデジタルモデム」、ITU-Tの推奨v.91、1999年5月。
[31] International Telecommunication Union, "Enhancements to Recommendation V.90", ITU-T Recommendation V.92, November 2000.
[31] 国際電気通信ユニオン、「推奨V.90の強化」、ITU-T勧告v.92、2000年11月。
[32] International Telecommunication Union, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs", ITU-T Recommendation V.150.1, January 2003.
[32] International Telecommunication Union、「モデムオーバーIPネットワーク：VシリーズDCEのエンドツーエンド接続の手順」、ITU-T推奨V.150.1、2003年1月。
[33] International Telecommunication Union, "Procedures for supporting voice-band data over IP networks", ITU-T Recommendation V.152, January 2005.
[33] 国際電気通信連合、「IPネットワーク上の音声帯域データをサポートする手順」、ITU-T推奨v.152、2005年1月。
[34] Telecommunications Industry Association, "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network", ANSI TIA- 825-A-2003, April 2003.
[34] Telecommunications Industry Association、「公共の切り替えた電話ネットワークで使用するための周波数シフトキー付きモデム」、ANSI TIA-825-A-2003、2003年4月。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US
ヘニングシュルツリンコロンビアU.コンピュータサイエンスコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
トム・テイラー・ノーテル1852オンタリオ州K1H 6Z8カナダ、ロレイン・アヴェ・オタワ
EMail: taylor@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。