Network Working Group H. Schulzrinne
Request for Comments: 4734 Columbia U.
Obsoletes: 2833 T. Taylor
Updates: 4733 Nortel
Category: Standards Track December 2006
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.
此备忘录更新RFC 4733，以便在电话事件RTP有效负载中携带时，为调制解调器、传真和文本电话信号添加事件代码。它取代了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
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中的说明进行解释。
In addition to those defined for specific events, this document uses the following abbreviations:
除了为特定事件定义的缩写外，本文件还使用以下缩写：
Fax facsimile
传真
HDLC High-level Data Link Control
高电平数据链路控制
PSTN Public Switched (circuit) Telephone Network
公用交换（电路）电话网
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建议相对应。其目的是支持传真、调制解调器或文本电话会话的协商、启动和关闭以及操作模式之间的转换。实际传真、调制解调器和文本有效载荷通常由其他有效载荷类型承载（例如，V.150.1[32]调制解调器中继、ITU-T Rec.V.152[33]中形式化的声带数据、数字数据的Clearmode[17]、传真的T.38[21]或字符模式文本的RFC 4103[18]）。
NOTE: implementers SHOULD NOT rely on the descriptions of the various modem protocols described below without consulting the original references (generally ITU-T Recommendations). The descriptions are provided in this document to give a context for the use of the events defined here. They frequently omit important details needed for implementation.
注：在未参考原始参考资料（通常为ITU-T建议）的情况下，实施者不应依赖下文所述的各种调制解调器协议的描述。本文档中提供的描述为使用此处定义的事件提供了上下文。它们经常忽略实施所需的重要细节。
The typical application of these events is to allow the Internet to serve as a bridge between terminals operating on the PSTN. This application is characterized as follows:
这些事件的典型应用是允许互联网充当PSTN上运行的终端之间的桥梁。该应用程序的特点如下：
o each gateway will act both as sender and as receiver;
o 每个网关将同时充当发送方和接收方；
o time constraints apply to the exchange of signals, making the early identification and reporting of events desirable so that receiver playout can proceed in a timely fashion;
o 时间限制适用于信号交换，使事件的早期识别和报告变得可取，以便接收机播放能够及时进行；
o the receiver must play out events in their proper order;
o 接受者必须以正确的顺序播放事件；
o transfer of the events must be reliable. Applications will vary in their ability to recover from missing events.
o 事件的传输必须可靠。应用程序从丢失事件中恢复的能力各不相同。
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 2.4.1 of RFC 4733 [5] specifies how an implementation can use the Session Description Protocol (SDP) "fmtp" parameter within an SDP description [4] to indicate which events it is prepared to handle.
在某些情况下，实现可能只是忽略某些在特定环境中没有意义的事件，例如传真音。RFC 4733[5]第2.4.1节规定了实现如何在SDP描述[4]中使用会话描述协议（SDP）“fmtp”参数来指示准备处理哪些事件。
Regardless of which events they support, implementations MUST be prepared to send and receive data signals using payload types other than telephone-event, simultaneously with the use of the latter. This is discussed further in Section 3.
无论支持哪种事件，实现都必须准备好在使用电话事件的同时，使用电话事件以外的负载类型发送和接收数据信号。这将在第3节中进一步讨论。
In many cases, continuity of playout is critical. In principle, this is achieved through buffering at the receiving end. It is generally desirable to minimize such buffering to reduce round-trip response times. Maintenance of a constant packetization interval at the sending end while reporting events is helpful for this purpose.
在许多情况下，比赛的连续性至关重要。原则上，这是通过接收端的缓冲来实现的。通常希望最小化这种缓冲以减少往返响应时间。在报告事件时，在发送端保持恒定的打包间隔有助于实现这一目的。
A further word on time constraints is in order. Time constraints governing the duration of tones do not pose a problem when using the telephone-event payload type: the payload specifies the duration and the receiving gateway can play out the tones accordingly. Problems occur when time constraints are specified for the duration of silence between tones. A silent period of "at least x ms" is not a problem -- event notifications can be received late, but they can still be played out at their specified durations.
关于时间限制的另一个词已经准备好了。当使用电话事件有效负载类型时，控制音调持续时间的时间约束不会造成问题：有效负载指定持续时间，接收网关可以相应地播放音调。当为音调之间的静音持续时间指定时间限制时，会出现问题。“至少x毫秒”的静默期不是问题——事件通知可以延迟接收，但仍可以在指定的持续时间内播放。
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 Rec.G.164[6]）和回声消除器（ITU-T Rec.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]是两个端点在呼叫启动时和呼叫建立后建立彼此能力和在不同操作模式之间转换的一般程序。它支持许多与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 bis能力协商之后，如果终端协商了基于调制解调器的操作模式，则它们使用V.8、V.8的截断版本（首选）或V.25启动来启动实际的调制解调器会话。第2.4节描述了V.25。
V.8 bis distinguishes between "signals" and "messages". The V.8 bis signals -- ESi/ESr, MRe/MRd, and CRe/CRd -- consist of tones, as described in the next few paragraphs. The V.8 bis messages -- MS, CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4) -- consist of sequences of bits transported over V.21 [12] modulation.
V.8之二区分了“信号”和“信息”。V.8 bis信号——ESi/ESr、MRe/MRd和CRe/CRd——由音调组成，如下几段所述。V.8 bis消息——MS、CL、CLR、ACK（1）、ACK（2）、NAK（1）、NAK（2）、NACK（3）和NACK（4）——由通过V.21[12]调制传输的比特序列组成。
Signals are intended to be comprehensible at the receiver even in the presence of voice content. They consist of two tone segments. The first segment consists of a dual-frequency tone held for 400 ms, and has the function of preparing the receiver and any in-line echo suppressor or canceller for what follows. The specific frequencies depend only on whether the signal is from the initiator or the responder in a transaction. When using the telephone-event payload, the V8bISeg and V8bRSeg events in Table 1 represent the first segment of any V.8 bis signal in the initiating and responding case, respectively.
信号旨在即使在存在语音内容的情况下也能在接收器处被理解。它们由两个音调段组成。第一段由一个保持400 ms的双频音调组成，具有为接收机和任何在线回波抑制器或消除器准备以下内容的功能。特定频率仅取决于信号是来自事务中的发起方还是响应方。当使用电话事件有效载荷时，表1中的V8bISeg和V8bRSeg事件分别表示启动和响应情况下任何V.8 bis信号的第一段。
The complete V.8 bis strategy for dealing with echo suppressors or cancellers is described in Rec. V.8 bis Appendix III. The only silent period constraints imposed are of the "at least" type, posing no difficulties for the use of the telephone-event payload.
关于处理回声抑制器或消除器的完整V.8 bis策略，请参见附录III中的建议V.8 bis。施加的唯一静默期限制为“至少”类型，不会对电话事件有效载荷的使用造成任何困难。
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 ms的单音。使用的频率表示定义的六个信号中的特定信号。使用电话事件有效载荷时，V.8 bis信号的第二段由适用事件表示：CRdSeg、CReSeg、MRdSeg、MReSeg、，
ESiSeg, or ESrSeg, as defined in Table 1. ESiSeg and ESrSeg use the same frequencies as V.21 low and high channel '1' bits, respectively (see Table 2), and are therefore assigned the same event codes.
ESiSeg或ESrSeg，如表1所示。ESiSeg和ESrSeg分别使用与V.21低通道和高通道“1”位相同的频率（见表2），因此分配了相同的事件代码。
V.8 bis messages use V.21 [12] frequency-shift signalling to transfer message content. V.21 is described in the next section. V.8 bis uses V.21 in half-duplex mode at 300 bits/s, with the lower channel assigned to the initiator and the upper channel to the responder.
V.8 bis消息使用V.21[12]频移信号传输消息内容。V.21将在下一节中介绍。V.8 bis以300比特/秒的速度在半双工模式下使用V.21，低通道分配给启动器，高通道分配给响应器。
Each V.8 bis message is preceded by a 100-ms preamble of continuous V.21 marking frequency except if it was immediately preceded by an ESi or ESr signal (the second segment of which is that same V.21 marking frequency). The sender SHALL NOT report this preamble tone using the ESiSeg or ESrSeg events; these are to be used only for the V.8 bis signals to which they pertain.
每个V.8 bis消息前面都有一个100毫秒的连续V.21标记频率的前导码，除非它前面紧接着一个ESi或ESr信号（第二段是相同的V.21标记频率）。发送方不得使用ESiSeg或ESrSeg事件报告此前导音；这些信号仅用于与之相关的V.8 bis信号。
Spelling this out, continuous V.21 marking tone immediately following V8bISeg and V8bRSeg is reported as ESiSeg or ESrSeg, respectively. Continuous V.21 marking tone occurring in any other context, and particularly after CRdSeg, CReSeg, MRdSeg, or MReSeg, is reported by other means such as a different payload type or using the V.21 '1' bit events defined in Section 2.2.
为了说明这一点，紧接着V8bISeg和V8bRSeg的连续V.21标记音分别报告为ESiSeg或ESrSeg。在任何其他情况下，尤其是在CRdSeg、CReSeg、MRdSeg或MReSeg之后，出现的连续V.21标记音通过其他方式报告，如不同的有效负载类型或使用第2.2节中定义的V.21“1”位事件。
No events are defined for V.8 bis messages, but a brief description follows.
没有为V.8 bis消息定义任何事件，但下面将进行简要说明。
o the V.8 bis CL message describes the sending terminal's capabilities;
o V.8 bis CL报文描述了发送终端的能力；
o the CLR message also describes capabilities, but indicates that the sender wants to receive a CL in return;
o CLR消息还描述了功能，但表示发送方希望收到CL作为回报；
o the MS establishes a particular operating mode;
o MS建立特定的操作模式；
o the ACK and NAK messages are used to terminate the message transactions.
o ACK和NAK消息用于终止消息事务。
The V.8 bis messages are organized as a sequence of octets. The first two to five octets are HDLC flags (0x7E). Then comes a message type identifier (four bits), a V.8 bis version identifier (four bits), zero to two more octets of identifying information, followed by zero or more information field parameters in the form of bit maps. An individual bit map is one to five octets in length. Up to 64 octets of non-standard information may also be present. The information fields are followed by a checksum and one to three HDLC flags. Because of limits on the size of any one information field, V.8 bis defines segmentation procedures. Excess data is sent in an additional message, but only after prompting from the receiving end.
V.8 bis消息被组织为八位字节序列。前两到五个八位字节是HDLC标志（0x7E）。然后是一个消息类型标识符（四位）、一个V.8 bis版本标识符（四位）、零到两个以上的八位字节的标识信息，然后是零个或多个位图形式的信息字段参数。单个位图的长度为一到五个八位字节。还可能存在多达64个八位字节的非标准信息。信息字段后面是校验和和和一到三个HDLC标志。由于对任何一个信息字段大小的限制，V.8 bis定义了分段过程。多余的数据在附加消息中发送，但仅在接收端提示后发送。
Applications supporting V.8 bis signalling using the telephone-event payload MAY transfer V.8 bis messages in the form of sequences of bits, using the V.21 bit events defined in the next section. If they do so, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, and the terminating HDLC flags.
使用电话事件有效载荷支持V.8 bis信令的应用程序可以使用下一节中定义的V.21位事件，以位序列的形式传输V.8 bis消息。如果这样做，则传输的信息必须包括消息的完整内容：初始HDLC标志、信息字段、校验和和终止HDLC标志。
Transmission MUST also include the extra '0' bits added according to the procedures of Rec. V.8 bis, clause 7.2.8, to prevent false recognition of HDLC flags at the receiver. Implementers should note that these extra '0' bits mean that in general V.8 bis messages as transmitted on the wire will not come out to an even multiple of octets. Sending implementations MAY choose to vary the packetization interval to include exactly one octet of information plus any extra '0' bits inserted into that octet; the resulting variation will be insignificant compared with the amount of buffering required to guard against network delays in delivery of packets to the receiver (see below).
传输还必须包括根据Rec.V.8 bis第7.2.8条的程序添加的额外“0”位，以防止接收器错误识别HDLC标志。实施者应注意，这些额外的“0”位意味着，通常情况下，在有线传输的V.8 bis消息不会达到八位字节的偶数倍。发送实现可以选择改变分组间隔，以包括正好一个八位字节的信息加上插入该八位字节的任何额外的“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 bis和V.21信号的功率水平受国家法规的约束。因此，似乎适合将V.8 bis事件建模为由发送方指定音量的音调。如果接收器将V.8 bis音调作为音频内容呈现，以便向前传输，则接收器可使用事件报告中包含的音量，或可修改音量以符合下游国家要求。
Table 1 summarizes the event codes defined for V.8 bis signalling in this document. The individual events are described following the table. Each event begins when the beginning of the tone segment is detected and ends when the tone is no longer detected.
表1总结了本文件中为V.8 bis信号定义的事件代码。下表描述了各个事件。每个事件在检测到音调段的开始时开始，在不再检测到音调时结束。
+---------+-------------+-----------+------------+------+---------+
| Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? |
+---------+-------------+-----------+------------+------+---------+
| ESiSeg | 980 | 100 | 38 | tone | yes |
| | | | | | |
| ESrSeg | 1650 | 100 | 40 | tone | yes |
| | | | | | |
| CRdSeg | 1900 | 100 | 23 | tone | yes |
| | | | | | |
| CReSeg | 400 | 100 | 24 | tone | yes |
| | | | | | |
| MRdSeg | 1150 | 100 | 25 | tone | yes |
| | | | | | |
| MReSeg | 650 | 100 | 26 | tone | yes |
| | | | | | |
| V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes |
| | | | | | |
| V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes |
+---------+-------------+-----------+------------+------+---------+
+---------+-------------+-----------+------------+------+---------+
| Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? |
+---------+-------------+-----------+------------+------+---------+
| ESiSeg | 980 | 100 | 38 | tone | yes |
| | | | | | |
| ESrSeg | 1650 | 100 | 40 | tone | yes |
| | | | | | |
| CRdSeg | 1900 | 100 | 23 | tone | yes |
| | | | | | |
| CReSeg | 400 | 100 | 24 | tone | yes |
| | | | | | |
| MRdSeg | 1150 | 100 | 25 | tone | yes |
| | | | | | |
| MReSeg | 650 | 100 | 26 | tone | yes |
| | | | | | |
| V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes |
| | | | | | |
| V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes |
+---------+-------------+-----------+------------+------+---------+
Table 1: Events for V.8 bis Signals
表1:V.8 bis信号的事件
ESiSeg:
ESiSeg：
The second segment of a V.8 bis initiating Escape Signal (ESi). The complete ESi signal is represented by events V8bISeg followed by ESiSeg. ESi will be followed by an MS, CL, or CLR message from the same terminal. A 1.5-s silent interval may come between the ESi signal and the transmission of the MS, CL, or CLR message to accommodate network echo suppressors.
V.8 bis启动逃逸信号（ESi）的第二段。完整的ESi信号由事件V8bISeg表示，后跟ESiSeg。ESi之后将出现来自同一终端的MS、CL或CLR消息。ESi信号与MS、CL或CLR消息传输之间可能存在1.5秒的静默间隔，以适应网络回声抑制器。
ESrSeg:
ESrSeg：
The second segment of a V.8 bis responding Escape Signal (ESr). The complete ESr signal is represented by events V8bRSeg followed by ESrSeg. ESr is always sent by the calling terminal in response to an MRe or CRe from an automatic answering station. It will be followed by an MS, CL, or CLR message. The ESr signal turns off any announcement being generated by the automatic answering station.
V.8 bis响应逃逸信号（ESr）的第二段。完整的ESr信号由事件V8bRSeg和ESrSeg表示。ESr总是由呼叫终端发送，以响应来自自动应答站的MRe或CRe。随后将出现MS、CL或CLR消息。ESr信号关闭自动应答站生成的任何公告。
CRdSeg:
CRdSeg：
The second segment of a V.8 bis Capabilities Request signal (CRd). The first segment of the CRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a capabilities list (CL or CLR message).
V.8 bis能力请求信号（CRd）的第二段。CRd信号的第一段由V8bISeg或V8bRSeg表示，具体取决于上下文。另一端将返回一个功能列表（CL或CLR消息）。
CReSeg:
克雷塞格：
The second segment of a V.8 bis Capabilities Request signal (CRe) initiated by an automatic answering terminal. The complete CRe signal is represented by events V8bISeg followed by CReSeg. The calling terminal will respond with a CRd signal or a CL or CLR message.
由自动应答终端发起的V.8 bis能力请求信号（CRe）的第二段。完整的CRe信号由事件V8bISeg和CReSeg表示。呼叫终端将以CRd信号或CL或CLR消息进行响应。
MRdSeg:
MRdSeg：
The second segment of a V.8 bis Mode Request signal (MRd). The first segment of the MRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a CRd signal or an MS message.
V.8 bis模式请求信号（MRd）的第二段。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）的第二段。完整的MRe信号由事件V8bISeg表示，后跟MReSeg。呼叫终端将以MRd或CRd信号或MS消息进行响应。
V8bISeg:
V8bISeg：
The first segment of an initiating V.8 bis signal, which may be one of ESi, CRd, CRe, MRd, or MRe.
起始V.8 bis信号的第一段，可以是ESi、CRd、CRe、MRd或MRe中的一个。
V8bRSeg:
V8bRSeg：
The first segment of a responding V.8 bis signal, which may be one of ESr, CRd, or MRd.
响应V.8 bis信号的第一段，可以是ESr、CRd或MRd之一。
V.8 bis implementations are unlikely to tolerate gaps or extensions in playout times due to congestion-caused packet delay. At a minimum, the current transaction is liable to be reset when these defects in playout occur. As a result, careful management of the playout buffer is required at the receiver to increase robustness in the face of possible lost or delayed packets. The playout algorithm should also be such as not to cause event playout to exceed the nominal duration of the event.
V.8 bis实现不太可能容忍由于拥塞导致的数据包延迟而导致的播放时间间隔或延长。至少，当播放中出现这些缺陷时，当前事务可能会被重置。因此，需要在接收器处仔细管理播放缓冲区，以增加面对可能丢失或延迟分组时的鲁棒性。播放算法还应确保不会导致事件播放超过事件的标称持续时间。
V.8 bis does not appear to offer opportunities for dynamic adaptation to congestion through manipulation of the packetization interval.
V.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位/秒的数据传输速率。定义了两个通道，在需要时支持全双工数据传输。低通道使用频率980 Hz表示“1”（标记），1180 Hz表示“0”（空间）；高通道使用1650 Hz的频率表示“1”，1850 Hz的频率表示“0”。调制解调器可以同步或异步工作。
V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) for transmission of control data, and is also used in its own right between text terminals. The V.21 events are summarized in Table 2.
V.21被其他协议（例如，V.8 bis、V.18、T.30）用于控制数据的传输，并且在文本终端之间以其自身的权利使用。表2总结了V.21事件。
Sending implementations SHOULD report a completed event for every bit transmitted (i.e., rather than at transitions between '0' and '1'). Bit events are assumed to begin and end with the clock interval for the event, neglecting the rise and fall times between bit transitions. Thus, it is important for a gateway to determine the actual bit rate in use before beginning to report V.21 events.
发送实现应报告传输的每个位的已完成事件（即，而不是“0”和“1”之间的转换）。假定位事件以事件的时钟间隔开始和结束，忽略位转换之间的上升和下降时间。因此，网关在开始报告V.21事件之前确定实际使用的比特率是很重要的。
Sometimes determination of the bit rate is not immediately possible, as in the case of the 100-ms training signal at V.21 mark frequency used before V.8 bis messages. Transmission of a single longer-duration V.21 event is reasonable under these circumstances and should not cause any difficulties at the receiving end.
有时无法立即确定比特率，例如在V.8 bis消息之前使用的V.21标记频率下的100 ms训练信号。在这些情况下，传输单个较长持续时间的V.21事件是合理的，并且不应在接收端造成任何困难。
Implementations SHOULD pack multiple events into one packet, using the procedures of Section 2.5.1.5 of RFC 4733 [5]. Eight to ten bits is a reasonable packetization interval.
实施应使用RFC 4733[5]第2.5.1.5节中的程序将多个事件打包成一个数据包。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[5]第2.5.1.4节中的描述传输三次。为了减少报告所需的数据包数量，实现应该使用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比特的时间为3.33毫秒，或以默认8000 Hz采样率传输26.67个时间戳单位。由于此持续时间不是时间戳单位的整数，因此不可能准确报告事件开始和事件持续时间。发送网关应将V.21事件开始时间四舍五入到最接近的整个时间戳单位。
When sending multiple consecutive V.21 events in a succession of packets, the sending gateway MUST ensure that individual event durations reported do not cause the last event of one packet to overlap with the first event of the next, taking into account the respective initial event timestamps. To accomplish this, the sending gateway MUST derive the individual event durations as the succession of differences between the event starting times (so that, at 8000 Hz, every third event has reported duration 26 units, the remainder 27 units).
当以连续的数据包发送多个连续的V.21事件时，发送网关必须确保报告的单个事件持续时间不会导致一个数据包的最后一个事件与下一个数据包的第一个事件重叠，同时考虑到各自的初始事件时间戳。为了实现这一点，发送网关必须将单个事件持续时间导出为事件开始时间之间的连续差异（因此，在8000 Hz时，每三个事件报告持续时间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 | | | | |
+--------------------+----------------+------------+------+---------+
+--------------------+----------------+------------+------+---------+
| 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]发送或接收传真，以及一长串V系列调制解调器，包括V.34[28]、V.90[29]、V.91[30]和V.92[31]。与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.
第8节未使用与第8节之二相同的术语。相反，它定义了由V.21[12]以300位/秒传输的位组成的四个信号：呼叫指示灯信号（CI）、呼叫菜单信号（CM）、CM终止符（CJ）和联合菜单信号（JM）。此外，它使用了V.25[13]和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信号。它至少重复CI三次，偶尔会暂停，直到检测到ANSam音。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将在400 ms后禁用电路上的任何G.164[6]回波抑制器，并在ANSam播放一秒钟后禁用任何G.165[7]回波消除器。
3. On detecting ANSam, the calling terminal pauses at least half a second, then begins transmitting CM to indicate detailed capabilities within the chosen mode.
3. 在检测到ANSam时，呼叫终端暂停至少半秒，然后开始发送CM以指示所选模式内的详细能力。
4. After detecting at least two identical sequences of CM, the answering terminal begins to transmit JM, indicating its own capabilities (or offering an alternative terminal type if it cannot support the one requested).
4. 在检测到至少两个相同的CM序列后，应答终端开始发送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序列后，呼叫终端完成CM的当前八位字节，然后发送CJ以确认JM信号。它暂停75毫秒，然后在所选模式下开始运行。
6. The answering terminal transmits JM until it has detected CJ. At that point, it stops transmitting JM immediately, pauses exactly 75 ms, then starts operating in the selected mode.
6. 应答终端发送JM，直到检测到CJ。此时，它立即停止传输JM，暂停75毫秒，然后开始在选定模式下运行。
The CI, CM, and JM signals all consist of a fixed sequence of ten '1' bits followed by a signal-dependent pattern of ten synchronization bits, followed by one or more octets of variable information. Each octet is preceded by a '0' start bit and followed by a '1' stop bit. The combination of the synchronization pattern and V.21 channel uniquely identifies the message type. The CJ signal consists of three successive octets of all zeros with stop and start bits but without the preceding '1's and synchronizing pattern of the other signals.
CI、CM和JM信号都由十个“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.
应用程序可以将CM、JM和CJ信号的每个实例分别报告为一系列V.21位事件（第2.2节），或者可以使用另一种有效负载类型来承载此信息。支持使用电话事件有效载荷的V.8信令的应用程序可将CI信号的同步部分（十个'1'后接'000001'）报告为一系列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毫秒后从电话事件的播放切换到数据承载有效负载的播放。
+--------+----------------------+------------+------+---------+
| 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 |
+--------+----------------------+------------+------+---------+
+--------+----------------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------+----------------------+------------+------+---------+
| ANSam | 2100 x 15 | 34 | tone | yes |
| | | | | |
| /ANSam | 2100 x 15 phase rev. | 35 | tone | yes |
| | | | | |
| CI | (V.21 bits) | 53 | tone | yes |
+--------+----------------------+------------+------+---------+
Table 3: Events for V.8 Signals
表3:V.8信号的事件
ANSam:
安萨姆：
The modified answer tone ANSam consists of a sinewave signal at 2100 Hz, amplitude-modulated by a sine wave at 15 Hz. The beginning of the event is at the beginning of the tone. The end of the event is at the sooner of the ending of the tone or the occurrence of a phase reversal (marking the beginning of a /ANSam event). Phase reversals are used to disable echo cancellation; if they are being applied, they occur at 450-ms intervals.
修改后的应答音ANSam由2100 Hz的正弦波信号组成，振幅由15 Hz的正弦波调制。事件的开始是在音调的开始。事件结束时间为音调结束或相位反转（标志a/ANSam事件开始）发生的较早时间。相位反转用于禁用回声消除；如果正在应用它们，则它们以450毫秒的间隔出现。
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事件之前，不应发送ANSam事件包（见下文V.25事件）。
The modulated envelope for the ANSam tone ranges in amplitude between 0.8 and 1.2 times its average amplitude. The average transmitted power is governed by national regulations. Thus, it makes sense to indicate the volume of the signal.
ANSam音调的调制包络的振幅范围在其平均振幅的0.8到1.2倍之间。平均传输功率受国家法规管辖。因此，指示信号的音量是有意义的。
/ANSam:
/安萨姆：
/ANSam reports the same physical signal as ANSam, but is reported following the first phase reversal in that signal. It begins with the phase reversal and ends at the end of the tone. The receiver of /ANSam MUST reverse the phase of the tone at the beginning of playout of /ANSam and every 450 ms thereafter until the end of the tone is reached.
/ANSam报告与ANSam相同的物理信号，但在该信号的第一个相位反转后报告。它从相位反转开始，在音调结束时结束。/ANSam接收器必须在/ANSam播放开始时反转音调相位，此后每隔450毫秒反转一次，直到到达音调结束。
CI:
CI:
CI reports the occurrence of the V.21 bit pattern '11111 11111 00000 00001' indicating the beginning of a V.8 CI signal. The event begins at the beginning of the first bit and ends at the end of the last one. This event MUST NOT be reported except in a context where a V.8 CI signal might be expected (i.e., at the calling end during call setup). Note that if the calling modem
CI报告V.21位模式“11111 11111 00000 00001”的出现，表示V.8 CI信号的开始。事件从第一位开始，到最后一位结束。不得报告此事件，除非在可能预期V.8 CI信号的上下文中（即，在呼叫设置期间的呼叫端）。请注意，如果呼叫调制解调器
sends the CI signal at all, it will typically repeat the signal several times.
发送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]是早于V.8[9]和V.8之二[10]的启动协议。它规定了两种音调信号的交换：CT和ANS。
CT (calling tone) consists of a series of interrupted bursts of 1300-Hz tone, on for a duration of not less than 0.5 s and not more than 0.7 s and off for a duration of not less than 1.5 s and not more than 2.0 s. [13]. Modems not starting with the V.8 CI signal often use this tone.
CT（呼叫音）由一系列1300 Hz的中断突发音组成，打开持续时间不小于0.5 s，不大于0.7 s，关闭持续时间不小于1.5 s，不大于2.0 s。[13]. 不以V.8 CI信号启动的调制解调器通常使用此音调。
ANS (Answer tone) is a 2100-Hz tone used to disable echo suppression for data transmission [13], [8]. For fax machines, Recommendation T.30 [8] refers to this tone as called terminal identification (CED) answer tone. ANS differs from V.8 ANSam in that, unlike the latter, it has constant amplitude.
ANS（应答音）是一种2100 Hz的音调，用于禁用数据传输的回波抑制[13]，[8]。对于传真机，建议T.30[8]将此音调称为终端识别（CED）应答音。ANS与V.8 ANSam的不同之处在于，与后者不同，它具有恒定的振幅。
V.25 specifically includes procedures for disabling echo suppressors as defined by ITU-T Rec. G.164 [6]. However, G.164 echo suppressors have now for the most part been replaced by G.165 [7] echo
V.25特别包括ITU-T Rec.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）。因此，2001年7月修改了建议V.25，规定如果要禁用回声抵消器，则需要ANS音调中的相位反转。
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不会到达呼叫终端。因为这大约需要一秒钟，所以它只能发生在一次CT脉冲和下一次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 ms（如果使用ANS的相位反转来禁用回声消除器，则至少1 s），然后才能生成呼叫站响应音。此音调特定于调制解调器，未在V.25中指定。
4. The called terminal plays out ANS for 2.6 to 4.0 seconds or until it has detected calling station response for 100 ms. It waits 55-95 ms (nominal 75 ms) in silence. (Note that the upper limit of 95 ms is rather close to the point at which echo control may reestablish itself.) If the reason for ANS termination was timeout rather than detection of calling station response, the called terminal begins to play out ANS again to maintain disabling of echo control until the calling station responds.
4. 被叫终端播放ANS 2.6至4.0秒，或直到它检测到呼叫站响应100毫秒。它静默等待55-95毫秒（标称75毫秒）。（注意，95 ms的上限非常接近回声控制可能重新建立自身的点。）如果ANS终止的原因是超时而不是检测到呼叫站响应，则被叫终端开始再次播放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 |
+-------------------+----------------+------------+------+---------+
+-------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+-------------------+----------------+------------+------+---------+
| Answer tone (ANS) | 2100 | 32 | tone | yes |
| | | | | |
| /ANS | 2100 ph. rev. | 33 | tone | yes |
| | | | | |
| CT | 1300 | 49 | tone | yes |
+-------------------+----------------+------------+------+---------+
Table 4: Events for V.25 Signals
表4:V.25信号的事件
ANS:
答复：
The beginning of the event is at the beginning of the 2100-Hz tone. The end of the event is at the sooner of the ending of the tone or the occurrence of a phase reversal (marking the beginning of a /ANS event).
事件的开始是2100 Hz音调的开始。事件结束时间为音调结束或发生相位反转（标志a/ANS事件开始）中较早的一个。
An initial ANS event packet SHOULD NOT be sent until it is possible to discriminate between an ANS event and an ANSam event (see V.8 events, above).
在能够区分ANS事件和ANSam事件之前，不应发送初始ANS事件数据包（见上文V.8事件）。
/ANS:
/答复：
/ANS reports the same physical signal as ANS, but is reported following the first phase reversal in that signal. It begins with the phase reversal and ends at the end of the tone. The receiver of /ANS MUST reverse the phase of the tone at the beginning of playout of /ANS and every 450 ms thereafter until the end of the tone is reached.
/ANS报告与ANS相同的物理信号，但在该信号的第一个相位反转后报告。它从相位反转开始，在音调结束时结束。/ANS接收器必须在/ANS播放开始时反转音调相位，此后每隔450毫秒反转一次，直到到达音调结束。
CT:
计算机断层扫描：
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的相变。当遇到拥塞时，发送方似乎还可以临时增加分组间隔以减少分组量。一个风险是，延长的播放继续进行，超过音调的实际结束（追溯确定），并且接收机被迫继续施加额外的播放缓冲延迟，以满足音调播放后标称75 ms静默期的最大持续时间的限制。
ITU-T Recommendation V.32 [14] is a modem using phase-shift keying with quadrature amplitude modification. It operates on a carrier at 1800 Hz, modulated at 2400 symbols/s. The basic data rates for V.32 are 4800 and 9600 bits/s. V.32bis [15] extends the data rates up to 14,400 bits/s. Most or all existing deployments are V.32bis, typically in support of point-of-sale terminals and the like.
ITU-T建议V.32[14]是一种使用相移键控和正交幅度修改的调制解调器。它在1800赫兹的载波上工作，以2400符号/秒的速度调制。V.32的基本数据速率为4800和9600位/秒。V.32bis[15]将数据速率扩展至14400位/秒。大多数或所有现有部署都是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. 从ANS开始，到结束。从ANS开始，到结束。从ANS开始，到结束。从ANS开始，到结束。从ANS开始，到结束。从ANS开始，到结束。从ANS开始，到结束。从第2.5段，到结束，到结束，到结束。从第5.1段，到结束，到结束，到结束，到结束，到结束，到结束，从应答；
b. the calling end waits in silence until it has detected ANS for 1 s;
b. 呼叫端静默等待，直到检测到ANS 1s；
c. the calling end begins to transmit a V.32/V.32bis pattern designated AA, i.e., a series of '0000' bit sequences transmitted at 4800 bits/s;
c. 呼叫端开始发送指定为AA的V.32/V.32bis模式，即以4800比特/s发送的一系列“0000”比特序列；
d. upon detecting the AA pattern for at least 100 ms, the called modem is silent for 75 +/- 20 ms, then responds with an AC pattern, which is a series of '0011' bit sequences transmitted at 4800 bits/s.
d. 在检测到AA模式至少100 ms后，被叫调制解调器静音75+/-20 ms，然后以AC模式响应，AC模式是以4800位/秒传输的一系列“0011”位序列。
The difference in leased line operation is that the calling modem starts the session by sending AA. After that, the called modem responds with AC, and the rest of the sequence is unchanged.
租用线路操作的不同之处在于，主叫调制解调器通过发送AA来启动会话。之后，被调用的调制解调器用交流电响应，序列的其余部分不变。
In support of V.32/V.32bis operation, Table 5 defines two events, V32AA and V32AC.
为了支持V.32/V.32bis操作，表5定义了两个事件，V32AA和V32AC。
+----------------+------------------+------------+------+---------+
| Event | Bit Pattern | Event Code | Type | Volume? |
+----------------+------------------+------------+------+---------+
| V32AA | b'0000' repeated | 63 | tone | yes |
| | | | | |
| V32AC | b'0011' repeated | 27 | tone | yes |
+----------------+------------------+------------+------+---------+
+----------------+------------------+------------+------+---------+
| Event | Bit Pattern | Event Code | Type | Volume? |
+----------------+------------------+------------+------+---------+
| V32AA | b'0000' repeated | 63 | tone | yes |
| | | | | |
| V32AC | b'0011' repeated | 27 | tone | yes |
+----------------+------------------+------------+------+---------+
Table 5: Events for V.32/V.32bis Signals
表5:V.32/V.32bis信号的事件
V32AA:
V32AA：
Indicates that the AA calling pattern of a V.32/V.32bis terminal has been detected.
表示已检测到V.32/V.32bis终端的AA呼叫模式。
V32AC:
V32AC：
Indicates that the AC answering pattern of a V.32/V.32bis terminal has been detected.
表示已检测到V.32/V.32bis终端的交流应答模式。
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]或Clearmode[17]。为了帮助尽快进行转换，应在检测到相应模式后立即报告V32AA或V32AC事件。似乎实现将以替代形式同时传输具有相同数据的事件报告，通常使用RFC 2198[2]冗余。
The primary issue raised by congestion is the loss or undue delay of the initial report. Once the receiver is aware that an AA or AC pattern has been detected, further reports are of no interest. The actual duration of the AC pattern may be as short as 27 ms. On this basis, the appropriate sender behavior may be to send at least three packets reporting the event using normal event updates and end of event retransmission behavior and a fairly short packetization interval (20-30 ms).
拥堵引起的主要问题是初始报告的丢失或不当延误。一旦接收器意识到已检测到AA或AC模式，则对进一步的报告不感兴趣。AC模式的实际持续时间可短至27 ms。在此基础上，适当的发送者行为可为使用正常事件更新和事件结束重传行为以及相当短的分组间隔（20-30 ms）发送至少三个报告事件的分组。
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]定义了第三组传真终端使用的程序。定义本节事件的消息前程序用于识别各端的终端能力并协商操作模式。还包括Post消息过程，用于处理多文档传输等情况。传真终端支持多种协议栈，因此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
T.30定义了通话开始时使用的两个音调信号。CNG信号由呼叫终端发送。这是一种1100赫兹的纯音，以突发方式播放：0.5秒打开，3秒关闭。它一直持续到超时
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.
或者直到呼叫终端检测到响应。它的主要目的是让被叫端的人工操作员知道传真终端已在主叫端激活。
The called terminal waits in silence for at least 200 ms. It then may return CED tone (which is physically identical to V.25 ANS), or else V.8 ANSam if it has V.8 capability. If called and calling terminals both support V.8, the called terminal will detect CI or more likely CM in response to its ANSam and will continue with V.8 negotiation. Otherwise, the called terminal stops transmitting CED after 2.6 to 4 seconds, waits 75 +/- 20 ms in silence, then enters the T.30 negotiation phase.
被叫终端在静默中等待至少200毫秒。然后它可能返回CED音调（在物理上与V.25 ANS相同），或者如果它具有V.8能力，则返回V.8 ANSam。如果被叫和主叫终端都支持V.8，被叫终端将检测CI或更可能的CM以响应其ANSam，并将继续V.8协商。否则，被叫终端在2.6到4秒后停止发送CED，静默等待75+/-20毫秒，然后进入T.30协商阶段。
In the T.30 negotiation phase the terminals exchange binary messages using V.21 signals, high channel frequencies only, at 300 bits/s. Each message is preceded by a one-second (nominal) preamble consisting entirely of HDLC flag octets (0x7E). This flag has the function of preparing echo control equipment for the message that follows.
在T.30协商阶段，终端使用V.21信号以300比特/秒的速度交换二进制消息，仅高通道频率。每条消息前面都有一个1秒（标称）的前导，前导完全由HDLC标志八位字节（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要求插入额外的“0”位，以防止对HDLC标志的虚假识别。
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标志，以及为防止接收器错误识别HDLC标志而添加的额外“0”位。实施者应该注意到，这些额外的“0”位意味着，在一般情况下，通过有线传输的T.30消息不会达到八位字节的偶数倍。
The training signal sent by the transmitting terminal after DCS consists of a steady string of V.21 high channel zeros (1850-Hz tone) for 1.5 s. Since the bit rate (nominally 300 bits/s) should have been clearly established when processing the preceding signalling, it is natural that if the telephony-event payload type is being used, this training signal will also be sent as a series of V.21 bit events at that bit rate. However, if the sending gateway is capable of recognizing the transition from the end of the DCS to the start of training, it MAY report the training signal as a single extended V.21 (high channel) '0' event.
DCS后由发送终端发送的训练信号由稳定的V.21高通道零点串（1850 Hz音调）组成，持续1.5秒。由于在处理之前的信令时应明确确定比特率（名义上为300比特/秒），因此，如果正在使用电话事件有效载荷类型，则该训练信号也将以该比特率作为一系列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 |
+--------------------+----------------+------------+------+---------+
+--------------------+----------------+------------+------+---------+
| 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:
土木工程署：
The beginning of the event is at the beginning of the 2100-Hz tone. The end of the event is at the sooner of the ending of the tone or the occurrence of a phase reversal (marking the beginning of a /CED event).
事件的开始是2100 Hz音调的开始。事件结束时间为音调结束或相位反转（标志a/CED事件开始）发生的较早时间。
An initial CED event packet SHOULD NOT be sent until it is possible to discriminate between a CED event and an ANSam event (see V.8 events, above).
在能够区分CED事件和ANSam事件之前，不应发送初始CED事件数据包（见上文V.8事件）。
/CED:
/土木工程署：
/CED reports the same physical signal as CED, but is reported following the first phase reversal in that signal. It begins with the phase reversal and ends at the end of the tone. The receiver of /CED MUST reverse the phase of the tone at the beginning of playout of /CED and every 450 ms thereafter until the end of the tone is reached.
/CED报告与CED相同的物理信号，但在该信号的第一个相位反转后报告。它从相位反转开始，在音调结束时结束。/CED接收器必须在/CED播放开始时反转音调相位，此后每隔450毫秒反转一次，直到到达音调结束。
CNG:
压缩天然气：
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:
五.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 preamble事件吸收以下消息的初始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 bis一样，接收机必须适当地管理其播放缓冲区，以提高在拥塞情况下的鲁棒性。
Legacy text telephony uses a wide variety of terminals, with different standards favored in different parts of the world. Going forward, the vision is that new terminals will work directly into the packet network and be based on RFC 4103 [18] packetization of character data. In anticipation of this migration, it is RECOMMENDED that text carried in the PSTN by legacy modem protocols be converted to RFC 4103 packets at the sending gateway.
传统文本电话使用各种各样的终端，在世界不同地区采用不同的标准。展望未来，新的终端将直接进入分组网络，并基于RFC 4103[18]字符数据分组。在进行此迁移之前，建议在发送网关将传统调制解调器协议在PSTN中携带的文本转换为RFC 4103数据包。
During a transitional period, however, gateways of a lesser capability may be able to recognize the nature of incoming content, but may only be able to encode it as voice-band data on the packet side. In such circumstances, it will help to optimize processing of the signal at the receiving end if that end receives an indication of the nature of the voice-encoded data signals. The events defined in this section provide such indications, and MAY be used in conjunction with ITU-T Recommendation V.152 [33], as one example, to carry the content as voice-band data.
然而，在过渡期间，能力较小的网关可能能够识别传入内容的性质，但可能只能在分组侧将其编码为语音带数据。在这种情况下，如果接收端接收到语音编码数据信号性质的指示，则将有助于优化接收端的信号处理。本节中定义的事件提供了此类指示，并可与ITU-T建议V.152[33]结合使用，作为一个示例，将内容作为声带数据进行传输。
Implementers should take note of an additional class of text terminals not considered in the events below. These terminals use dual tone multi-frequency (DTMF) tones to encode and exchange signals. This application is described in RFC 4733 [5], Section 3.1, in conjunction with the registration of DTMF events.
实施者应注意以下事件中未考虑的另一类文本终端。这些终端使用双音多频（DTMF）音来编码和交换信号。RFC 4733[5]第3.1节结合DTMF事件的注册对该应用进行了描述。
The events shown in Table 7 correspond to signals coming from the following modem types:
表7所示的事件对应于来自以下调制解调器类型的信号：
o Baudot [34], a five bit character encoding nominally operating at 45.45 or 50 bits/s with frequencies 1800 Hz = '0', 1400 Hz = '1';
o Baudot[34]，一种五位字符编码，名义上以45.45或50位/秒的速度运行，频率为1800赫兹='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 EDT，即V.21[12]，在半双工模式下以110位/秒的速度运行（仅限较低通道）；字符为7位IA5加上初始起始位、尾随奇偶校验位和两个停止位；
o Bell 103 mode (documented in Recommendation V.18 Annex D), which is structurally similar to V.21, but uses different frequencies: lower channel, 1070 Hz = '0', 1270 Hz = '1'; upper channel, 2025 Hz = '0', 2225 Hz = '1'; characters are US ASCII framed by one start bit, one trailing parity bit, and one stop bit;
o 贝尔103模式（记录在建议V.18附录D中），其结构类似于V.21，但使用不同的频率：较低的信道，1070 Hz='0'，1270 Hz='1'；上通道，2025赫兹='0'，2225赫兹='1'；字符是由一个起始位、一个尾随奇偶校验位和一个停止位构成的美国ASCII码；
o V.23 [25] based videotex, in Minitel and Prestel versions. V.23 offers a forward channel operating at 1200 bits/s if possible (2100 Hz = '0', 1300 Hz = '1') or otherwise at 600 bits/s (1700 Hz = '0', 1300 Hz = '1'), and a 75 bits/s backward channel, which is transmitting 390 Hz (continuous '1's) except when '0' is to be transmitted (450 Hz);
o 基于V.23[25]的可视图文，采用Minitel和Prestel版本。V.23提供了一个以1200位/秒（如有可能）（2100 Hz='0'，1300 Hz='1'）或以600位/秒（1700 Hz='0'，1300 Hz='1'）的速度运行的前向信道，以及一个75位/秒的后向信道，该后向信道传输390 Hz（连续的'1'），除非传输'0'（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.
o 以300比特/秒的速度使用V.21[12]的非V.18文本终端。字符为7位国家字符（例如，美国ASCII），带有起始位、奇偶校验位和一个停止位。
+----------+-----------+----------------+---------+-------+---------+
| Event | Bit Rate | Frequency (Hz) | Event | Type | Volume? |
| | bits/s | | Code | | |
+----------+-----------+----------------+---------+-------+---------+
| ANS2225 | N/A | 2225 | 52 | tone | yes |
| | | | | | |
| V21L110 | 110 | 980/1180 | 55 | other | no |
| | | | | | |
| V21L300 | 300 | 980/1180 | 30 | other | no |
| | | | | | |
| V21H300 | 300 | 1650/1850 | 31 | other | no |
| | | | | | |
| B103L300 | 300 | 1070/1270 | 56 | other | no |
| | | | | | |
| V23Main | 600/1200 | 1700-2100/1300 | 57 | other | no |
| | | | | | |
| V23Back | 75 | 450/390 | 58 | other | no |
| | | | | | |
| Baud4545 | 45.45 | 1800/1400 | 59 | other | no |
| | | | | | |
| Baud50 | 50 | 1800/1400 | 60 | other | no |
| | | | | | |
| XCIMark | 1200 | 2100/1300 | 62 | tone | yes |
+----------+-----------+----------------+---------+-------+---------+
+----------+-----------+----------------+---------+-------+---------+
| Event | Bit Rate | Frequency (Hz) | Event | Type | Volume? |
| | bits/s | | Code | | |
+----------+-----------+----------------+---------+-------+---------+
| ANS2225 | N/A | 2225 | 52 | tone | yes |
| | | | | | |
| V21L110 | 110 | 980/1180 | 55 | other | no |
| | | | | | |
| V21L300 | 300 | 980/1180 | 30 | other | no |
| | | | | | |
| V21H300 | 300 | 1650/1850 | 31 | other | no |
| | | | | | |
| B103L300 | 300 | 1070/1270 | 56 | other | no |
| | | | | | |
| V23Main | 600/1200 | 1700-2100/1300 | 57 | other | no |
| | | | | | |
| V23Back | 75 | 450/390 | 58 | other | no |
| | | | | | |
| Baud4545 | 45.45 | 1800/1400 | 59 | other | no |
| | | | | | |
| Baud50 | 50 | 1800/1400 | 60 | other | no |
| | | | | | |
| XCIMark | 1200 | 2100/1300 | 62 | tone | yes |
+----------+-----------+----------------+---------+-------+---------+
Table 7: Indicators for Text Telephony
表7：文本电话指标
ANS2225:
ANS2225：
indicates that a 2225-Hz answer tone has been detected. This is a pure tone with no amplitude modulation and no semantics attached to phase reversals, if there are any. The sender SHOULD report the beginning of the event when the tone is detected. The sender MAY send updates as the tone continues, and MUST report the end of the event when the tone ceases. The tone concerned is generated by a Bell 103-type modem in answer mode. This event MUST NOT be reported outside of the startup context (i.e., on the answering side at the beginning of a call).
表示检测到2225 Hz的应答音。这是一种纯音，没有振幅调制，也没有相位反转的语义（如果有）。当检测到音调时，发送方应报告事件的开始。发送方可以在铃声持续时发送更新，并且必须在铃声停止时报告事件结束。相关音调由应答模式下的贝尔103型调制解调器产生。不得在启动上下文之外报告此事件（即在呼叫开始时的应答端）。
V21L110:
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.
表示发送方已检测到V.21调制以110比特/秒的速率在较低信道中运行。请注意，区分300位/秒和110位/秒操作可能需要一些时间。对于单个事件和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.
表示发送方检测到V.21调制以300比特/秒的速率在较低信道中运行。请注意，区分300位/秒和110位/秒操作可能需要一些时间。对于单个事件和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.
表示发送方检测到V.21调制以300比特/秒的速率在上层信道中运行。对于单个事件和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比特/秒的低信道中工作的贝尔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位/秒反向信道中运行的V.23调制。
Baud4545:
Baud4545：
indicates that the sending device has detected Baudot modulation operating at 45.45 bits/s.
表示发送设备已检测到以45.45位/秒运行的波多特调制。
Baud50:
波特50：
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).
表示发送设备在V.23主通道“标记”（1300 Hz）周期之后，已检测到使用V.23上通道调制以1200比特/秒的速度发送的特定位模式（0）1111111 1111（1）（0）1111 1111（1）。
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 ms是一个建议值，尽管相关媒体的打包周期可能足够。）发送方可以继续发送同一指示器事件的附加报告，尽管一旦接收方调整自身以适应其接收的内容类型，这些报告就没有多大价值。
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终端将使用V.8协商启动，并在物理级别继续，V.21以300位/秒的速度传输7位字符，由启动位和停止位限定。
The V.18 terminal is also designed to interoperate with the text modems listed in the previous sub-section. The startup sequences for all these different terminal types are naturally quite different. The V.18 initial startup sequence specifically addresses itself to V.8-capable terminals and V.21 terminals and, by the combination of signals, to V.23 videotex terminals. During the initial startup sequence, the V.18 terminal listens for frequency responses characterizing the other terminal types. If it does not make contact in the preliminary step, it probes for each type specifically. By the nature of the application, V.18 has been designed to provide an extremely robust startup capability.
V.18终端还设计用于与上一小节中列出的文本调制解调器进行互操作。所有这些不同终端类型的启动顺序自然是完全不同的。V.18初始启动序列专门针对具有V.8功能的终端和V.21终端，并通过信号组合针对V.23可视图文终端。在初始启动序列期间，V.18终端监听表征其他终端类型的频率响应。如果在初步步骤中没有接触，它会专门探测每种类型。根据应用程序的性质，V.18的设计目的是提供极其强大的启动能力。
The handling of the V.18 XCI signal is a specific case of the procedures described in the previous section. XCI is a signal transmitted in high-band V.23 modulation to stimulate V.23 terminals to respond and to allow detection of V.18 capabilities in a DCE. The 3-second XCI signal uses the V.23 upper channel having periods of "mark" (i.e., 1300 Hz) alternating with the XCIMark pattern. The full definition is found in V.18, Section 3.13. The sender SHOULD indicate V23Main during the transmission of the "mark" portion of XCI, and change the indication to XCIMark when that pattern is detected.
V.18 XCI信号的处理是前一节所述程序的具体情况。XCI是一种在高频段V.23调制中传输的信号，用于刺激V.23终端响应并允许检测DCE中的V.18能力。3秒XCI信号使用V.23上通道，其周期为“标记”（即1300 Hz），与XCIMark模式交替。完整定义见第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 ms是一个建议值，尽管相关媒体的打包周期可能足够。）发送方可以继续发送VBDGen事件的附加报告，尽管一旦接收方调整自身以适应其接收的内容类型，这些报告就没有多大价值。
+--------+---------------+------------+-----------+-------+---------+
| Event | Bit Rate | Frequency | Event | Type | Volume? |
| | bits/s | (Hz) | Code | | |
+--------+---------------+------------+-----------+-------+---------+
| VBDGen | Variable | Variable | 61 | other | no |
+--------+---------------+------------+-----------+-------+---------+
+--------+---------------+------------+-----------+-------+---------+
| 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中。网关可能服务于话音和数据通信的混合，并且需要采用适合于媒体流的有效负载类型。如果语音压缩用于语音呼叫，这意味着网关需要在识别数据流时灵活地切换到其他有效负载类型。
Within the established IETF framework, this implies that the gateways must negotiate the potential payloads (voice, telephone-event, tones, voice-band data, T.38 fax [21], and possibly RFC 4103 [18] text and Clearmode [17] octet streams) as separate payload types. From a timing point of view, this is most easily done at the beginning of a call, but results in an over-allocation of resources at the gateways and in the intervening network.
在已建立的IETF框架内，这意味着网关必须将潜在有效负载（语音、电话事件、音调、声带数据、T.38传真[21]，以及可能的RFC 4103[18]文本和Clearmode[17]八位字节流）协商为单独的有效负载类型。从计时的角度来看，这最容易在呼叫开始时完成，但会导致网关和介入网络中资源的过度分配。
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 bis、T.30或V.25控制序列开始的会话是一种可行的方法。
Named data-related events also allow gateways to optimize their operation when data signals are received in a relatively general form. One example is the use of V.8-related events to deduce that the voice-band data being sent in a G.711 payload comes from a higher-speed modem and therefore requires disabling of echo cancellers.
当以相对一般的形式接收数据信号时，命名的数据相关事件还允许网关优化其操作。一个例子是使用V.8相关事件推断G.711有效载荷中发送的声带数据来自高速调制解调器，因此需要禁用回声消除器。
All of the control procedures described in the sub-sections of Section 2 eventually give way to data content. As mentioned above, this content will be carried by other payload types. Receiving gateways MUST be prepared to switch to the other payload type within the time constraints associated with the respective applications. (For several of the procedures documented above, the sender provides 75 ms of silence between the initial control signalling and the sending of data content.) In some cases (V.8 bis [10], T.30 [8]), further control signalling may happen after the call has been established.
第2节小节中描述的所有控制程序最终都会让位给数据内容。如上所述，该内容将由其他有效负载类型承载。接收网关必须准备好在与相应应用程序相关的时间限制内切换到其他有效负载类型。（对于上面记录的几个过程，发送方在初始控制信令和发送数据内容之间提供75 ms的静默时间。）在某些情况下（V.8 bis[10]，T.30[8]），在建立呼叫后可能会发生进一步的控制信令。
A possible strategy is to send both the telephone-event and the data payload in an RFC 2198 [2] redundancy arrangement. The receiving gateway then propagates the data payload whenever no event is in progress. For this to work, the data payload and events (when present) MUST cover exactly the same content over the same time period; otherwise, spurious events will be detected downstream. An example of this mode of operation is shown below.
一种可能的策略是在RFC 2198[2]冗余安排中发送电话事件和数据有效载荷。然后，接收网关在没有任何事件进行时传播数据有效负载。要使其工作，数据有效负载和事件（如果存在）必须在同一时间段内覆盖完全相同的内容；否则，将在下游检测到虚假事件。该操作模式的示例如下所示。
Note that there are a number of cases where no control sequence will precede the data content. This is true, for example, for a number of legacy text terminal types. In such instances, the events defined in Section 2.7 in particular MAY be sent to help the remote gateway optimize its handling of the alternative payload.
请注意，在许多情况下，数据内容之前没有控制序列。例如，对于许多传统文本终端类型来说，这是正确的。在这种情况下，可以发送第2.7节中定义的事件，以帮助远程网关优化其对替代有效负载的处理。
This section presents an example of the use of the event codes defined in Section 2. The basic scenario is the startup sequence for duplex V.34 modem operation. It is assumed that once the initial V.8 sequence is complete, the gateways will enter into voice-band data operation using G.711 encoding to transmit the modem signals. The basic packet sequence is indicated in Table 9. Sample packets are then shown in detail for two variants on event transmission strategy:
本节介绍了第2节中定义的事件代码的使用示例。基本场景是双工V.34调制解调器操作的启动顺序。假设初始V.8序列完成后，网关将使用G.711编码进入声带数据操作，以传输调制解调器信号。基本数据包序列如表9所示。然后详细显示事件传输策略的两种变体的示例数据包：
o simultaneous transmission of events and retransmitted events using RFC 2198 [2] redundancy;
o 使用RFC 2198[2]冗余同时传输事件和重传事件；
o simultaneous transmission of events, retransmitted events, and voice-band data covering the same content using RFC 2198 redundancy.
o 使用RFC 2198冗余同时传输事件、重传事件和覆盖相同内容的声带数据。
For simplicity and semi-realism, the times shown for the example scenario assume a fixed lag at each gateway of 20 ms between the packet side of the gateway and the local user equipment and vice versa (i.e., minimum of 40 ms between packet received and packet sent specifically in response to the received packet). A propagation delay of 5 ms is assumed between gateways. It is assumed that the
为了简单和半现实，示例场景所示的时间假设网关的分组侧和本地用户设备之间的每个网关处的固定延迟为20ms，反之亦然（即，在接收到的分组和专门响应接收到的分组而发送的分组之间的最小延迟为40ms）。假定网关之间的传播延迟为5ms。假设
event packetization interval is 30 ms, a reasonable compromise between packet volume and buffering delay, particularly for V.21 events.
事件打包间隔为30毫秒，这是数据包容量和缓冲延迟之间的合理折衷，特别是对于V.21事件。
At the basic V.8 protocol level, the table assumes that the answering modem waits 0.2 s (200 ms) from the beginning of the call to start transmitting ANSam. The calling modem waits 1 s (1000 ms) from the time it begins to receive ANSam until it begins to send the V.8 CM signal. Both modems wait 75 ms from the time they finish sending and receiving CJ, respectively, until they begin sending V.34 modem signals.
在基本V.8协议级别，该表假设应答调制解调器从呼叫开始等待0.2秒（200毫秒）以开始传输ANSam。主叫调制解调器从开始接收ANSam到开始发送V.8厘米信号，等待1秒（1000毫秒）。两个调制解调器分别从完成发送和接收CJ起等待75 ms，直到开始发送V.34调制解调器信号。
+------------+------------------------------------------------------+
| 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. |
| | |
+------------+------------------------------------------------------+
| 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 | The called gateway issues its next-scheduled event |
| | report packet, indicating an initial report for |
| | /ANSam (M bit set, timestamp ts0 + 5360, duration |
| | 240 timestamp units). The packet also carries the |
| | first retransmission of the final ANSam report, |
| | total duration 3600 units, this time with the E bit |
| | set. |
| | |
| 1295.0 | The calling gateway begins to receive the CM signal |
| | from the calling modem. |
| | |
| 1325.0 | The calling gateway sends a packet containing the |
| | first 9 bits of the CM signal. |
| | |
| 1445.0 | The calling gateway sends out a packet containing |
| | the last 4 bits of the first CM signal, plus the |
| | first 5 bits of the next repetition of that signal. |
| | CM bits will continue to be transmitted from the |
| | calling gateway until 2015.0 ms (see below), for a |
| | total of 24 packets. (The final packet also carries |
| | the beginning of the CJ signal.) |
| | |
| 1596.7 | The called gateway completes playout of the final |
| | bit of the second occurrence of the CM signal. |
| | |
| 1636.7 | The called gateway detects end of /ANSam (and |
| | beginning of JM) from the called modem. The next |
| | packet is not yet due to go out. |
| | |
| 1660.0 | The called gateway sends out a packet combining the |
| | final /ANSam event report (E bit set and total |
| | duration 533 timestamp units) with the first 7 bits |
| | of the JM signal. The M bit for the packet is set |
| | and the packet timestamp is ts0 + 12560 (the start |
| | of the now-discontinued /ANSam event). |
| | |
| 1690.0 | The called gateway sends out a packet containing the |
| | next nine bits of JM signal. The M bit is set and |
| | the timestamp is ts0 + 13280 (beginning of the first |
| | bit in the packet). JM will continue to be |
| | transmitted until 2170.0 ms (see below), for a total |
| | of 18 packets (plus two for final retransmissions). |
| | |
| 1938.3 | The calling gateway completes playout of the final |
| | packet of the second occurrence of the JM signal. |
| | |
| 1995.0 | The calling gateway begins to receive the initial |
| | bits of the CJ signal. |
| | |
| 2015.0 | The calling gateway sends a packet containing the |
| | final 3 bits of the first decad of a CM signal and |
| | first 6 bits of a CJ signal. |
| | |
| 2095.0 | The calling gateway receives the last bit of the CJ |
| | signal. A period of silence lasting 75-ms begins at |
| | the called end. It is not yet time to send out an |
| | event report. |
| | |
| 2105.0 | The calling gateway sends out a packet containing |
| | the final 6 bits of the CJ signal. |
| | |
| 2130.0 | The called gateway finishes playing out the last CJ |
| | signal bit sent to it. |
| | |
| 2135.0 | The calling gateway sends a packet containing no new |
| | events, but retransmissions of the last 15 bits of |
| | the CJ signal (in two generations). |
| | |
| 2165.0 | The calling gateway sends out a packet containing no |
| | new events, but retransmissions of the final 6 bits |
| | of the CJ signal. |
| | |
| 2170.0 | The called gateway sends out the last packet |
| | containing bits of the JM signal (except for |
| | retransmissions). Note that according to the V.8 |
| | specification these bits do not in general complete |
| | a JM signal or even an "octet" of that signal |
| | (although they happen to do so in this example). A |
| | 75 ms period of silence begins at the called end. |
| | |
| 2170.0 | The calling gateway begins to receive V.34 |
| | signalling from the called modem. |
| | |
| 2175.0 | The calling gateway finishes playing out the last JM |
| | signal bit sent to it. |
| | |
| 2195.0 | The calling gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17360 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 200 8-bit samples. Packetization interval |
| | is shown here as continuing to be 30 ms. It could |
| | be less, but MUST NOT be more because that would |
| | make the silent period too long. |
| | |
| | |
| 2015.0 | The calling gateway sends a packet containing the |
| | final 3 bits of the first decad of a CM signal and |
| | first 6 bits of a CJ signal. |
| | |
| 2095.0 | The calling gateway receives the last bit of the CJ |
| | signal. A period of silence lasting 75-ms begins at |
| | the called end. It is not yet time to send out an |
| | event report. |
| | |
| 2105.0 | The calling gateway sends out a packet containing |
| | the final 6 bits of the CJ signal. |
| | |
| 2130.0 | The called gateway finishes playing out the last CJ |
| | signal bit sent to it. |
| | |
| 2135.0 | The calling gateway sends a packet containing no new |
| | events, but retransmissions of the last 15 bits of |
| | the CJ signal (in two generations). |
| | |
| 2165.0 | The calling gateway sends out a packet containing no |
| | new events, but retransmissions of the final 6 bits |
| | of the CJ signal. |
| | |
| 2170.0 | The called gateway sends out the last packet |
| | containing bits of the JM signal (except for |
| | retransmissions). Note that according to the V.8 |
| | specification these bits do not in general complete |
| | a JM signal or even an "octet" of that signal |
| | (although they happen to do so in this example). A |
| | 75 ms period of silence begins at the called end. |
| | |
| 2170.0 | The calling gateway begins to receive V.34 |
| | signalling from the called modem. |
| | |
| 2175.0 | The calling gateway finishes playing out the last JM |
| | signal bit sent to it. |
| | |
| 2195.0 | The calling gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17360 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 200 8-bit samples. Packetization interval |
| | is shown here as continuing to be 30 ms. It could |
| | be less, but MUST NOT be more because that would |
| | make the silent period too long. |
| | |
| 2200.0 | The called gateway sends a packet containing no new |
| | events, but retransmissions of the last 18 bits of |
| | the JM signal (in two generations). |
| | |
| 2225.0 | The calling gateway sends out the second packet of |
| | V.34 signalling as voice-band data (PCMU). |
| | Timestamp is ts0 + 17560 and M bit is not set. The |
| | packet contains 240 8-bit samples. |
| | |
| 2230.0 | The called gateway sends out a packet containing no |
| | new events, but retransmissions of the final 9 bits |
| | of the JM signal. |
| | |
| 2245.0 | The called gateway begins to receive V.34 signalling |
| | from the called modem. |
| | |
| 2255.0 | The calling gateway sends out a third packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17800 and M bit is not set. The packet |
| | contains 240 8-bit samples. |
| | |
| 2260.0 | The called gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17960 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 120 samples. Packetization interval is |
| | shown here as continuing to be 30 ms. It could be |
| | less, but MUST NOT be more because that would make |
| | the silent period too long. |
| | |
| . . . | . . . |
+------------+------------------------------------------------------+
| 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事件和重发事件的传输
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=audio 12343 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12345 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
This indicates two media streams, the first for G.711 (i.e., voice or voice-band data), the second for triply-redundant telephone events. As RFC 2198 notes, it is also possible for the sender to send telephone-event payloads without redundancy in the second stream, although the redundant form is the primary transmission mode. (It would be reasonable to send the interim ANSam reports without redundancy.) The set of telephone events supported includes the DTMF events (not relevant in this example), and all of the data events defined in this document. In fact, only event codes 34-35 and 37-40 are used in the example.
这表示两个媒体流，第一个用于G.711（即语音或声带数据），第二个用于三重冗余电话事件。如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冗余的使用以及显示事件报告的基本组成，第二分组报告JM信号位（由被调用网关在1690.0 ms发送）似乎是一个不错的选择。该数据包还将承载最终/ANSam事件报告的第二次重传和JM信号初始7位的第一次重传。数据包的详细内容如图1所示。为了更清楚地看到连续几代的内容，将它们显示为在连续的32位边界上对齐。事实上，它们都偏移了一个八位组，从RFC 2198报头开始依次偏移。
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.
根据主数据块中多个事件编码的需要，在分组的RTP报头中设置M位。事实上，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 ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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块（第二次重传）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel) (first retransmission)
JM的前7位（=V.21高通道中的“1111111”）（第一次重传）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
JM的下9位（=V.21高通道中的“111000000”）（新内容）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 RFC 2198 Redundancy
4.2. 使用RFC 2198冗余同时传输事件和声带数据
Negotiation of the transmission mode being described in this section would use SDP similar to the following:
本节中描述的传输模式协商将使用类似于以下内容的SDP：
m=audio 12343 RTP/AVP 99 100 101
a=rtpmap:99 red/8000/1
a=fmtp:99 100/101/101/101
a=rtpmap:100 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
m=audio 12343 RTP/AVP 99 100 101
a=rtpmap:99 red/8000/1
a=fmtp:99 100/101/101/101
a=rtpmap:100 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
This indicates one media stream, with G.711 (i.e., voice or voice-band data) as the primary content, along with three blocks of telephone events. RFC 2198 requires that the more voluminous representation (i.e., the G.711) be the primary one. The most recent block of events covers the same time period as the voice-band data. The other two streams provide the first and second retransmissions of the events as in the previous example. Because G.711 is the primary content, the M bit for the packets will in general not be set, except after periods of silence.
这表示一个媒体流，以G.711（即语音或声带数据）为主要内容，以及三个电话事件块。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 ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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块（第二次重传）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel) (first retransmission)
JM的前7位（=V.21高通道中的“1111111”）（第一次重传）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
JM的下9位（=V.21高通道中的“111000000”）（新内容）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30 ms of G.711-encoded voice-band data (240 samples)
30毫秒G.711编码的声带数据（240个样本）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 1 | Sample 2 | Sample 3 | Sample 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 237 | Sample 238 | Sample 239 | Sample 240 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 1 | Sample 2 | Sample 3 | Sample 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 237 | Sample 238 | Sample 239 | Sample 240 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Packet Contents with Voice-Band Data Combined with Events
图2：语音带数据与事件组合的数据包内容
The V.21 bit events defined in this document may be used to transmit user-sensitive data. This could include initial log-on sequences and application-level protocol exchanges as well as user content. As a result, such a usage of V.21 bit events entails, in the terminology of [16], threats to both communications and system security. The attacks of concern are:
本文件中定义的V.21位事件可用于传输用户敏感数据。这可能包括初始登录序列、应用程序级协议交换以及用户内容。因此，用[16]的术语来说，V.21位事件的这种使用会对通信和系统安全造成威胁。令人关切的攻击是：
o confidentiality violations and password sniffing;
o 违反保密规定和密码嗅探；
o hijacking of data sessions through message insertion;
o 通过消息插入劫持数据会话；
o modification of the transmitted content through man-in-the-middle attacks;
o 通过中间人攻击修改传输内容；
o denial of service by means of message insertion, deletion, and modification aimed at interference with the application protocol.
o 通过消息插入、删除和修改的方式拒绝服务，旨在干扰应用程序协议。
To prevent these attacks, the transmission of V.21 bit events MUST be given confidentiality protection. Message authentication and the protection of message integrity MUST also be provided. These address the threats posed by message insertion and modification. With these measures in place, RTP sequence numbers and the redundancy provided by the RFC 4733 procedures for transmission of events add protection against and some resiliency in the face of message deletion.
为了防止这些攻击，必须对V.21位事件的传输进行保密保护。还必须提供消息身份验证和消息完整性保护。这些解决了消息插入和修改带来的威胁。有了这些措施，RTP序列号和RFC 4733程序为事件传输提供的冗余增加了针对消息删除的保护和一些弹性。
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
本文件中定义的其他事件（以及控制序列中的V.21位事件）仅用于设置和控制数据终端或传真设备之间的会话。虽然这些事件的披露不会暴露用户敏感数据，但可能会暴露用户设备的功能，这些功能可能被PSTN域中的攻击所利用。因此，应提供保密保护。主要威胁是拒绝服务，通过在控制序列的易受攻击点注入不适当的信号，或通过更改或阻止足够的事件
packets to disrupt that sequence. To meet the injection threat, message authentication and integrity protection MUST be provided.
数据包来破坏该序列。为了应对注入威胁，必须提供消息身份验证和完整性保护。
The Secure Real-time Transport Protocol (SRTP) [3] meets the requirements for protection of confidentiality, message integrity, and message authentication described above. It SHOULD therefore be used to protect media streams containing the events described in this document.
安全实时传输协议（SRTP）[3]满足上述保密性、消息完整性和消息认证的保护要求。因此，应使用它来保护包含本文档中所述事件的媒体流。
Note that the appropriate method of key distribution for SRTP may vary with the specific application.
请注意，SRTP的适当密钥分配方法可能因具体应用而异。
In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP.
在某些部署中，最好使用其他方式提供与SRTP提供的保护等效的保护。
This document adds the events in Table 10 to the registry established by RFC 4733 [5].
本文件将表10中的事件添加到RFC 4733[5]建立的注册表中。
+-------+--------------------------------------------+--------------+
| Event | Event Name | Reference |
| Code | | |
+-------+--------------------------------------------+--------------+
| 23 | CRdSeg: second segment of V.8 bis CRd | RFC 4734 |
| | signal | |
| | | |
| 24 | CReSeg: second segment of V.8 bis CRe | RFC 4734 |
| | signal | |
| | | |
| 25 | MRdSeg: second segment of V.8 bis MRd | RFC 4734 |
| | signal | |
| | | |
| 26 | MReSeg: second segment of V.8 bis MRe | RFC 4734 |
| | signal | |
| | | |
| 27 | V32AC: A pattern of bits modulated at 4800 | RFC 4734 |
| | bits/s, emitted by a V.32/V.32bis | |
| | answering terminal upon detection of the | |
| | AA pattern. | |
| | | |
| 28 | V8bISeg: first segment of initiating V.8 | RFC 4734 |
| | bis signal | |
| | | |
| 29 | V8bRSeg: first segment of responding V.8 | RFC 4734 |
| | bis signal | |
| | | |
+-------+--------------------------------------------+--------------+
| 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 bits/s low channel V.21 | RFC 4734 |
| | indication | |
| | | |
| 31 | V21H300: 300 bits/s high channel V.21 | RFC 4734 |
| | indication | |
| | | |
| 32 | ANS (V.25 Answer tone). Also known as CED | RFC 4734 |
| | (T.30 Called tone). | |
| | | |
| 33 | /ANS (V.25 Answer tone after phase shift). | RFC 4734 |
| | Also known as /CED (T.30 Called tone after | |
| | phase shift) | |
| | | |
| 34 | ANSam (V.8 amplitude modified Answer tone) | RFC 4734 |
| | | |
| 35 | /ANSam (V.8 amplitude modified Answer tone | RFC 4734 |
| | after phase shift) | |
| | | |
| 36 | CNG (T.30 Calling tone) | RFC 4734 |
| | | |
| 37 | V.21 channel 1 (low channel), '0' bit | RFC 4734 |
| | | |
| 38 | V.21 channel 1, '1' bit. Also used for | RFC 4734 |
| | ESiSeg (second segment of V.8 bis ESi | |
| | signal). | |
| | | |
| 39 | V.21 channel 2, '0' bit | RFC 4734 |
| | | |
| 40 | V.21 channel 2, '1' bit. Also used for | RFC 4734 |
| | ESrSeg (second segment of V.8 bis ESr | |
| | signal). | |
| | | |
| 49 | CT (V.25 Calling Tone) | RFC 4734 |
| | | |
| 52 | ANS2225: 2225-Hz indication for text | RFC 4734 |
| | telephony | |
| | | |
| 53 | CI (V.8 Call Indicator signal preamble) | RFC 4734 |
| | | |
| 54 | V.21 preamble flag (T.30) | RFC 4734 |
| | | |
| 55 | V21L110: 110 bits/s V.21 indication for | RFC 4734 |
| | text telephony | |
| | | |
| 56 | B103L300: Bell 103 low channel indication | RFC 4734 |
| | for text telephony | |
| | | |
| 57 | V23Main: V.23 main channel indication for | RFC 4734 |
| | text telephony | |
| | | |
| 58 | V23Back: V.23 back channel indication for | RFC 4734 |
| | text telephony | |
| | | |
| 59 | Baud4545: 45.45 bits/s Baudot indication | RFC 4734 |
| | for text telephony | |
| | | |
| 60 | Baud50: 50 bits/s Baudot indication for | RFC 4734 |
| | text telephony | |
| | | |
| 61 | VBDGen: Tone patterns indicative of use of | RFC 4734 |
| | an unidentified modem type | |
| | | |
| 62 | XCIMark: A pattern of bits modulated in | RFC 4734 |
| | the V.23 main channel, emitted by a V.18 | |
| | calling terminal. | |
| | | |
| 63 | V32AA: A pattern of bits modulated at 4800 | RFC 4734 |
| | bits/s, emitted by a V.32/V.23bis calling | |
| | terminal. | |
+-------+--------------------------------------------+--------------+
| 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.
Scott Petrack是RFC 2833的原始作者。Henning Schulzrinne后来借出了他的专业知识来完成该文档，但必须归功于Scott在IP上对音调进行紧凑编码的想法背后的能量。
Gunnar Hellstrom and Keith Chu provided particularly useful comments helping to shape the present document. Amiram Allouche and Ido Benda drew the authors' attention to the value of including events for V.32/V.32bis in the document, and Yaakov Stein confirmed details of operation of this modem.
Gunnar Hellstrom和Keith Chu提供了特别有用的意见，有助于形成本文件。阿米拉姆·阿洛切（Amiram Allouche）和伊多·本达（Ido Benda）提请作者注意将V.32/V.32bis事件包含在文件中的价值，雅科夫·斯坦（Yaakov Stein）确认了该调制解调器的操作细节。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[2] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[3] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[4] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[5] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[5] Schulzrinne，H.和T.Taylor，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 47332006年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] 国际电信联盟，“在文本电话模式下运行的{DCE的操作和互通要求”，ITU-T建议V.18，2000年11月。
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] 国际电信联盟，“通用交换电话网中使用的标准化300比特/秒双工调制解调器”，ITU-T建议V.21，1988年11月。
[13] International Telecommunication Union, "Automatic answering equipment and general procedures for automatic calling equipment on the general switched telephone network including procedures for disabling of echo control devices for both manually and automatically established calls", ITU-T Recommendation V.25, October 1996.
[13] 国际电信联盟，“自动应答设备和通用交换电话网络上自动呼叫设备的一般程序，包括手动和自动建立呼叫的回声控制装置禁用程序”，ITU-T建议V.25，1996年10月。
See also Corrigendum 1 to Recommendation V.25, Jul. 2001.
另见建议V.25更正1，2001年7月。
[14] International Telecommunication Union, "A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use on the general switched telephone network and on leased telephone-type circuits", ITU-T Recommendation V.32, March 1993.
[14] 国际电信联盟，“以高达9600比特/秒的数据信令速率运行的一系列2线双工调制解调器，用于一般交换电话网络和租用电话型电路”，ITU-T建议V.32，1993年3月。
[15] International Telecommunication Union, "A duplex modem operating at data signalling rates of up to 14 400 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits", ITU-T Recommendation V.32bis, February 1991.
[15] 国际电信联盟，“在一般交换电话网络和租用的点对点2线电话型电路上以高达14 400比特/秒的数据信令速率运行的双工调制解调器”，ITU-T建议V.32bis，1991年2月。
[16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[16] Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[17] Kreuter，R.，“64 kbit/s透明呼叫的RTP有效负载格式”，RFC 4040，2005年4月。
[18] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[18] Hellstrom，G.和P.Jones，“文本对话的RTP有效载荷”，RFC 4103，2005年6月。
[19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
[19] 国际电信联盟，“语音频率的脉冲编码调制（PCM）”，ITU-T建议G.711，1988年11月。
[20] International Telecommunication Union, "Terminal for low bit-rate multimedia communication", ITU-T Recommendation H.324, March 2002.
[20] 国际电信联盟，“低比特率多媒体通信终端”，ITU-T建议H.324，2002年3月。
[21] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
[21] 国际电信联盟，“通过IP网络进行实时第3组传真通信的程序”，ITU-T建议T.38，2003年7月。
[22] International Telecommunication Union, "International interworking for videotex services", ITU-T Recommendation T.101, November 1994.
[22] 国际电信联盟，“可视图文服务的国际互通”，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] 国际电信联盟，“速率高达14 400比特/秒的传真应用的双线调制解调器”，ITU-T建议V.17，1991年2月。
[25] International Telecommunication Union, "600/1200-baud modem standardized for use in the general switched telephone network", ITU-T Recommendation V.23, November 1988.
[25] 国际电信联盟，“通用交换电话网使用的标准化600/1200波特调制解调器”，ITU-T建议V.23，1988年11月。
[26] International Telecommunication Union, "4800/2400 bits per second modem standardized for use in the general switched telephone network", ITU-T Recommendation V.27ter, November 1988.
[26] 国际电信联盟，“用于一般交换电话网的标准化4800/2400比特/秒调制解调器”，ITU-T建议V.27ter，1988年11月。
[27] International Telecommunication Union, "9600 bits per second modem standardized for use on point-to-point 4-wire leased telephone-type circuits", ITU-T Recommendation V.29, November 1988.
[27] 国际电信联盟，“用于点对点4线租用电话型电路的标准化9600比特/秒调制解调器”，ITU-T建议V.29，1988年11月。
[28] International Telecommunication Union, "A modem operating at data signalling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits", ITU-T Recommendation V.34, February 1998.
[28] 国际电信联盟，“在一般交换电话网络和租用的点对点双线电话电路上使用的数据信令速率高达33 600比特/秒的调制解调器”，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] 国际电信联盟，“在公共交换电话网（PSTN）上使用的数字调制解调器和模拟调制解调器对，下行数据信令速率高达56000比特/秒，上行数据信令速率高达33600比特/秒”，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线电路交换连接和租用的点对点4线数字电路上以高达64000位/秒的数据信令速率运行的数字调制解调器”，ITU-T建议V.91，1999年5月。
[31] International Telecommunication Union, "Enhancements to Recommendation V.90", ITU-T Recommendation V.92, November 2000.
[31] 国际电信联盟，“加强建议V.90”，ITU-T建议V.92，2000年11月。
[32] International Telecommunication Union, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs", ITU-T Recommendation V.150.1, January 2003.
[32] 国际电信联盟，“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号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
Tom Taylor Nortel 1852加拿大安大略省渥太华洛林大道K1H 6Z8
EMail: taylor@nortel.com
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。