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).
著作権（C）IETFトラスト（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.
テレフォニーイベントRTPペイロードで運ばれたときにこのメモの更新RFC 4733は、モデム、ファックス、およびテキスト電話信号のためのイベントコードを追加します。これは、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].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [1] RFC 2119に記載されるように解釈されるべきです。
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公衆は（回路）交換電話網
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勧告に対応する、いくつかのグループに編成されています。彼らの目的は、ネゴシエーションをサポートし、ファックス、モデム、または動作モード間のテキストテレフォニーセッションやトランジションのテイクダウンアップを開始することです。実際のファックス、モデム、およびITU-T RECの定式化としてテキストペイロードは、典型的には、他のペイロードタイプによって（例えば、V.150.1 [32]モデムリレー、音声帯域データを運ばれる。V.152 [33]、クリアモード[17 】文字モードテキストのデジタルデータ、ファックス、またはRFC 4103のためのT.38 [21] [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のセクション2.4.1 [5]インプリメンテーションは、処理するために調製されるイベントを示すために、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ミリ秒」の沈黙期間は問題ではありません。
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-T勧告G.164 [6]）とエコーキャンセラ（ITU-T勧告G.165 [7]）。これらのデバイスは、ライン上の無信号のわずか100 msの後に再起動してもよいです。その結果、エコーサプレッサやセラが仕事へのシグナリングのために無効にする必要がありますどのような状況では、トーン・イベントは、これらのデバイスは再度有効になっていないことを確実にするために十分迅速に報告しなければなりません。
2. Definitions of Events for Control of Data, Fax, and Text Telephony Sessions
2.データ、ファックスのコントロールのイベントの定義、およびテキストテレフォニーセッション
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ビス[10]互いの能力を確立するために、通話の起動時に、呼が確立された後の両方で、異なる動作モード間を遷移するように2つのエンドポイントのための一般的な方法です。これは、V.8 [9]（セクション2.3以下）と同じ端子の多くをサポートしているが、より詳細なパラメータネゴシエーションを可能にします。これは、V.8で定義された古いVシリーズモデムのいくつかのサポートを欠いたが、同時または交互音声とデータのための機能を追加し、H.324 [20]マルチリンク、および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ビス能力交渉以下、それらがV.8、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ビスは、「信号」と「メッセージ」を区別します。 ESI / ESR、MRE / MRD、およびCRE / CRD - - 次のいくつかの段落に記載されるように、トーンから成るV.8は、信号がビス。 V.8メッセージビス - 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ビス信号の最初のセグメントを表します。
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ビス戦略は録音中に記載されています。 V.8は、付録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,
第二セグメントは、第一の直後、および100ミリ秒間保持単一のトーンです。使用される周波数は、定義された6つの信号の特定の信号を示しています。 CRdSeg、CReSeg、MRdSeg、MReSeg、：電話イベントペイロードを使用する場合、V.8ビス信号の第2のセグメントは、該当するイベントで表されます。
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.
表1に定義されるようESiSeg、またはESrSegは、ESiSegとESrSeg（表2を参照）は、それぞれ、「1」V.21低および高チャネルとしてのビットを同じ周波数を使用するため、同じイベントコードが割り当てられます。
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は、メッセージがメッセージの内容を転送するシグナリングV.21 [12]周波数シフトを使用ビス。 V.21は、次のセクションで説明されています。 V.8ビスは、イニシエータとレスポンダの上部チャネルに割り当てられた下側チャネルと、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ビスメッセージは、（第2のセグメントうち同じV.21周波数マーキングすることである）、それが直ちにESI又はESRシグナルが先行している場合を除いて周波数マーキング連続V.21の100ミリ秒のプリアンブルが先行します。送信者はESiSegまたはESrSegイベントを使用して、このプリアンブルトーンを報告してはなりません。これらはV.8は、彼らが関連する信号をビスでのみ使用されるべきです。
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.
これを綴り、トーンをマーキング連続V.21直後のV8bISegとV8bRSegは、それぞれ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ビスメッセージのために定義されていませんが、簡単な説明は、次のされています。
o the V.8 bis CL message describes the sending terminal's capabilities;
O V.8は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はオクテットのシーケンスとして編成されています。最初の2〜5のオクテットはHDLCフラグ（0x7Eに）です。次に、ビットマップの形でゼロ以上の情報フィールドパラメータに続くメッセージタイプ識別子（4ビット）、V.8ビスバージョン識別子（4ビット）、識別情報のゼロから2以上のオクテットを、来ます。個々のビットマップの長さは1〜5個のオクテットです。非標準情報の最大64個のオクテットが存在していてもよいです。情報フィールドは、チェックサムと一から三のHDLCフラグが続いています。なぜなら、任意の1つの情報フィールドの大きさの制限のため、V.8ビスセグメンテーション手順を定義します。過剰データは、追加のメッセージで、のみ受信端から促す後に送信されます。
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.21ビットイベントを使用して、V.8は、ビットの配列の形でメッセージを転送することができるビス電話イベントペイロードを使用してシグナリングビスV.8を支持します。最初の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).
伝送はまた、撮影の手順に従って追加の余分な「0」ビットを含まなければなりません。 V.8ビス、節7.2.8には、受信機でHDLCフラグの誤認識を防止します。実装者はこれらの余分な「0」ビットはオクテットの偶数倍に出て来ることはありませんワイヤ上で送信されるとして、一般的V.8でメッセージをビスことを意味していることに注意してください。実装を送信する情報の正確に1オクテットプラスそのオクテットに挿入された余分な「0」ビットを含むようにパケット化間隔を変更することを選択するかもしれません。得られた変動は、（下記参照）受信機にパケットの配信におけるネットワーク遅延を防ぐために必要なバッファリングの量と比べて微々たるものであろう。
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ビットを報告するための一つの理由は、それはまた、音声帯域データなどの他の手段によって実施される場合、対応するコンテンツと一致することです。
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ビスとV.21信号の電力レベルは、国家規制の対象となっています。したがって、ボリュームが送信者が指定する必要のあるトーンなどのイベントビスV.8をモデル化するために適しているようです。受信機は前方送信のためのオーディオコンテンツとしてV.8ビストーンをレンダリングしている場合、受信機は、イベントレポートに含まれているボリュームを使用したり、ボリュームが下流の国民の要求に合致するように変更することができます。
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ビスに対して定義されたイベントコードをまとめたものです。個々のイベントは、次の表で説明されています。各イベントはトーンセグメントの先頭が検出されたときに始まり、音がもはや検出されたときに終了します。
+---------+-------------+-----------+------------+------+---------+
| 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ビス信号用のイベント
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.
開始V.8ビスの第2セグメントは、シグナル（ESI）をエスケープ。完全なESI信号はESiSeg続いV8bISegイベントによって表されます。 ESIは、同じ端末からMS、CL、またはCLRメッセージが続くであろう。 1.5-S無音区間は、ネットワークエコーサプレッサーを収容するために、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.
信号（ESR）をエスケープ応答ビスV.8の第2のセグメント。完全なESR信号はESrSeg続いV8bRSegイベントによって表されます。 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の第2のセグメントは、機能要求信号（CRD）をビス。 CRD信号の最初のセグメントは、文脈に応じて、V8bISeg又はV8bRSegいずれかによって表されます。もう一方の端には、機能リスト（CLまたはCLRメッセージ）を返します。
CReSeg:
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の第2のセグメントは、自動応答端末によって開始された機能要求信号（CRE）をビス。完全なCRE信号がCReSeg続いV8bISegイベントによって表されます。発呼端末は、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ビスモード要求信号（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ビスモード要求信号（MRE）の第2セグメント。完全なMRE信号はMReSeg続いV8bISegイベントによって表されます。発呼端末は、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.
ESI、CRD、CRE、MRD、又はMREのものであってもよい開始V.8ビス信号の最初のセグメント。
V8bRSeg:
V8bRSeg：
The first segment of a responding V.8 bis signal, which may be one of ESr, CRd, or MRd.
ESR、CRD、またはMRDのものであってもよい応答V.8ビス信号の最初のセグメント。
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は実装が輻輳発生するパケットの遅延によるプレイアウト時間のギャップや拡張を容認する可能性は低いビス。最低でも、現在のトランザクションは、再生中にこれらの欠陥が発生したときにリセットしやすくなります。その結果、再生バッファの慎重な管理が可能失われた又は遅れたパケットの顔にロバスト性を高めるために受信機において必要とされます。再生アルゴリズムは、イベントの再生は、イベントの名目上の期間を超えることがないようなものでなければなりません。
V.8 bis does not appear to offer opportunities for dynamic adaptation to congestion through manipulation of the packetization interval.
V.8ビスは、パケット化間隔を操作して渋滞に動的に適応のための機会を提供するためには表示されません。
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ビット/秒の最大速度でのデータ伝送を提供するモデムプロトコルです。 2つのチャネルが必要な場合は全二重データ伝送をサポートして、定義されています。低いチャネルは、周波数「1」（マーク）が980ヘルツと「0」（スペース）のために1180ヘルツを使用します。高いチャネル周波数「1」1650ヘルツと「0」の1850ヘルツを使用します。モデムは、同期または非同期で動作することができます。
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ビス、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ビスメッセージの前に使用V.21マーク周波数で100ミリ秒のトレーニング信号の場合のように、すぐには不可能です。シングル長い期間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のセクション2.5.1.5の手順を使用して、1つのパケットに複数のイベントを詰めるべきである[5]。 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回送信されるため、冗長性を報告し、信頼性を報告ビット当たりではなく、遷移増加あたりイベントを報告する[5]。報告に必要なパケットの数を減らすために、実装は、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ビット/秒の公称速度に一つV.21ビットを送信する時間は、電話イベントペイロードタイプに対するデフォルト8000 Hzのサンプリングレートで3.33ミリ秒、または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イベントを送信する場合、送信ゲートウェイが報告された個々のイベントの継続時間を考慮にそれぞれの初期イベントを取って、次の最初のイベントと重複するために、1つのパケットの最後のイベントを引き起こさないことを保証しなければなりませんタイムスタンプ。これを達成するために、送信側ゲートウェイは、開始時間、イベントの違いの連続のような個々のイベントの持続時間を導出しなければならない（ように、8000 Hzで、すべての3番目のイベントは、期間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ビットイベントの連続したシリーズを報告することを認識した場合、それは彼らの報告間隔と期間中の可能なワンタイムスタンプユニットの不一致にもかかわらず、一定の速度でそれらを果たすべきです。
+--------------------+----------------+------------+------+---------+
| 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に定義されたインジケータイベントのいずれかを使用することを望むかもしれません。実装は、これらのインジケータのイベントと同一のコンテンツについて上記で定義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]マルチメディア、V.18 [11]テキスト、T.101 [22]ビデオテキスト、T.30 [ 8]を送信またはFAXを受信し、V.34 [28]、V.90 [29]、V.91 [30]、およびV.92 [31]を含むVシリーズモデムの長いリスト。 V.8ビス[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ビスと同じ用語を使用しません。コールインジケータ信号（CI）、コールメニュー信号（CM）、CMターミネーター（CJ）、および関節：むしろ、それは300ビット/ sでV.21 [12]によって転送されたビットから成る4つの信号を定義しますメニュー信号（JM）。また、[13] V.25で定義されたトーンを使用してT.30 [8]（後述）、及びV.8自体で定義されトーン（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信号を送信します。それはANSamのトーンを検出するまで時折一時停止を継続、CI、少なくとも3回繰り返されます。 CIは、発呼端末は、H.324、V.18、T.30センド、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のは、ANSamの再生の1秒後に400ミリ秒と任意G.165 [7]エコーキャンセラ後の回路上の任意のG.164 [6]エコー抑制を無効にします。
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).
前記CMの少なくとも二つの同一の配列を検出した後、応答端末は、（それが要求されたものをサポートできない場合、または別の端末タイプを提供する）は、独自の能力を示す、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の少なくとも二つの同一の配列を検出した後、発呼端末は、JM信号を認識するCJを送信し、CMの現在のオクテットを完了する。これは、選択したモードで動作を開始し、その後、正確に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.
それはCJを検出するまで前記応答端末は、JMを送信します。その時点で、それはすぐに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同期ビットの信号依存性パターンに続く10「1」ビットの固定された配列からなる信号です。各オクテットは「0」スタートビットにより先行及び「1」ストップビットが続きます。同期パターンとV.21チャネルの組み合わせは一意のメッセージ・タイプを識別する。 CJ信号は、ストップ＆スタートビットではなく、先行する「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.
アプリケーションは、V.21ビット一連のイベント（セクション2.2）のように、それぞれ、CM、JM、およびCJ信号の各インスタンスを報告すること、またはこの情報を運ぶために、別のペイロードタイプを使用することができます。 CI信号の同期部分を報告すること電話イベントペイロードを使用してV.8シグナリングをサポートするアプリケーション（「続く1の 『10 00000 00001』）の両方それが認識されているV.21ビットイベントのシリーズとして、単一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信号の同期のみの一部を覆っていることに注意してください。残りの通話機能オクテットとその開始およびストップビット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ミリ秒の休止は、それらが後のデータ・ベアリング・ペイロードの再生に電話イベントの再生から変更できるように、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ヘルツ、振幅変調15 Hzでの正弦波によってで正弦波信号から成ります。イベントの開始は、トーンの先頭にあります。イベントの終了は、トーンの終了または（/ ANSamのイベントの始まりをマーキング）位相反転の発生の早期にあります。位相反転は、エコーキャンセルを無効にするために使用されています。それらが適用されている場合、彼らは450ミリ秒の間隔で発生します。
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).
ANSamのイベントとANSイベント（V.25イベントを参照、下記）を区別することが可能になるまでのANSamイベントパケットを送るべきではありません。
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:
/ ANSA：
/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のと同じ物理的な信号を報告するが、その信号中の第1の位相反転以下の報告されています。これは、位相反転で始まり、トーンの終わりで終了します。トーンの終わりに到達するまで/の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.8のCI信号の先頭を示すV.21ビットパターン「11111 11111 00000 00001」の発生を報告します。イベントは、最初のビットの開始時に始まり、最後の1の終わりで終了します。このイベントは、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ミリ秒間隔でスケジュールで発生提供することができます。
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] [9]とV.8ビス[10] V.8より以前起動プロトコルです。 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（呼び出しトーン）が1.5以上秒の期間以上0.5秒の持続時間以上、0.7秒間オンとオフ、1300ヘルツの音の中断バーストの系列から成り、以上2.0秒。 [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
V.25は、具体的にはITU-T勧告によって定義されるようなエコー抑制を無効にする手順を含みます。 G.164 [6]。しかし、G.164エコーサプレッサは、大部分が今持っているがG.165 [7]エコーに置き換えられて
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.
無効化トーンの位相反転を必要とするキャンセラは、（上記のANSamを参照します）。その結果、勧告V.25は、エコーキャンセラが無効にされている場合はANSトーンでその位相反転が必要になると言って、2001年7月に変更されました。
One possible V.25 sequence is as follows:
次のように一つの可能なV.25シーケンスは次のとおりです。
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を停止した後、少なくとも400ミリ秒（1秒以上ANSの位相反転がエコーキャンセラを無効にするために使用されている場合）を待たなければなりません。このトーンは、モデム固有の、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.着信端末は、2.6〜4.0秒のANSを担っているか、それは100ミリ秒のための駅応答を呼び出すことが検出されましたまで。それは沈黙で55-95ミリ秒（公称75ミリ秒）待機します。 ANS終了の理由がなく局応答を呼び出すの検出よりも、タイムアウトした場合は（95ミリ秒の上限が制御自体を再確立することができるエコーする点にかなり近いことに留意されたい。）、被呼端末は再びANSを再生し始めます発呼局が応答するまで、エコー制御の無効化を維持。
The events defined for V.25 signalling are shown in Table 4.
V.25シグナリングのために定義されたイベントを表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:
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のトーンの先頭です。イベントの終了は、トーンの終了または（/ 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イベントと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と同じ物理信号を報告するが、その信号中の第1の位相反転以下の報告されています。これは、位相反転で始まり、トーンの終わりで終了します。トーンの終わりに到達するまでの/ 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ミリ秒間隔で、用/スケジュールでANS相転移を果たさなければなりません。また、送信者が一時的に混雑に遭遇したときのパケット量を減らすためにパケット化間隔を長くするために可能であるように思われます。 1つのリスクは（遡及決定されるような）音の実際の端過去その拡張再生進行であり、受信機は、サイレント公称75ミリ秒の最大継続時間の制約を満たすために追加のプレイアウトバッファリング遅延を課すこと続けることを余儀なくされていますトーン再生後の期間。
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.
ITU-T勧告V.32 [14]直交振幅変更と位相シフトキーイングを使用して、モデムです。これは、2400シンボル/ sで変調された1800 Hzでのキャリア上で動作します。 V.32のための基本的なデータレートは、4800および9600ビット/秒です。 V.32bis [15] 14,400ビット/秒までのデータレートを拡張します。ほとんどまたはすべての既存の展開には、通常、POS端末などのサポートで、V.32bisあります。
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はまだ使用されている一つの理由は、特に専用線の上に、その比較的迅速なスタートアップ・シーケンスです。次のように公衆電話網を介して動作し、起動が始まります。
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。応答端は（エコーキャンセル装置を無効にすることが可能と位相反転して、3.3秒の最大連続ANSトーン続く無音の1.8〜2.5秒）V.25の応答手順で始まります。
b. the calling end waits in silence until it has detected ANS for 1 s;
B。それは1秒間ANSを検出するまで無音で呼び出す端待ちます。
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。発呼側は、V.32 / V.32bisパターン指定AA、4800ビット/秒で送信される「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。少なくとも100ミリ秒のためのAAパターンを検出すると、呼び出されるモデム75の+/- 20msの無音であり、次いで、4800ビット/秒で伝送「0011」ビット系列の系列であるACパターンで応答します。
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は、2つのイベント、V32AAとV32ACを定義します。
+----------------+------------------+------------+------+---------+
| 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:
FAAE：
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.
これら二つの事象のそれぞれは、そのパターンの先頭から始まり、パターンを受信して停止したときに、名目上終了します。セッションがV.150.1モデムリレー[32]またはクリアモードを使用し続けることができるこれらのイベントのいずれかの送信を次の[17]ネゴシエートまたは事前に構成されています。可能な限り迅速に移行を支援するために、V32AAまたはV32ACイベントはすぐに対応するパターンが検出されたと報告されるべきである（SHOULD）。これは、インプリメンテーションは、典型的には、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信号は、発呼端末によって送信されます。上で0.5秒、3秒オフ：これはバーストで再生純粋1100 Hzのトーンです。これは、タイムアウトするまで、または発呼端末が応答を検出するまで続けます。その主な目的は、呼び出された最後の人間のオペレータは、ファックス端末を呼び出して最後に起動されていることを知らせることです。
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ミリ秒の無音で待機します。それがV.8機能を持っている場合は、その後（V.25 ANSに物理的に同一である）CEDトーン、または他の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ネゴシエーションフェーズにおいて端末は300ビット/秒で、V.21信号、高いチャネル周波数のみを使用してバイナリメッセージを交換します。各メッセージはHDLCフラグオクテットの完全なる1秒（公称）プリアンブル（0x7Eを）によって先行されます。このフラグは、次のメッセージのエコー制御機器を製造する機能を有しています。
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.
送信他端がファックスコンテンツを受信する準備をすることを要求で使用されるオプションを示すために、送信端末によって送信されたコマンドメッセージ。それは呼び出し側からDTCに応じて送信し、またはと呼ばれる年末までにするかどうかこれは、呼び出し終了によって送られます。また、送信端末によって送信されたトレーニング信号、が続いています。
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ビスのように、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ビットイベントと、一連の各メッセージの前にプリアンブルを報告することができます。プリアンブル以下T.30制御メッセージは、V.21ビットイベントまたはいくつかの他のペイロードタイプを使用してのシーケンスの形で報告することができます。ビットイベントとして送信した場合、送信される情報は、メッセージの完全な内容を含める必要があります最初のHDLCフラグ、情報フィールド、チェックサム、終端HDLCフラグ、及び余分の「0」ビットはHDLCフラグの誤認識を防止するために添加しました受信側で。実装者はこれらの余分な「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
表6：T.30信号用のイベント
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のトーンの先頭です。イベントの終了は、トーンの終了または（/ 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と同じ物理的な信号を報告するが、その信号中の第1の位相反転以下の報告されています。これは、位相反転で始まり、トーンの終わりで終了します。トーンの終わりに達するまで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.
モデムの含有量は、主に、別のペイロードタイプを使用して送信されているときV.21プリアンブルフラグイベントは最も有用であろうことが予想されます。イベントは、受信モードをファックスに遷移する自身を準備することができ、その内容の解説として作用します。
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ビスと同様に、意味します。
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ボドー[34]、名目周波数1800ヘルツ=で45.45または50ビット/秒で動作するコード5ビットキャラクタ「0」1400ヘルツ=「1」;
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 V.21 [12]であるEDTは、半二重モード（のみ下部チャネル）で110ビット/秒で動作します。文字は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;
、「0」下部チャネル1070ヘルツ= 1270ヘルツ=「1」; V.21と構造的に類似しているが、異なる周波数を使用する（勧告V.18付属書Dに記載）ベル103モードは、O上部チャネル2025ヘルツ= '0'、2225ヘルツ= '1';文字は、米国ではASCII 1スタートビット、1末尾のパリティビット、および1ストップビットに囲まれています。
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);
ミニテルとPrestelバージョンのO V.23 [25]ベースのビデオテックス、。 V.23は、600ビット/秒（1700ヘルツ= '0'、1300ヘルツ=「にそうでないと（ '1' = '0' = 1300ヘルツを2100ヘルツ）可能であれば1200ビット/秒で動作する順方向チャネルを提供し、または1 「）、及び（連続390 Hzで送信される75ビット/ sの後方チャネル」、 『0』場合を除いて）1のを（450 Hz）で送信されます。
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.
300ビット/ sでV.21 [12]を使用して、非V.18テキスト端末O。文字は、スタートビット、パリティ、ストップビット1と（例えば、米国ASCII）7ビットの国家です。
+----------+-----------+----------------+---------+-------+---------+
| 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:
Ansaaakh：
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:
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ビット/秒および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ビット/秒および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.
送信者が300ビット/ sで上部チャネルで動作V.21変調を検出したことを示しています。実装は、このイベントと同じ内容のため、個々のV.21ビットの両方のイベントを送信しないことが期待されます。
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.
送信デバイスが高速チャネルで動作V.23変調を検出したことを示しています。以下に説明するように、このインジケータはXCIMark表示と交互してもよいです。
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ビット/秒で動作ボドー変調を検出したことを示しています。
Baud50:
Baud50：
indicates that the sending device has detected Baudot modulation operating at 50 bits/s.
送信装置は、50ビット/秒で動作ボドー変調を検出したことを示しています。
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ビット/秒、で送信チャンネル "マーク"（1300ヘルツ）。
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]音声帯域データが送信されていることをすべての場合に想定されます。これを行うための自然な方法は、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.
他の指標の全てについて、送信者は、すぐにオーディオコンテンツの性質が認識されているように、初期イベントレポートを生成する必要があります。信頼性については、初期イベントレポートは、短い間隔で二回再送されるべきです。 （関連したメディアのパケット化期間は十分かもしれないが、20ミリ秒は、推奨値である。）受信機がのタイプに自分自身を調整した後、送信者が、これらはほとんど価値を有するが、同一のインジケータイベントの追加レポートを送信し続けるMAYそれが受信されたコンテンツ。
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.
受信機はさらに、パケットが受信されるまでANS2225イベントを再生し続けることのために、パケットロスや遅延に直面し、それが適切です。他のイベントの場合、問題は最初のイベントレポートの損失ではなく、再生の継続性の維持です。既に上記で与えられたこれらの他のイベントの再送信についてのアドバイスは、輻輳によるパケットロスや遅延に対処するのに十分です。
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.
ITU-T勧告V.18 [11]、おそらく声と組み合わせて、テキストの会話のための端子を定義しています。 V.18は、従来のテキスト端末の様々な相互運用を意図しているので、その起動シーケンスは、もう一方の端にあるかを判断するために設計された刺激のシリーズで構成することができます。互いに話し二つV.18端末が起動を交渉し、開始によって囲ま7ビット文字を担持する300ビット/ sでV.21と物理レベルで継続し、ビットを停止するV.8を使用します。
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が応答し、DCEでV.18機能の検出を可能にするV.23端子を刺激する高域V.23変調で送信される信号です。 3秒XCI信号はXCIMarkパターンと交互に「マーク」（すなわち1300ヘルツ）の周期を持つ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.
前節の指標と同様に、送信者は、すぐにオーディオコンテンツの性質が認識されているように、初期イベントレポートを生成する必要があります。信頼性については、初期イベントレポートは、短い間隔で二回再送されるべきです。 （関連したメディアのパケット化期間は十分かもしれないが、20ミリ秒は、推奨値である。）受信機は、コンテンツの種類に自分自身を調整した後、送信者が、これらはほとんど価値を有するが、VBDGenイベントの追加レポートを送信し続けるMAYそれが受信されます。
+--------+---------------+------------+-----------+-------+---------+
| 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の枠組みの中で、これはゲートウェイが[17電位ペイロード（音声、電話イベント、トーン、音声帯域データ、T.38ファックス[21]、および場合によってはRFC 4103 [18]テキストとクリアモードを交渉しなければならないことを意味します別々のペイロードタイプなど]オクテットストリーム）。ビューのタイミングの観点から、これは最も簡単に通話の開始時に行われますが、ゲートウェイでのリソースの過剰割り当てに介在するネットワークにつながります。
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.
一つの選択肢は、帯域外の信号がセッションに適用される新しいペイロードタイプに更新するように交換されている間の時間を購入するという名前のイベントを使用することです。この文書で定義されたイベントのおかげで、これはV.8、V.8ビス、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.
指定されたデータに関連するイベントは、データ信号は、比較的一般的な形式で受信された場合、ゲートウェイは、それらの動作を最適化することを可能にします。一例では、G.711ペイロードに送信される音声帯域データが高速モデムから来る従ってエコーキャンセラの無効化が必要と推論するV.8関連のイベントを使用することです。
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のサブセクションで説明した制御手順の全ては、最終的にデータ内容に道を譲ります。上述したように、このコンテンツは、他のペイロードタイプによって実施されます。受信ゲートウェイは、それぞれのアプリケーションに関連付けられた時間制約内で他のペイロードタイプに切り替えるように準備されなければなりません。さらにいくつかのケースでは（V.8ビス[10]、T.30 [8]）、（上記の文書化された手順のいくつかのために、送信者は、75個の初期制御シグナリングとの間の無音のMSとデータコンテンツの送信を。与えます）コールが確立された後、制御シグナリングが発生する可能性があります。
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:
このセクションでは、基本的なシナリオが二重V.34モデム動作の起動順序である第2節で定義されたイベントコードの使用例を示します。初期V.8シーケンスが完了すると、ゲートウェイはモデム信号を送信するG.711符号化を使用して、音声帯域データ動作に入ることが想定されます。基本的なパケットシーケンスは、次に、イベント送信戦略上の2つの変異体について詳細に示されている表9サンプルパケットで示されています。
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.
イベント、再送イベント、およびRFC 2198の冗長性を使用して、同じコンテンツをカバーする音声帯域データのO同時送信。
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ミリ秒の各ゲートウェイに固定された遅れを想定し（すなわち、パケット間の40ミリ秒の最小値は、受信されたとパケット受信パケットに応答して特異的に送信されます）。 5ミリ秒の伝搬遅延はゲートウェイ間で想定されます。イベントパケット化間隔は特にV.21イベントの30秒、パケット量とバッファリング遅延との間の合理的な妥協点であることが想定されます。
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プロトコルレベルでは、テーブルは、応答モデムは、ANSamの送信を開始するコールの開始から0.2秒（200ミリ秒）待機することを前提としています。呼び出し側のモデムは、それがV.8のCM信号を送信し始めるまでのANSamの受信を開始する時間から1秒（1,000ミリ秒）待機します。両方のモデムは、彼らがV.34モデム信号の送信を開始するまで、それぞれ、CJの送受信、彼らが終了した時点から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. |
| 700.0 |呼ばれるゲートウェイは、その次のスケジュールされたイベントを発行| | |以下のための最初の報告を示すパケットを報告| | | / ANSamの（Mビットのセット、タイムスタンプTS0 + 5360、期間| | | 240タイムスタンプ単位）。 |パケットも運びます| |最初の最終ANSamの報告書の再送信、| | |全期間3600台、Eビットで、この時間| | |セットする。 | | | | | 1295.0 |呼び出し元のゲートウェイは、CM信号の受信を開始| | |呼び出し側のモデムから。 | | | | | 1325.0 |呼び出しゲートウェイが含まれたパケットを送信します| | | CM信号の最初の9ビット。 | | | | | 1445.0 | |呼び出し元のゲートウェイが含まれたパケットを送信します| |最初のCM信号の最後の4ビット、プラス| | |その信号の次の繰り返しの最初の5ビット。 | | | CMビットから送信され続けます| | | |のために、（下記参照）2015.0ミリ秒までのゲートウェイを呼び出します| | 24のパケットの合計。 （最後のパケットも運ぶ| | | CJ信号の始まり。）| | | | | 1596.7 | |と呼ばれるゲートウェイは、最終の再生を完了します| | CM信号の第二の発生のビット。 | | | | | 1636.7 |呼ばれるゲートウェイはANSamの/の終了を検出（および| | | JMの始まり）と呼ばれるモデムから。次へ| | |パケットはまだ出て行くことによるものではありません。 | | | | | 1660.0 |呼ばれるゲートウェイは組み合わせてパケットを送信します| | |最初の7ビットの|（期間533のタイムスタンプユニットEビットセットと合計| |）最終/ ANSamのイベントレポート| | | JM信号の。パケットのためのMビットがセットされています| | | （|今-中止/ ANSamのイベントの| |スタート）、パケットのタイムスタンプは、TS0 + 12560です。 | | | | | 1690.0 |呼ばれるゲートウェイが含まれたパケットを送信します| | | JM信号の次の9ビット。 Mビットがセットされています| | |タイムスタンプはTS0 + 13280（|パケット内のビット| |最初の始まり）です。 JMはであり続けるだろう| | |合計2170.0ミリ（下記参照）まで送信| | | 18のパケットの（最終的に再送信のためのプラス2）。 | | | | | 1938.3 | |呼び出すゲートウェイは、最終の再生を完了します| | JM信号の第二の発生のパケット。 | | | | | 1995.0 |呼び出し元のゲートウェイは、初期の受信を開始| | | CJ信号のビット。 |
| | | | 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. | | | |
| | | | 2015.0 |呼び出しゲートウェイが含まれたパケットを送信します| | | CM信号との第decadの最後の3ビット| | | CJ信号の最初の6ビット。 | | | | | 2095.0 | |呼び出し元のゲートウェイは、CJの最後のビットを受け、 | |信号。 | 75ミリ秒の持続沈黙の期間がから始まります| |呼ばれるエンド。まだ出て送信する時間ではありません| | |イベントレポート。 | | | | | 2105.0 | |呼び出し元のゲートウェイが含まれたパケットを送信します| | CJ信号の最後の6ビット。 | | | | | 2130.0 |呼ばれるゲートウェイは、最後のCJを出し再生が終了| | |それに送られる信号のビット。 | | | | | 2135.0 | |呼び出すゲートウェイは、新しいを含まないパケットを送信します| |イベントが、最後の15ビットの再送信| | | （二世代における）CJ信号。 | | | | | 2165.0 |呼び出し元のゲートウェイはありませんを含むパケットを送信します| | |新しいイベントが、最終的な6ビットの再送信| | | CJ信号の。 | | | | | 2170.0 | |と呼ばれるゲートウェイは、最後のパケットを送信します| | （|再送信| |を除く）JM信号のビットを含みます。 V.8に従っていることに注意してください| | |これらのビットは、一般的な完全でない仕様| | | JM信号やその信号の偶数「オクテット」| | | （彼らはこの例ではそうするように起こるが）。 | | |無音の75ミリ秒の期間と呼ばれる端部で始まります。 | | | | | 2170.0 |呼び出し元のゲートウェイは、V.34の受信を開始| | |呼ばれるモデムからのシグナル伝達。 | | | | | 2175.0 |呼び出し元のゲートウェイは、最後のJMの再生を終了| | |それに送られる信号のビット。 | | | | | 2195.0 |呼び出し元のゲートウェイは、V.34の最初のパケットを送信します| | |音声帯域データ（PCMU）としてシグナリング。 |タイムスタンプは、 | | TS0 + 17360とMビットが示すように設定されて| | |沈黙の後にコンテンツの始まり。パケット| | | 200 8ビットのサンプルを含みます。パケット化間隔| | | 30ミリ秒であり続けとして示されています。それは可能性が| | |以下であることが、より多くしてはならないことを理由でしょう| | |サイレント期間が長すぎます。 | | | |
| 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シナリオのためのイベント
4.1. Simultaneous Transmission of Events and Retransmitted Events Using RFC 2198 Redundancy
4.1. 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 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
M =オーディオ12343 RTP / AVP 99 = rtpmap：99 PCMU / 8000メートル=オーディオ12345 RTP / AVP 100 101 = rtpmap：100赤/ 1分の8000 A =のfmtp：100 101/101/101 = rtpmap：101 101 0-15,32-41,43,46,48-49,52-68：/ 8000 =のfmtp電話-イベント
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つのメディアストリームを示しています。送信者は、第二ストリームの冗長性なしで電話イベントペイロードを送信するための冗長形態は、一次送信モードであるが、RFC 2198のノートとして、それは、も可能です。 （冗長性のない暫定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冗長性の使用を示すだけでなく、イベントレポートの基本的な構成を示す目的のために、（1690.0 MSで呼び出さゲートウェイによって送信された）JM信号ビットを報告する第2のパケットは良い選択であると思われます。このパケットはまた、ANSamの/最後のイベント報告の第二の再送とJM信号の最初の7ビットの最初の再送信を搬送します。それらは、連続する32ビット境界で整列しているかのようにパケットの詳細な内容がより明確世代の内容を参照するに、図1に示され、それらが提示されます。実際に、それらはすべての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)
/ ANSamのブロック（第2の再送）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel)
(first retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ヘッダーなしの単純なイベント・ペイロードとしてそれらを運ぶ電話イベントペイロード仕様に応じて許容されているだろう。後者の利点は、パケットを処理するとき、それはそれらを必要としない限り、受信側ゲートウェイは、再送されたイベントをスキップすることができるということです。
4.2. Simultaneous Transmission of Events and Voice-Band Data Using 2198 Redundancy
4.2. 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
M =オーディオ12343 RTP / AVP 99 100 101 = rtpmap：99赤/ 8000/1（a）=のfmtp：99 100/101/101/101 = rtpmap：100 PCMU / 8000 = rtpmap：101電話イベント/ 8000 =の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.
これは、電話イベントの三つのブロックと共に、一次コンテンツとしてG.711（即ち、音声または音声帯域データ）と、1つのメディアストリームを示しています。 RFC 2198は、より多量の表現（すなわち、G.711）は、一次一つであることを必要とします。イベントの最新のブロックは、音声帯域データと同じ期間をカバーしています。他の二つの流れは、前の例のようにイベントの第一及び第二の再送信を提供します。 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30 ms of G.711-encoded voice-band data (240 samples)
G.711符号化された音声帯域データの30ミリ秒（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ビットイベントは、ユーザの機密データを送信するために使用されてもよいです。これは、初期配列およびアプリケーションレベルのプロトコル交換にログならびにユーザーのコンテンツを含むことができます。結果として、V.21ビットイベントのような使用方法は、[16]の用語で、通信およびシステム・セキュリティの両方に対する脅威を伴います。懸念の攻撃は、次のとおりです。
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 man-in-the-middle攻撃を透過した内容の変更;
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.
これらの攻撃を防ぐために、V.21ビットイベントの送信は機密性保護を与えられなければなりません。メッセージ認証とメッセージの完全性の保護も提供しなければなりません。これらは、メッセージの挿入と変更の脅威に対処します。代わりにこれらの対策では、イベントの送信のためのRFC 4733の手順により提供さRTPシーケンス番号と冗長性を保護し、メッセージの削除の顔にいくつかの弾力性を追加します。
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ビットイベントが）のみデータ端末又はファックス装置間のセッションのセットアップおよび制御のために使用されます。これらの事象の開示は、ユーザーの機密データを公開していないだろうが、それは潜在的に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].
この文書は、RFC 4733 [5]によって確立されたレジストリに表10にイベントを追加します。
+-------+--------------------------------------------+--------------+
| 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 | | | | | |
| 30 | V21L300：300ビット/秒の低いチャンネルV.21 | RFC 4734 | | |表示| | | | | | | 31 | V21H300：300ビット/秒の高いチャネルV.21 | RFC 4734 | | |表示| | | | | | | 32 | ANS（V.25応答音）。また、CEDとして知られています| RFC 4734 | | | （T.30呼び出さトーン）。 | | | | | | | 33 | / ANS（位相シフト後V.25応答音）。 | RFC 4734 | | | |また、/ CED（| | | |位相シフト後のT.30呼び出さトーン）として知られています| | | | | | 34 | ANSamの（V.8振幅修正応答トーン）| RFC 4734 | | | | | | 35 | / ANSamの（V.8振幅改変応答トーン| RFC 4734 | | |位相シフト後）| | | | | | | 36 | CNG（T.30呼び出しトーン）| RFC 4734 | | | | | | 37 | V.21チャネル1（低いチャネル）、 '0' ビット| RFC 4734 | | | | | | 38 | V.21チャンネル1、 '1' ビット。 |また、使用のためにRFC 4734 | | | ESiSeg（V.8ビスESIの第二セグメント| | | |信号）。 | | | | | | | 39 | V.21チャンネル2、 '0' ビット| RFC 4734 | | | | | | 40 | V.21チャネル2、 '1' ビット。 |また、使用のためにRFC 4734 | | | ESrSeg（V.8ビスESRの第二セグメント| | | |信号）。 | | | | | | | 49 | CT（V.25トーンを呼び出します）| RFC 4734 | | | | | | 52 | ANS2225：テキストの2225 Hzで表示| RFC 4734 | | |テレフォニー| | | | | | | 53 | CI（V.8コールインジケータ信号プリアンブル）| RFC 4734 | | | | | | 54 | V.21プリアンブルフラグ（T.30）| RFC 4734 | | | | | | 55 | V21L110：110ビット/秒V.21表示| RFC 4734 | | |テキストテレフォニー| | | | | | | 56 | B103L300：ベル103の低チャンネル表示| RFC 4734 | | |テキスト電話用| | | | | |
| 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.
スコット2000 Petrackとは、RFC 2833ヘニングSchulzrinneとの原作者は、後で文書を完了するために彼の専門知識を貸与されましたが、スコットは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.
グンナー・ヘルストロームとキース・チューは、現在のドキュメントを形作るために貢献し、特に有益なコメントを提供しました。 Amiram Alloucheとイドベンダは、文書内のV.32 / V.32bisのためのイベントを含めての値に作者の注目を集めた、とYaakovのスタインはこのモデムの動作の詳細を確認しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、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.、マグリュー、D.、Naslund、M.、カララ、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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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.テイラーを、 "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]国際電気通信連合を、「データ回路終端機器（のDCE）との間、およびデータ端末装置（のDTE）間の動作の共通モードの識別および選択のための手順は、公衆交換電話網および専用のポイントツーポイントで上電話型回路」、ITU-T勧告V. 8ビス、2000年11月。
[11] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000.
[11]国際電気通信連合、ITU-T勧告V.18、2000年11月「テキスト電話モードで動作{のDCEの運用およびインターワーキング要件」。
See also Recommendation V.18 Amendment 1, Nov. 2002.
また、勧告V.18改正1、2002年11月を参照してください。
[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]国際電気通信連合は、ITU-T勧告V.21、1988年11月「第二の二本鎖あたりの300ビットは、一般的に使用するための標準モデムは、電話網」。
[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]国際電気通信連合は、ITU-T勧告V.25、10月、「自動応答装置や一般の自動呼び出し機器のための一般的な手順は、両方の手動および自動で確立されたコールのためのエコー制御装置を無効にする手順を含む交換電話網」 1996。
See also Corrigendum 1 to Recommendation V.25, Jul. 2001.
、2001年7月勧告V.25に正誤表1も参照してください。
[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]国際電気通信連合、「2線式のファミリー、二重モデムは、一般的に使用するために、最大9600ビット/秒のレートシグナリングデータで動作交換電話網および専用電話型回路に」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]国際電気通信連合、「データは、一般的に使用するために最大14 400ビット/秒の信号速度で動作する二重モデムは、電話網および専用のポイントツーポイント2線電話型回路上」、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.
、BCP 72、RFC 3552、2003年7月[16]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"。
[17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[17] Kreuter、R.、 "64kビット/ sの透明コールのためのRTPペイロードフォーマット"、RFC 4040、2005年4月。
[18] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[18]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
、ITU-T勧告G.711、1988年11月 "音声周波数のパルス符号変調（PCM）" [19]国際電気通信連合、。
[20] International Telecommunication Union, "Terminal for low bit-rate multimedia communication", ITU-T Recommendation H.324, March 2002.
、ITU-T勧告H.324、2002年3月[20]国際電気通信連合、 "低ビットレートマルチメディア通信のための端末"。
[21] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
[21]国際電気通信連合、ITU-T勧告T.38、2003年7月 "IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順"。
[22] International Telecommunication Union, "International interworking for videotex services", ITU-T Recommendation T.101, November 1994.
[22]国際電気通信連合、 "ビデオテックスサービスのための国際インターワーキング"、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]国際電気通信連合、ITU-T勧告V.17、1991年2月「14 400ビット/秒までの速度でファクシミリアプリケーション用の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]国際電気通信連合、1988年11月、ITU-T勧告V.23「一般的に使用するために標準化1200分の600ボーモデム交換電話網」。
[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]国際電気通信連合は、ITU-T勧告V.27ter、1988年11月「一般的に使用するための標準化秒モデムあたり2400分の4800ビット交換電話網」。
[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]国際電気通信連合、ITU-T勧告V.29、1988年11月、「ポイント・ツー・ポイント4線式で使用するために標準化秒モデムあたり9600ビットは、電話タイプの回路をリース」。
[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]国際電気通信連合、「一般的に使用するための最大33 600ビット/ sが交換電話網および専用のポイントツーポイント2線式電話型回路上のレートシグナリングデータで動作するモデム」、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]国際電気通信連合は、「パブリックで使用するためのデジタルモデムとアナログモデムの対は、上流下流の最大56 000ビット/秒のレートシグナリングデータで交換電話網（PSTN）、最大33 600ビット/秒」、 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]国際電気通信連合、「4線式回路に使用するために最大64 000ビット/秒のレートシグナリングデータで動作するデジタルモデム接続を切り替えて専用のポイント・ツー・ポイント4線式デジタル回路上の」、ITU -T勧告V.91、1999年5月。
[31] International Telecommunication Union, "Enhancements to Recommendation V.90", ITU-T Recommendation V.92, November 2000.
、ITU-T勧告V.92、2000年11月[31]国際電気通信連合、 "勧告V.90の強化"。
[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]国際電気通信連合、 "モデムオーバー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]電気通信工業会は、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
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨークのヘニングSchulzrinneとコロンビアU.部長、NY 10027米国
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
トムテイラーノーテル1852ロレーヌアヴェオタワ、オンタリオ州K1H 6Z8カナダ
EMail: taylor@nortel.com
メールアドレス：taylor@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。