Network Working Group H. Schulzrinne
Request for Comments: 2833 Columbia University
Category: Standards Track S. Petrack
MetaTel
May 2000
Network Working Group H. Schulzrinne
Request for Comments: 2833 Columbia University
Category: Standards Track S. Petrack
MetaTel
May 2000
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
DTMF数字、电话音和电话信号的RTP有效负载
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
本备忘录描述了如何在RTP数据包中传输双音多频（DTMF）信号、其他音信号和电话事件。
1 Introduction
1导言
This memo defines two payload formats, one for carrying dual-tone multifrequency (DTMF) digits, other line and trunk signals (Section 3), and a second one for general multi-frequency tones in RTP [1] packets (Section 4). Separate RTP payload formats are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate.
本备忘录定义了两种有效载荷格式，一种用于承载双音多频（DTMF）数字、其他线路和中继信号（第3节），另一种用于RTP[1]数据包中的一般多频音（第4节）。单独的RTP有效载荷格式是可取的，因为低速率语音编解码器不能保证足够准确地再现这些音调信号，以实现自动识别。定义单独的有效负载格式还允许更高的冗余，同时保持较低的比特率。
The payload formats described here may be useful in at least three applications: DTMF handling for gateways and end systems, as well as "RTP trunks". In the first application, the Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway likely has the necessary digital signal processors and algorithms, as it often needs to detect DTMF, e.g., for two-stage dialing. Having the gateway detect tones relieves the receiving Internet end system from having to do this work and also avoids that low bit-rate codecs like G.723.1 render DTMF tones unintelligible. Secondly, an Internet
这里描述的有效负载格式至少在三种应用中有用：网关和终端系统的DTMF处理，以及“RTP中继”。在第一个应用中，互联网电话网关检测输入电路上的DTMF，并发送此处描述的RTP有效载荷，而不是常规音频分组。网关可能具有必要的数字信号处理器和算法，因为它通常需要检测DTMF，例如两级拨号。使用网关检测音调可以免除接收互联网终端系统的这项工作，还可以避免像G.723.1这样的低比特率编解码器导致DTMF音调无法理解。第二，互联网
end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver.
终端系统（如“互联网电话”）可以模拟DTMF功能，而无需考虑生成精确的音调对，也无需将音调识别的负担强加给接收器。
In the "RTP trunk" application, RTP is used to replace a normal circuit-switched trunk between two nodes. This is particularly of interest in a telephone network that is still mostly circuit-switched. In this case, each end of the RTP trunk encodes audio channels into the appropriate encoding, such as G.723.1 or G.729. However, this encoding process destroys in-band signaling information which is carried using the least-significant bit ("robbed bit signaling") and may also interfere with in-band signaling tones, such as the MF digit tones. In addition, tone properties such as the phase reversals in the ANSam tone, will not survive speech coding. Thus, the gateway needs to remove the in-band signaling information from the bit stream. It can now either carry it out-of-band in a signaling transport mechanism yet to be defined, or it can use the mechanism described in this memorandum. (If the two trunk end points are within reach of the same media gateway controller, the media gateway controller can also handle the signaling.) Carrying it in-band may simplify the time synchronization between audio packets and the tone or signal information. This is particularly relevant where duration and timing matter, as in the carriage of DTMF signals.
在“RTP中继”应用程序中，RTP用于替换两个节点之间的正常电路交换中继。这在仍然主要是电路交换的电话网络中尤其令人感兴趣。在这种情况下，RTP中继线的每一端将音频信道编码为适当的编码，例如G.723.1或G.729。然而，该编码过程破坏使用最低有效位（“抢位信令”）携带的带内信令信息，并且还可能干扰带内信令音调，例如MF数字音调。此外，音调属性（如ANSam音调中的相位反转）将无法在语音编码中存活。因此，网关需要从比特流中移除带内信令信息。它现在可以在尚未定义的信令传输机制中进行带外传输，也可以使用本备忘录中描述的机制。（如果两个中继端点在同一媒体网关控制器的可达范围内，媒体网关控制器也可以处理信令。）带内携带它可以简化音频分组与音调或信号信息之间的时间同步。这在持续时间和定时很重要的情况下尤其重要，例如在DTMF信号的传输中。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[2]中的描述进行解释，并表示符合性实施的要求级别。
2 Events vs. Tones
2事件与音调
A gateway has two options for handling DTMF digits and events. First, it can simply measure the frequency components of the voice band signals and transmit this information to the RTP receiver (Section 4). In this mode, the gateway makes no attempt to discern the meaning of the tones, but simply distinguishes tones from speech signals.
网关有两个用于处理DTMF数字和事件的选项。首先，它可以简单地测量声带信号的频率分量，并将该信息传输到RTP接收器（第4节）。在这种模式下，网关不试图辨别音调的含义，而只是将音调与语音信号区分开来。
All tone signals in use in the PSTN and meant for human consumption are sequences of simple combinations of sine waves, either added or modulated. (There is at least one tone, the ANSam tone [3] used for indicating data transmission over voice lines, that makes use of periodic phase reversals.)
PSTN中使用的、供人使用的所有音调信号都是正弦波的简单组合序列，可以是添加的，也可以是调制的。（至少有一种音调，即ANSam音调[3]，用于指示语音线路上的数据传输，它利用周期性相位反转。）
As a second option, a gateway can recognize the tones and translate them into a name, such as ringing or busy tone. The receiver then produces a tone signal or other indication appropriate to the signal.
作为第二种选择，网关可以识别铃声并将其转换为名称，如铃声或忙音。然后，接收器产生适合于该信号的音调信号或其它指示。
Generally, since the recognition of signals often depends on their on/off pattern or the sequence of several tones, this recognition can take several seconds. On the other hand, the gateway may have access to the actual signaling information that generates the tones and thus can generate the RTP packet immediately, without the detour through acoustic signals.
通常，由于信号的识别通常取决于其开/关模式或多个音调的序列，因此该识别可能需要几秒钟。另一方面，网关可以访问生成音调的实际信令信息，因此可以立即生成RTP分组，而无需绕道声音信号。
In the phone network, tones are generated at different places, depending on the switching technology and the nature of the tone. This determines, for example, whether a person making a call to a foreign country hears her local tones she is familiar with or the tones as used in the country called.
在电话网络中，根据切换技术和音调的性质，在不同的位置生成音调。例如，这决定了打电话到外国的人是否听到了她熟悉的当地音调或在被呼叫国家使用的音调。
For analog lines, dial tone is always generated by the local switch. ISDN terminals may generate dial tone locally and then send a Q.931 SETUP message containing the dialed digits. If the terminal just sends a SETUP message without any Called Party digits, then the switch does digit collection, provided by the terminal as KEYPAD messages, and provides dial tone over the B-channel. The terminal can either use the audio signal on the B-channel or can use the Q.931 messages to trigger locally generated dial tone.
对于模拟线路，拨号音始终由本地交换机生成。ISDN终端可在本地生成拨号音，然后发送包含拨号数字的Q.931设置消息。如果终端只发送一条没有任何被叫方数字的设置消息，则交换机进行数字采集，由终端作为键盘消息提供，并通过B通道提供拨号音。终端可以使用B通道上的音频信号，也可以使用Q.931消息触发本地生成的拨号音。
Ringing tone (also called ringback tone) is generated by the local switch at the callee, with a one-way voice path opened up as soon as the callee's phone rings. (This reduces the chance of clipping the called party's response just after answer. It also permits pre-answer announcements or in-band call-progress indications to reach the caller before or in lieu of a ringing tone.) Congestion tone and special information tones can be generated by any of the switches along the way, and may be generated by the caller's switch based on ISUP messages received. Busy tone is generated by the caller's switch, triggered by the appropriate ISUP message, for analog instruments, or the ISDN terminal.
铃声（也称回铃音）由被叫方的本地交换机生成，被叫方的电话一响，单向语音路径就会打开。（这减少了接听后立即切断被叫方响应的机会。它还允许接听前通知或带内通话进度指示在铃声之前或代替铃声到达呼叫者。）沿途的任何交换机都可以生成拥塞音和特殊信息音，并且可以由呼叫方的交换机根据接收到的ISUP消息生成。对于模拟仪表或ISDN终端，呼叫方交换机通过相应的ISUP消息触发，产生忙音。
Gateways which send signaling events via RTP MAY send both named signals (Section 3) and the tone representation (Section 4) as a single RTP session, using the redundancy mechanism defined in Section 3.7 to interleave the two representations. It is generally a good idea to send both, since it allows the receiver to choose the appropriate rendering.
通过RTP发送信令事件的网关可以使用第3.7节中定义的冗余机制将命名信号（第3节）和音调表示（第4节）作为单个RTP会话发送。通常最好同时发送这两种渲染，因为它允许接收者选择适当的渲染。
If a gateway cannot present a tone representation, it SHOULD send the audio tones as regular RTP audio packets (e.g., as payload format PCMU), in addition to the named signals.
如果网关不能呈现音调表示，则除了指定的信号外，还应将音频音调作为常规RTP音频包（例如，作为有效负载格式PCMU）发送。
3 RTP Payload Format for Named Telephone Events
3指定电话事件的RTP有效负载格式
The payload format for named telephone events described below is suitable for both gateway and end-to-end scenarios. In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN recreates the DTMF tones or other telephony events and injects them into the PSTN. Since, for example, DTMF digit recognition takes several tens of milliseconds, the first few milliseconds of a digit will arrive as regular audio packets. Thus, careful time and power (volume) alignment between the audio samples and the events is needed to avoid generating spurious digits at the receiver.
下面描述的命名电话事件的有效负载格式适用于网关和端到端场景。在网关场景中，将分组语音网络连接到PSTN的Internet电话网关重新创建DTMF音调或其他电话事件，并将它们注入PSTN。例如，由于DTMF数字识别需要几十毫秒，因此数字的前几毫秒将作为常规音频数据包到达。因此，音频样本和事件之间需要仔细的时间和功率（音量）对齐，以避免在接收器处产生虚假数字。
DTMF digits and named telephone events are carried as part of the audio stream, and MUST use the same sequence number and time-stamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. The default clock frequency is 8,000 Hz, but the clock frequency can be redefined when assigning the dynamic payload type.
DTMF数字和命名电话事件作为音频流的一部分进行传输，并且必须使用与常规音频通道相同的序列号和时间戳，以简化网关上音频波形的生成。默认时钟频率为8000 Hz，但在分配动态有效负载类型时，可以重新定义时钟频率。
The payload format described here achieves a higher redundancy even in the case of sustained packet loss than the method proposed for the Voice over Frame Relay Implementation Agreement [4].
这里描述的有效载荷格式即使在持续分组丢失的情况下也比为帧中继实现协议[4]提出的方法实现更高的冗余。
If an end system is directly connected to the Internet and does not need to generate tone signals again, time alignment and power levels are not relevant. These systems rely on PSTN gateways or Internet end systems to generate DTMF events and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice-response (IVR) system.
如果终端系统直接连接到互联网，并且不需要再次生成音调信号，则时间对齐和功率水平不相关。这些系统依靠PSTN网关或互联网终端系统生成DTMF事件，而不执行自己的音频波形分析。这种系统的一个例子是因特网交互式语音应答（IVR）系统。
In circumstances where exact timing alignment between the audio stream and the DTMF digits or other events is not important and data is sent unicast, such as the IVR example mentioned earlier, it may be preferable to use a reliable control protocol rather than RTP packets. In those circumstances, this payload format would not be used.
在音频流和DTMF数字或其他事件之间的精确定时对准不重要并且数据是单播发送的情况下，例如前面提到的IVR示例，可能优选使用可靠的控制协议而不是RTP分组。在这些情况下，将不使用此有效负载格式。
A source MAY send events and coded audio packets for the same time instants, using events as the redundant encoding for the audio stream, or it MAY block outgoing audio while event tones are active and only send named events as both the primary and redundant encodings.
源可以使用事件作为音频流的冗余编码，为相同的时间瞬间发送事件和编码音频包，或者在事件音调处于活动状态时阻止传出音频，并且仅发送命名事件作为主编码和冗余编码。
Note that a period covered by an encoded tone may overlap in time with a period of audio encoded by other means. This is likely to occur at the onset of a tone and is necessary to avoid possible errors in the interpretation of the reproduced tone at the remote end. Implementations supporting this payload format must be prepared to handle the overlap. It is RECOMMENDED that gateways only render the encoded tone since the audio may contain spurious tones introduced by the audio compression algorithm. However, it is anticipated that these extra tones in general should not interfere with recognition at the far end.
注意，编码音调所覆盖的时段可能与通过其他方式编码的音频时段在时间上重叠。这可能发生在音调开始时，并且对于避免远端再现音调的解释中可能出现的错误是必要的。支持此有效负载格式的实现必须准备好处理重叠。建议网关仅呈现编码音调，因为音频可能包含音频压缩算法引入的伪音调。然而，预计这些额外的音调通常不会干扰远端的识别。
This payload format is used for five different types of signals:
此有效负载格式用于五种不同类型的信号：
o DTMF tones (Section 3.10);
o 双音多频音（第3.10节）；
o fax-related tones (Section 3.11);
o 传真相关铃声（第3.11节）；
o standard subscriber line tones (Section 3.12);
o 标准用户线路音调（第3.12节）；
o country-specific subscriber line tones (Section 3.13) and;
o 特定国家/地区的用户线路音调（第3.13节）和；
o trunk events (Section 3.14).
o 中继事件（第3.14节）。
A compliant implementation MUST support the events listed in Table 1 with the exception of "flash". If it uses some other, out-of-band mechanism for signaling line conditions, it does not have to implement the other events.
合规实施必须支持表1中列出的事件，但“闪存”除外。如果它使用一些其他带外机制来发送线路条件的信号，则不必实现其他事件。
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 3.9 specifies how an implementation can use the SDP "fmtp" parameter within an SDP description to indicate its inability to understand a particular event or range of events.
在某些情况下，实现可能只是忽略某些在特定环境中没有意义的事件，例如传真音。第3.9节规定了实现如何在SDP描述中使用SDP“fmtp”参数，以表明其无法理解特定事件或事件范围。
Depending on the available user interfaces, an implementation MAY render all tones in Table 5 the same or, preferably, use the tones conveyed by the concurrent "tone" payload or other RTP audio payload. Alternatively, it could provide a textual representation.
取决于可用的用户界面，实现可以使表5中的所有音调相同，或者，优选地，使用由并发“音调”有效载荷或其他RTP音频有效载荷传送的音调。或者，它可以提供文本表示。
Note that end systems that emulate telephones only need to support the events described in Sections 3.10 and 3.12, while systems that receive trunk signaling need to implement those in Sections 3.10, 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line" signals. Systems that do not support fax or modem functionality do not need to render fax-related events described in Section 3.11.
请注意，模拟电话的终端系统只需要支持第3.10节和第3.12节中描述的事件，而接收中继信号的系统需要实现第3.10节、第3.11节、第3.12节和第3.14节中描述的事件，因为MF中继也携带大多数“线路”信号。不支持传真或调制解调器功能的系统不需要呈现第3.11节中描述的传真相关事件。
The RTP payload format is designated as "telephone-event", the MIME type as "audio/telephone-event". The default timestamp rate is 8000 Hz, but other rates may be defined. In accordance with current practice, this payload format does not have a static payload type number, but uses a RTP payload type number established dynamically and out-of-band.
RTP有效负载格式指定为“电话事件”，MIME类型指定为“音频/电话事件”。默认时间戳速率为8000 Hz，但可以定义其他速率。根据当前实践，此有效负载格式没有静态有效负载类型编号，但使用动态和带外建立的RTP有效负载类型编号。
Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 3.5 extends forwards from that time. The receiver calculates jitter for RTCP receiver reports based on all packets with a given timestamp. Note: The jitter value should primarily be used as a means for comparing the reception quality between two users or two time-periods, not as an absolute measure.
时间戳：RTP时间戳反映当前数据包的测量点。第3.5节中描述的事件持续时间从该时间开始向前延伸。接收器根据具有给定时间戳的所有数据包计算RTCP接收器报告的抖动。注：抖动值应主要用作比较两个用户或两个时间段之间接收质量的方法，而不是绝对测量值。
Marker bit: The RTP marker bit indicates the beginning of a new event.
标记位：RTP标记位表示新事件的开始。
The payload format is shown in Fig. 1.
有效载荷格式如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Payload Format for Named Events
图1：命名事件的有效负载格式
events: The events are encoded as shown in Sections 3.10 through 3.14.
事件：事件编码如第3.10节至第3.14节所示。
volume: For DTMF digits and other events representable as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, larger values denote lower volume. This value is defined only for DTMF digits. For other events, it is set to zero by the sender and is ignored by the receiver.
音量：对于DTMF数字和其他可表示为音调的事件，此字段描述音调的功率级别，在删除符号后以dBm0表示。功率级别范围从0到-63 dBm0。有效DTMF的范围为0到-36 dBm0（必须接受）；必须拒绝低于-55 dBm0（TR-TSY-000181，ITU-T Q.24A）。因此，值越大表示体积越小。此值仅为DTMF数字定义。对于其他事件，发送方将其设置为零，接收方将忽略它。
duration: Duration of this digit, in timestamp units. Thus, the event began at the instant identified by the RTP timestamp and has so far lasted as long as indicated by this parameter. The event may or may not have ended.
持续时间：此数字的持续时间，以时间戳为单位。因此，事件开始于RTP时间戳标识的瞬间，并且一直持续到该参数指示的时间。事件可能已经结束，也可能尚未结束。
For a sampling rate of 8000 Hz, this field is sufficient to express event durations of up to approximately 8 seconds.
对于8000 Hz的采样率，此字段足以表示高达约8秒的事件持续时间。
E: If set to a value of one, the "end" bit indicates that this packet contains the end of the event. Thus, the duration parameter above measures the complete duration of the event.
E：如果设置为值1，“结束”位表示此数据包包含事件的结束。因此，上面的持续时间参数度量事件的完整持续时间。
A sender MAY delay setting the end bit until retransmitting the last packet for a tone, rather than on its first transmission. This avoids having to wait to detect whether the tone has indeed ended.
发送方可以延迟设置结束位，直到重新传输音调的最后一个数据包，而不是在第一次传输时。这样可以避免等待检测音调是否确实结束。
Receiver implementations MAY use different algorithms to create tones, including the two described here. In the first, the receiver simply places a tone of the given duration in the audio playout buffer at the location indicated by the timestamp. As additional packets are received that extend the same tone, the waveform in the playout buffer is extended accordingly. (Care has to be taken if audio is mixed, i.e., summed, in the playout buffer rather than simply copied.) Thus, if a packet in a tone lasting longer than the packet interarrival time gets lost and the playout delay is short, a gap in the tone may occur. Alternatively, the receiver can start a tone and play it until it receives a packet with the "E" bit set, the next tone, distinguished by a different timestamp value or a given time period elapses. This is more robust against packet loss, but may extend the tone if all retransmissions of the last packet in an event are lost. Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless.
接收机实现可以使用不同的算法来创建音调，包括这里描述的两种算法。在第一种情况下，接收器简单地将给定持续时间的音调放置在时间戳指示的位置处的音频播放缓冲区中。当接收到扩展相同音调的附加分组时，播放缓冲器中的波形相应地扩展。（如果音频在播放缓冲区中混合，即相加，而不是简单地复制，则必须小心。）因此，如果持续时间长于数据包到达间隔时间的数据包丢失且播放延迟短，则可能会出现音频间隔。或者，接收器可以启动一个音调并播放它，直到它接收到设置了“E”位的分组，即下一个音调，通过不同的时间戳值或经过给定的时间段来区分。这对分组丢失更具鲁棒性，但如果事件中最后一个分组的所有重传丢失，则可能会延长音调。有必要限制延长音调的时间段，以避免音调“卡住”。无论使用哪种算法，音调扩展不应超过三个数据包间隔时间。轻微延长音调持续时间和缩短停顿通常是无害的。
R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it.
R：此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
An audio source SHOULD start transmitting event packets as soon as it recognizes an event and every 50 ms thereafter or the packet interval for the audio codec used for this session, if known. (The sender does not need to maintain precise time intervals between event packets in order to maintain precise inter-event times, since the timing information is contained in the timestamp.)
音频源应在识别到事件后立即开始传输事件数据包，此后每隔50毫秒或此会话所用音频编解码器的数据包间隔（如果已知）。（发送方不需要在事件包之间保持精确的时间间隔以保持精确的事件间时间，因为时间戳中包含定时信息。）
Q.24 [5], Table A-1, indicates that all administrations surveyed use a minimum signal duration of 40 ms, with signaling velocity (tone and pause) of no less than 93 ms.
Q.24[5]，表A-1表明，所有接受调查的管理机构使用的信号持续时间最小为40 ms，信号速度（音调和暂停）不小于93 ms。
If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly. (The RTP sequence number is incremented by one for each packet.) If there has been no new event in the last interval, the event SHOULD be retransmitted three times or until the next event is recognized. This ensures that the duration of the event can be recognized correctly even if the last packet for an event is lost.
如果事件持续时间超过一个周期，则生成事件的源应发送一个新的事件包，其中RTP时间戳值对应于事件的开始，并且事件的持续时间相应增加。（每个数据包的RTP序列号增加一个。）如果在最后一个间隔内没有新事件，则该事件应重新传输三次或直到识别出下一个事件。这确保即使事件的最后一个数据包丢失，也能正确识别事件的持续时间。
DTMF digits and events are sent incrementally to avoid having the receiver wait for the completion of the event. Since some tones are two seconds long, this would incur a substantial delay. The transmitter does not know if event length is important and thus needs to transmit immediately and incrementally. If the receiver application does not care about event length, the incremental transmission mechanism avoids delay. Some applications, such as gateways into the PSTN, care about both delays and event duration.
DTMF数字和事件以增量方式发送，以避免接收器等待事件完成。由于某些音调的长度为两秒，因此会导致严重延迟。发送器不知道事件长度是否重要，因此需要立即增量传输。如果接收器应用程序不关心事件长度，则增量传输机制可避免延迟。一些应用程序，例如进入PSTN的网关，关心延迟和事件持续时间。
During an event, the RTP event payload format provides incremental updates on the event. The error resiliency depends on the playout delay at the receiver. For example, for a playout delay of 120 ms and a packet gap of 50 ms, two packets in a row can get lost without causing a gap in the tones generated at the receiver.
在事件期间，RTP事件有效负载格式提供事件的增量更新。错误恢复能力取决于接收器的播放延迟。例如，对于120ms的播放延迟和50ms的分组间隔，一行中的两个分组可以丢失，而不会导致在接收器处生成的音调中的间隔。
The audio redundancy mechanism described in RFC 2198 [6] MAY be used to recover from packet loss across events. The effective data rate is r times 64 bits (32 bits for the redundancy header and 32 bits for the telephone-event payload) every 50 ms or r times 1280 bits/second, where r is the number of redundant events carried in each packet. The value of r is an implementation trade-off, with a value of 5 suggested.
RFC 2198[6]中描述的音频冗余机制可用于跨事件从分组丢失中恢复。有效数据速率为每50 ms r乘以64位（冗余报头为32位，电话事件有效载荷为32位）或r乘以1280位/秒，其中r是每个数据包中携带的冗余事件数。r的值是一种实现权衡，建议值为5。
The timestamp offset in this redundancy scheme has 14 bits, so that it allows a single packet to "cover" 2.048 seconds of telephone events at a sampling rate of 8000 Hz. Including the starting time of previous events allows precise reconstruction of the tone sequence at a gateway. The scheme is resilient to consecutive packet losses spanning this interval of 2.048 seconds or r digits, whichever is less. Note that for previous digits, only an average loudness can be represented.
此冗余方案中的时间戳偏移有14位，因此它允许单个数据包以8000 Hz的采样率“覆盖”2.048秒的电话事件。包括先前事件的开始时间允许在网关处精确地重建音调序列。该方案对跨越该间隔2.048秒或r位（以较小者为准）的连续数据包丢失具有弹性。请注意，对于前面的数字，只能表示平均响度。
An encoder MAY treat the event payload as a highly-compressed version of the current audio frame. In that mode, each RTP packet during an event would contain the current audio codec rendition (say, G.723.1 or G.729) of this digit as well as the representation described in Section 3.5, plus any previous events seen earlier.
编码器可将事件有效载荷视为当前音频帧的高度压缩版本。在该模式下，事件期间的每个RTP数据包将包含该数字的当前音频编解码器格式副本（例如，G.723.1或G.729）以及第3.5节中描述的表示，以及前面看到的任何先前事件。
This approach allows dumb gateways that do not understand this format to function. See also the discussion in Section 1.
这种方法允许不理解此格式的哑网关正常工作。另见第1节中的讨论。
A typical RTP packet, where the user is just dialing the last digit of the DTMF sequence "911". The first digit was 200 ms long (1600 timestamp units) and started at time 0, the second digit lasted 250 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp units), the third digit was pressed at time 1.4 s (11,200 timestamp units) and the packet shown was sent at 1.45 s (11,600 timestamp units). The frame duration is 50 ms. To make the parts recognizable, the figure below ignores byte alignment. Timestamp and sequence number are assumed to have been zero at the beginning of the first digit. In this example, the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the telephone event payload, respectively.
典型的RTP数据包，用户只需拨打DTMF序列“911”的最后一位。第一个数字长200毫秒（1600个时间戳单位），从时间0开始，第二个数字持续250毫秒（2000个时间戳单位），从时间800毫秒（6400个时间戳单位）开始，第三个数字在时间1.4秒（11200个时间戳单位）按下，显示的数据包以1.45秒（11600个时间戳单位）发送。帧持续时间为50毫秒。为了使部件可识别，下图忽略字节对齐。时间戳和序列号假定在第一个数字的开头为零。在此示例中，已分别为冗余机制和电话事件有效载荷分配了动态有效载荷类型96和97。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example RTP packet after dialing "911"
图2：拨打“911”后的RTP数据包示例
Receivers MAY indicate which named events they can handle, for example, by using the Session Description Protocol (RFC 2327 [7]). The payload formats use the following fmtp format to list the event values that they can receive:
接收者可以指示他们可以处理哪些命名事件，例如，通过使用会话描述协议（RFC 2327[7]）。有效负载格式使用以下fmtp格式列出它们可以接收的事件值：
a=fmtp:<format> <list of values>
a=fmtp:<format> <list of values>
The list of values consists of comma-separated elements, which can be either a single decimal number or two decimal numbers separated by a hyphen (dash), where the second number is larger than the first. No whitespace is allowed between numbers or hyphens. The list does not have to be sorted.
值列表由逗号分隔的元素组成，可以是单个十进制数，也可以是由连字符（破折号）分隔的两个十进制数，其中第二个数字大于第一个数字。数字或连字符之间不允许有空格。列表不必排序。
For example, if the payload format uses the payload type number 100, and the implementation can handle the DTMF tones (events 0 through 15) and the dial and ringing tones, it would include the following description in its SDP message:
例如，如果有效负载格式使用有效负载类型编号100，并且实现可以处理DTMF音调（事件0到15）以及拨号和铃声，则其SDP消息中将包括以下描述：
a=fmtp:100 0-15,66,70
a=fmtp:100 0-15,66,70
Since all implementations MUST be able to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL.
由于所有实现都必须能够接收事件0到15，因此在a=fmtp行中列出这些事件是可选的。
The corresponding MIME parameter is "events", so that the following sample media type definition corresponds to the SDP example above:
相应的MIME参数为“events”，因此以下示例媒体类型定义对应于上面的SDP示例：
audio/telephone-event;events="0-11,66,67";rate="8000"
audio/telephone-event;events="0-11,66,67";rate="8000"
Table 1 summarizes the DTMF-related named events within the telephone-event payload format.
表1总结了电话事件有效负载格式中与DTMF相关的命名事件。
Event encoding (decimal)
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16
Event encoding (decimal)
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16
Table 1: DTMF named events
表1：DTMF命名事件
Table 3.11 summarizes the events and tones that can appear on a subscriber line serving a fax machine or modem. The tones are described below, with additional detail in Table 7.
表3.11总结了服务于传真机或调制解调器的用户线路上可能出现的事件和音调。音调描述如下，更多细节见表7。
ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for data transmission [8,9]. For fax machines, Recommendation T.30 [9] refers to this tone as called terminal identification (CED) answer tone.
ANS：该2100+/-15 Hz音调用于禁用数据传输的回波抑制[8,9]。对于传真机，建议T.30[9]将此音调称为终端识别（CED）应答音。
/ANS: This is the same signal as ANS, except that it reverses phase at an interval of 450 +/- 25 ms. It disables both echo cancellers and echo suppressors. (In the ITU Recommendation V.25 [8], this signal is rendered as ANS with a bar on top.)
/ANS：这是与ANS相同的信号，只是它以450+/-25 ms的间隔反转相位。它同时禁用回声消除器和回声抑制器。（在ITU建议V.25[8]中，该信号呈现为顶部带有条形图的ANS。）
ANSam: The modified answer tone (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz without phase reversals, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone is sent by modems if network echo canceller disabling is not required.
ANSam：修改后的应答音（ANSam）[3]是2100+/-1 Hz的正弦波信号，无相位反转，由15+/-0.1 Hz的正弦波进行振幅调制。如果不需要禁用网络回声消除器，则调制解调器会发送此音。
/ANSam: The modified answer tone with phase reversals (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz with phase reversals at intervals of 450 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11] and faxes to disable echo suppressors.
/ANSam：带相位反转的修改应答音（ANSam）[3]是2100+/-1 Hz的正弦波信号，相位反转间隔为450+/-25 ms，振幅由15+/-0.1 Hz的正弦波调制。该音调[10,8]由调制解调器[11]和传真发送，以禁用回声抑制器。
CNG: After dialing the called fax machine's telephone number (and before it answers), the calling Group III fax machine (optionally) begins sending a CalliNG tone (CNG) consisting of an interrupted tone of 1100 Hz. [9]
CNG：在拨打被叫传真机的电话号码后（在应答之前），主叫组III传真机（可选）开始发送主叫音（CNG），包括1100 Hz的中断音。[9]
CRdi: Capabilities Request (CRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRdi is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to a CRe or MRe."
CRdi：能力请求（CRd），起始端，[12]是一个双音信号，其音调为1375 Hz和2002 Hz，持续400 ms，然后是1900 Hz的单音，持续100 ms。“此信号请求远程站从电话模式转换到信息传输模式，并请求远程站传输能力列表消息。特别是，CRdi在呼叫过程中由发起站发送，或在呼叫建立时由呼叫站响应CRe或MRe发送。”
CRdr: CRdr is the response tone to CRdi (see above). It consists of a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms.
CRdr:CRdr是对CRdi的响应音（见上文）。它由一个双音信号组成，在1529 Hz和2225 Hz下的音持续400 ms，然后是一个1900 Hz下的单音持续100 ms。
CRe: Capabilities Request (CRe) [12] is a dual-tone signal with tones at tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 400 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRe is sent by an automatic answering station at call establishment."
CRe:Capabilities Request（CRe）[12]是一种双音信号，其音调为1375 Hz和2002 Hz，持续时间为400 ms，然后是400 Hz的单音，持续时间为100 ms。“此信号请求远程站从电话模式转换到信息传输模式，并请求远程站传输能力列表消息。特别是，CRe由呼叫建立时的自动应答站发送。”
CT: "The calling tone [8] consists of a series of interrupted bursts of binary 1 signal or 1300 Hz, on for a duration of not less than 0.5 s and not more than 0.7 s and off for a duration of not less than 1.5 s and not more than 2.0 s." Modems not starting with the V.8 call initiation tone often use this tone.
CT：“呼叫音[8]由一系列中断的二进制1信号或1300 Hz突发组成，打开持续时间不小于0.5秒，不大于0.7秒，关闭持续时间不小于1.5秒，不大于2.0秒。”不以V.8呼叫起始音开始的调制解调器通常使用此音。
ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode. signal ESi is sent by the initiating station."
ESi:Escape Signal（ESi）[12]是一种双音信号，其音调为1375 Hz和2002 Hz，持续400 ms，随后为980 Hz，持续100 ms。“该信号要求远程站从电话模式转换到信息传输模式。信号ESi由始发站发送。”
ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1650 Hz for 100 ms. Same as ESi, but sent by the responding station.
ESr：逸出信号（ESr）[12]是一种双音信号，其音调为1529 Hz和2225 Hz，持续400 ms，然后是1650 Hz，持续100 ms。与ESi相同，但由响应站发送。
MRdi: Mode Request (MRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms followed by a single tone at 1150 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRd is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to an MRe." [12]
MRdi:Mode Request（MRd），起始侧，[12]是一个双音信号，其音调为1375 Hz和2002 Hz，持续400 ms，然后是1150 Hz的单音，持续100 ms。“此信号请求远程站从电话模式转换到信息传输模式，并请求远程站传输模式选择消息。特别是，信号MRd在呼叫过程中由发起站发送，或在呼叫建立时由呼叫站响应MRe发送。”[12]
MRdr: MRdr is the response tone to MRdi (see above). It consists of a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1150 Hz for 100 ms.
MRdr:MRdr是对MRdi的响应音（见上文）。它由一个双音信号组成，在1529 Hz和2225 Hz下的音持续400 ms，然后是一个在1150 Hz下的单音持续100 ms。
MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRe is sent by an automatic answering station at call establishment." [12]
MRe:Mode Request（MRe）[12]是一种双音信号，其音调为1375 Hz和2002 Hz，持续400 ms，然后是650 Hz的单音，持续100 ms。“此信号请求远程站从电话模式转换到信息传输模式，并请求远程站传输模式选择消息。特别是，信号MRe由呼叫建立时的自动应答站发送。”[12]
V.21: V.21 describes a 300 b/s full-duplex modem that employs frequency shift keying (FSK). It is used by Group 3 fax machines to exchange T.30 information. The calling transmits on channel 1 and receives on channel 2; the answering modem transmits on channel 2 and receives on channel 1. Each bit value has a distinct tone, so that V.21 signaling comprises a total of four distinct tones.
V.21:V.21描述了采用频移键控（FSK）的300 b/s全双工调制解调器。第3组传真机使用它来交换T.30信息。主叫在信道1上发射，在信道2上接收；应答调制解调器在通道2上传输，在通道1上接收。每个比特值都有一个不同的音调，因此V.21信令总共包括四个不同的音调。
In summary, procedures in Table 2 are used.
总之，使用表2中的程序。
Procedure indications
___________________________________________________
V.25 and V.8 ANS
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam
V.8, echo canceller disabled /ANSam
Procedure indications
___________________________________________________
V.25 and V.8 ANS
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam
V.8, echo canceller disabled /ANSam
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendations
表2:V.x建议中ANS、ANSam和/或ANSam的使用
Event encoding (decimal)
___________________________________________________
Answer tone (ANS) 32
/ANS 33
ANSam 34
/ANSam 35
Calling tone (CNG) 36
V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRdi 41
CRdr 42
CRe 43
ESi 44
ESr 45
MRdi 46
MRdr 47
MRe 48
CT 49
Event encoding (decimal)
___________________________________________________
Answer tone (ANS) 32
/ANS 33
ANSam 34
/ANSam 35
Calling tone (CNG) 36
V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRdi 41
CRdr 42
CRe 43
ESi 44
ESr 45
MRdi 46
MRdr 47
MRe 48
CT 49
Table 3: Data and fax named events
表3：数据和传真命名事件
Table 4 summarizes the events and tones that can appear on a subscriber line.
表4总结了用户线路上可能出现的事件和音调。
ITU Recommendation E.182 [13] defines when certain tones should be used. It defines the following standard tones that are heard by the caller:
ITU建议E.182[13]规定了何时应使用某些音调。它定义了呼叫者可以听到的以下标准音调：
Dial tone: The exchange is ready to receive address information.
拨号音：交换机已准备好接收地址信息。
PABX internal dial tone: The PABX is ready to receive address information.
PABX内部拨号音：PABX已准备好接收地址信息。
Special dial tone: Same as dial tone, but the caller's line is subject to a specific condition, such as call diversion or a voice mail is available (e.g., "stutter dial tone").
特殊拨号音：与拨号音相同，但呼叫者的线路受到特定条件的限制，例如呼叫转移或语音邮件可用（例如，“口吃拨号音”）。
Second dial tone: The network has accepted the address information, but additional information is required.
第二拨号音：网络已接受地址信息，但需要附加信息。
Ring: This named signal event causes the recipient to generate an alerting signal ("ring"). The actual tone or other indication used to render this named event is left up to the receiver. (This differs from the ringing tone, below, heard by the caller
响铃：此命名信号事件导致收件人生成警报信号（“响铃”）。用于呈现此命名事件的实际音调或其他指示将留给接收者。（这与下面来电者听到的铃声不同
Ringing tone: The call has been placed to the callee and a calling signal (ringing) is being transmitted to the callee. This tone is also called "ringback".
铃声：呼叫已发送给被叫方，并且正在向被叫方发送呼叫信号（铃声）。这种音调也称为“回音”。
Special ringing tone: A special service, such as call forwarding or call waiting, is active at the called number.
特殊铃声：特殊服务，如呼叫转接或呼叫等待，在被叫号码处处于活动状态。
Busy tone: The called telephone number is busy.
忙音：被叫电话号码正忙。
Congestion tone: Facilities necessary for the call are temporarily unavailable.
拥塞提示音：呼叫所需的设施暂时不可用。
Calling card service tone: The calling card service tone consists of 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), followed by 940 ms of 350 Hz and 440 Hz (U.S. dial tone), decaying exponentially with a time constant of 200 ms.
电话卡服务音：电话卡服务音由941 Hz和1477 Hz音（DTMF“#”）之和的60 ms组成，然后是350 Hz和440 Hz（美国拨号音）的940 ms，以指数形式衰减，时间常数为200 ms。
Special information tone: The callee cannot be reached, but the reason is neither "busy" nor "congestion". This tone should be used before all call failure announcements, for the benefit of automatic equipment.
特殊信息音：无法联系到被叫人，但原因既不是“忙”，也不是“拥挤”。为便于自动设备，在所有呼叫故障通知之前应使用此音调。
Comfort tone: The call is being processed. This tone may be used during long post-dial delays, e.g., in international connections.
舒适提示音：正在处理呼叫。此音可在长时间拨号后延迟期间使用，例如在国际连接中。
Hold tone: The caller has been placed on hold.
等待音：呼叫方已处于等待状态。
Record tone: The caller has been connected to an automatic answering device and is requested to begin speaking.
录音音：来电者已连接到自动应答设备，并被要求开始讲话。
Caller waiting tone: The called station is busy, but has call waiting service.
呼叫等待音：被叫站忙，但有呼叫等待服务。
Pay tone: The caller, at a payphone, is reminded to deposit additional coins.
付费铃声：在付费电话旁，来电者被提醒多存硬币。
Positive indication tone: The supplementary service has been activated.
正向指示音：补充业务已激活。
Negative indication tone: The supplementary service could not be activated.
负面指示音：无法激活补充业务。
Off-hook warning tone: The caller has left the instrument off-hook for an extended period of time.
摘机警告音：呼叫者已将乐器摘机很长一段时间。
The following tones can be heard by either calling or called party during a conversation:
通话中，主叫方或被叫方均可听到以下音调：
Call waiting tone: Another party wants to reach the subscriber.
呼叫等待音：另一方想要联系用户。
Warning tone: The call is being recorded. This tone is not required in all jurisdictions.
警告音：正在录制通话。并非所有司法管辖区都需要这种语气。
Intrusion tone: The call is being monitored, e.g., by an operator.
入侵提示音：呼叫正在被监听，例如由话务员监听。
CPE alerting signal: A tone used to alert a device to an arriving in-band FSK data transmission. A CPE alerting signal is a combined 2130 and 2750 Hz tone, both with tolerances of 0.5% and a duration of 80 to. 80 ms. The CPE alerting signal is used with ADSI services and Call Waiting ID services [14].
CPE警报信号：用于提醒设备到达带内FSK数据传输的音调。CPE警报信号是2130和2750 Hz的组合音调，两者的公差均为0.5%，持续时间为80到80秒。80毫秒。CPE警报信号与ADSI服务和呼叫等待ID服务一起使用[14]。
The following tones are heard by operators:
操作员可听到以下音调：
Payphone recognition tone: The person making the call or being called is using a payphone (and thus it is ill-advised to allow collect calls to such a person).
付费电话识别音：拨打电话或被呼叫的人正在使用付费电话（因此，允许对方付费电话打给这样的人是不明智的）。
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Table 4: E.182 line events
表4:E.182线路事件
Table 5 summarizes country-specific events and tones that can appear on a subscriber line.
表5总结了可能出现在用户线路上的特定于国家/地区的事件和音调。
Table 6 summarizes the events and tones that can appear on a trunk. Note that trunk can also carry line events (Section 3.12), as MF signaling does not include backward signals [15].
表6总结了主干上可能出现的事件和音调。请注意，中继线也可以传输线路事件（第3.12节），因为MF信号不包括反向信号[15]。
ABCD transitional: 4-bit signaling used by digital trunks. For N-state signaling, the first N values are used.
ABCD过渡：数字中继使用的4位信令。对于N状态信令，使用前N个值。
Event encoding (decimal)
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112
Event encoding (decimal)
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112
Table 5: Country-specific Line events
表5：特定国家的线路活动
The T1 ESF (extended super frame format) allows 2, 4, and 16 state signaling bit options. These signaling bits are named A, B, C, and D. Signaling information is sent as robbed bits in frames 6, 12, 18, and 24 when using ESF T1 framing. A D4 superframe only transmits 4-state signaling with A and B bits. On the CEPT E1 frame, all signaling is carried in timeslot 16, and two channels of 16-state (ABCD) signaling are sent per frame.
T1 ESF（扩展超级帧格式）允许2、4和16状态信令位选项。这些信令位被命名为A、B、C和D。当使用ESF T1帧时，信令信息在帧6、12、18和24中作为抢夺位发送。D4超帧仅传输具有A和B位的4态信令。在CEPT E1帧上，所有信令在时隙16中承载，并且每帧发送两个信道的16状态（ABCD）信令。
Since this information is a state rather than a changing signal, implementations SHOULD use the following triple-redundancy mechanism, similar to the one specified in ITU-T Rec. I.366.2 [16], Annex L. At the time of a transition, the same ABCD information is sent 3 times at an interval of 5 ms. If another transition occurs during this time, then this continues. After a period of no change, the ABCD information is sent every 5 seconds.
由于该信息是一种状态，而不是一种变化的信号，因此实施应使用以下三重冗余机制，类似于ITU-T Rec.I.366.2[16]附录L中规定的机制。在过渡时，相同的ABCD信息以5ms的间隔发送3次。如果在此期间发生另一个过渡，然后继续。在一段时间不变后，ABCD信息每5秒发送一次。
Wink: A brief transition, typically 120-290 ms, from on-hook (unseized) to off-hook (seized) and back to onhook, used by the incoming exchange to signal that the call address signaling can proceed.
眨眼：一种短暂的转换，通常为120-290毫秒，从挂机（未显示）到摘机（被占用）再回到挂机，由入局交换机用来发出呼叫地址信令可以继续的信号。
Incoming seizure: Incoming indication of call attempt (off-hook).
传入扣押：呼叫尝试的传入指示（摘机）。
Event encoding (decimal)
__________________________________________________
MF 0... 9 128...137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142...143
ABCD signaling (see below) 144...159
Wink 160
Wink off 161
Incoming seizure 162
Seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173
Event encoding (decimal)
__________________________________________________
MF 0... 9 128...137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142...143
ABCD signaling (see below) 144...159
Wink 160
Wink off 161
Incoming seizure 162
Seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173
Table 6: Trunk events
表6：中继事件
Seizure: Seizure by answering exchange, in response to outgoing seizure.
扣押：通过应答交换扣押，以回应传出扣押。
Unseize circuit: Transition of circuit from off-hook to on-hook at the end of a call.
未调整电路大小：在呼叫结束时，电路从挂机状态过渡到挂机状态。
Wink off: A brief transition, typically 100-350 ms, from off-hook (seized) to on-hook (unseized) and back to off-hook (seized). Used in operator services trunks.
眨眼：一个短暂的过渡，通常为100-350毫秒，从脱钩（卡住）到上钩（未显示），再回到脱钩（卡住）。用于运营商服务中继。
Continuity tone send: A tone of 2010 Hz.
连续性音调发送：2010 Hz的音调。
Continuity tone detect: A tone of 2010 Hz.
连续性音调检测：2010 Hz的音调。
Continuity test send: A tone of 1780 Hz is sent by the calling exchange. If received by the called exchange, it returns a "continuity verified" tone.
连续性测试发送：主叫交换机发送1780 Hz的音调。如果被呼叫的交换机接收到，它将返回“连续性验证”提示音。
Continuity verified: A tone of 2010 Hz. This is a response tone, used in dual-tone procedures.
连续性验证：音调为2010 Hz。这是一种响应音，用于双音程序。
4 RTP Payload Format for Telephony Tones
4用于电话铃声的RTP有效负载格式
As an alternative to describing tones and events by name, as described in Section 3, it is sometimes preferable to describe them by their waveform properties. In particular, recognition is faster than for naming signals since it does not depend on recognizing durations or pauses.
作为第3节中描述的按名称描述音调和事件的替代方法，有时最好通过其波形特性来描述音调和事件。特别是，识别比命名信号更快，因为它不依赖于识别持续时间或暂停。
There is no single international standard for telephone tones such as dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones or some of the other special tones, such as payphone recognition, call waiting or record tone. However, across all countries, these tones share a number of characteristics [17]:
对于电话铃声，如拨号音、铃声（回铃）、忙音、拥塞（“快忙”）、特别公告音或其他一些特殊铃声，如付费电话识别、呼叫等待或录音音，没有单一的国际标准。然而，在所有国家，这些音调都有一些共同的特征[17]：
o Telephony tones consist of either a single tone, the addition of two or three tones or the modulation of two tones. (Almost all tones use two frequencies; only the Hungarian "special dial tone" has three.) Tones that are mixed have the same amplitude and do not decay.
o 电话音调包括单音、两个或三个音调的相加或两个音调的调制。（几乎所有音调都使用两个频率；只有匈牙利的“特殊拨号音”有三个频率。）混合的音调具有相同的振幅且不会衰减。
o Tones for telephony events are in the range of 25 (ringing tone in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz. The telephone frequency range is limited to 3,400 Hz. (The piano has a range from 27.5 to 4186 Hz.)
o 电话事件的音调范围为25（安哥拉的铃声）至1800 Hz。CED是2100 Hz时使用的最高音调。电话频率范围限制为3400 Hz。（钢琴的频率范围为27.5至4186赫兹。）
o Modulation frequencies range between 15 (ANSam tone) to 480 Hz (Jamaica). Non-integer frequencies are used only for frequencies of 16 2/3 and 33 1/3 Hz. (These fractional frequencies appear to be derived from older AC power grid frequencies.)
o 调制频率范围在15（安萨姆音调）到480赫兹（牙买加）之间。非整数频率仅用于16 2/3和33 1/3 Hz的频率。（这些分数频率似乎来自较旧的交流电网频率。）
o Tones that are not continuous have durations of less than four seconds.
o 非连续音调的持续时间小于4秒。
o ITU Recommendation E.180 [18] notes that different telephone companies require a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%.
o ITU建议E.180[18]指出，不同的电话公司要求音调准确度在0.5%到1.5%之间。建议频率公差为1%。
As an aid to the implementor, Table 7 summarizes some common tones. The rows labeled "ITU ..." refer to the general recommendation of Recommendation E.180 [18]. Note that there are no specific guidelines for these tones. In the table, the symbol "+" indicates addition of
作为对实施者的帮助，表7总结了一些常见的音调。标有“ITU…”的行指建议E.180[18]的一般性建议。请注意，这些音调没有具体的指导原则。在表中，符号“+”表示添加了
the tones, without modulation, while "*" indicates amplitude modulation. The meaning of some of the tones is described in Section 3.12 or Section 3.11 (for V.21).
音调，无调制，而“*”表示振幅调制。第3.12节或第3.11节（第21节）描述了某些音调的含义。
Tone name frequency on period off period
______________________________________________________
CNG 1100 0.5 3.0
V.25 CT 1300 0.5 2.0
CED 2100 3.3 --
ANS 2100 3.3 --
ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
ITU dial tone 425 -- --
U.S. dial tone 350+440 -- --
______________________________________________________
ITU ringing tone 425 0.67--1.5 3--5
U.S. ringing tone 440+480 2.0 4.0
ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
Tone name frequency on period off period
______________________________________________________
CNG 1100 0.5 3.0
V.25 CT 1300 0.5 2.0
CED 2100 3.3 --
ANS 2100 3.3 --
ANSam 2100*15 3.3 --
V.21 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
ITU dial tone 425 -- --
U.S. dial tone 350+440 -- --
______________________________________________________
ITU ringing tone 425 0.67--1.5 3--5
U.S. ringing tone 440+480 2.0 4.0
ITU busy tone 425
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
Table 7: Examples of telephony tones
表7：电话铃声示例
Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 3.5 extends forwards from that time.
时间戳：RTP时间戳反映当前数据包的测量点。第3.5节中描述的事件持续时间从该时间开始向前延伸。
Based on the characteristics described above, this document defines an RTP payload format called "tone" that can represent tones consisting of one or more frequencies. (The corresponding MIME type is "audio/tone".) The default timestamp rate is 8,000 Hz, but other rates may be defined. Note that the timestamp rate does not affect the interpretation of the frequency, just the durations.
基于上述特征，本文档定义了一种称为“音调”的RTP有效载荷格式，该格式可以表示由一个或多个频率组成的音调。（对应的MIME类型为“音频/音调”。）默认时间戳速率为8000 Hz，但可以定义其他速率。请注意，时间戳速率不影响频率的解释，只影响持续时间。
In accordance with current practice, this payload format does not have a static payload type number, but uses a RTP payload type number established dynamically and out-of-band.
根据当前实践，此有效负载格式没有静态有效负载类型编号，但使用动态和带外建立的RTP有效负载类型编号。
It is shown in Fig. 3.
如图3所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Payload format for tones
图3：音调的有效负载格式
The payload contains the following fields:
有效负载包含以下字段：
modulation: The modulation frequency, in Hz. The field is a 9-bit unsigned integer, allowing modulation frequencies up to 511 Hz. If there is no modulation, this field has a value of zero.
调制：调制频率，单位为Hz。该字段为9位无符号整数，允许调制频率高达511 Hz。如果没有调制，该字段的值为零。
T: If the "T" bit is set (one), the modulation frequency is to be divided by three. Otherwise, the modulation frequency is taken as is.
T：如果设置了“T”位（一），则调制频率将除以三。否则，调制频率按原样取。
This bit allows frequencies accurate to 1/3 Hz, since modulation frequencies such as 16 2/3 Hz are in practical use.
该位允许频率精确到1/3 Hz，因为实际使用的调制频率如16 2/3 Hz。
volume: The power level of the tone, expressed in dBm0 after dropping the sign, with range from 0 to -63 dBm0. (Note: A preferred level range for digital tone generators is -8 dBm0 to -3 dBm0.)
音量：音调的功率级，在删除符号后以dBm0表示，范围从0到-63 dBm0。（注：数字音频发生器的首选电平范围为-8 dBm0至-3 dBm0。）
duration: The duration of the tone, measured in timestamp units. The tone begins at the instant identified by the RTP timestamp and lasts for the duration value.
持续时间：音调的持续时间，以时间戳单位度量。音调从RTP时间戳标识的瞬间开始，持续时间值。
The definition of duration corresponds to that for sample-based codecs, where the timestamp represents the sampling point for the first sample.
持续时间的定义与基于样本的编解码器的定义相对应，其中时间戳表示第一个样本的采样点。
frequency: The frequencies of the tones to be added, measured in Hz and represented as a 12-bit unsigned integer. The field size is sufficient to represent frequencies up to 4095 Hz,
频率：要添加的音调的频率，单位为Hz，表示为12位无符号整数。字段大小足以表示高达4095 Hz的频率，
which exceeds the range of telephone systems. A value of zero indicates silence. A single tone can contain any number of frequencies.
这超出了电话系统的范围。值为零表示静默。单音可以包含任意数量的频率。
R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it.
R：此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
This payload format uses the reliability mechanism described in Section 3.7.
该有效载荷格式使用第3.7节中描述的可靠性机制。
5 Combining Tones and Named Events
5组合音调和命名事件
The payload formats in Sections 3 and 4 can be combined into a single payload using the method specified in RFC 2198. Fig. 4 shows an example. In that example, the RTP packet combines two "tone" and one "telephone-event" payloads. The payload types are chosen arbitrarily as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the redundancy format has the dynamic payload type 96.
第3节和第4节中的有效载荷格式可以使用RFC 2198中规定的方法组合成单个有效载荷。图4示出了一个示例。在该示例中，RTP分组组合了两个“音调”和一个“电话事件”有效载荷。有效载荷类型可任意选择，分别为97和98，采样率为8000 Hz。这里，冗余格式具有动态有效负载类型96。
The packet represents a snapshot of U.S. ringing tone, 1.5 seconds (12,000 timestamp units) into the second "on" part of the 2.0/4.0 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) into the ring cycle. The 440 + 480 Hz tone of this second cadence started at RTP timestamp 48,000. Four seconds of silence preceded it, but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds (16383 timestamp units) can be represented. Even though the tone sequence is not complete, the sender was able to determine that this is indeed ringback, and thus includes the corresponding named event.
该数据包表示美国铃声的快照，在2.0/4.0秒节拍的第二个“开”部分中为1.5秒（12000个时间戳单位），即在响铃周期中为7.5秒（60000个时间戳单位）。第二个节奏的440+480 Hz音调从RTP时间戳48000开始。之前有四秒钟的静默，但由于RFC 2198只有14位偏移量，因此只能表示2.05秒（16383个时间戳单位）。即使音调序列不完整，发送方也能够确定这确实是回铃，因此包括相应的命名事件。
6 MIME Registration
6 MIME注册
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: telephone-event
MIME子类型名称：电话事件
Required parameters: none.
所需参数：无。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Combining tones and events in a single RTP packet
图4：在单个RTP数据包中组合音调和事件
Optional parameters: The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can either be a single integer or two integers separated by a hyphen. No white space is allowed in the argument. The integers designate the event numbers supported by the implementation. All implementations MUST support events 0 through 15, so that the parameter can be omitted if the implementation only supports these events.
可选参数：“events”参数列出了实现支持的事件。事件以一个或多个逗号分隔的元素列出。每个元素可以是单个整数，也可以是由连字符分隔的两个整数。参数中不允许有空格。整数指定实现支持的事件编号。所有实现都必须支持事件0到15，因此，如果实现仅支持这些事件，则可以省略该参数。
The "rate" parameter describes the sampling rate, in Hertz. The number is written as a floating point number or as an integer. If omitted, the default value is 8000 Hz.
“速率”参数描述采样速率，单位为赫兹。该数字被写为浮点数或整数。如果省略，默认值为8000 Hz。
Encoding considerations: This type is only defined for transfer via RTP [1].
编码注意事项：此类型仅为通过RTP[1]传输而定义。
Security considerations: See the "Security Considerations" (Section 7) section in this document.
安全注意事项：请参阅本文件中的“安全注意事项”（第7节）一节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: This document.
已发布规范：本文件。
Applications which use this media: The telephone-event audio subtype supports the transport of events occurring in telephone systems over the Internet.
使用此媒体的应用程序：电话事件音频子类型支持通过Internet传输电话系统中发生的事件。
Additional information:
其他信息：
1. Magic number(s): N/A
1. 幻数：不适用
2. File extension(s): N/A
2. 文件扩展名：不适用
3. Macintosh file type code: N/A
3. Macintosh文件类型代码：不适用
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: tone
MIME子类型名称：tone
Required parameters: none
所需参数：无
Optional parameters: The "rate" parameter describes the sampling rate, in Hertz. The number is written as a floating point number or as an integer. If omitted, the default value is 8000 Hz.
可选参数：“速率”参数描述采样速率，单位为赫兹。该数字被写为浮点数或整数。如果省略，默认值为8000 Hz。
Encoding considerations: This type is only defined for transfer via RTP [1].
编码注意事项：此类型仅为通过RTP[1]传输而定义。
Security considerations: See the "Security Considerations" (Section 7) section in this document.
安全注意事项：请参阅本文件中的“安全注意事项”（第7节）一节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: This document.
已发布规范：本文件。
Applications which use this media: The tone audio subtype supports the transport of pure composite tones, for example those commonly used in the current telephone system to signal call progress.
使用此媒体的应用程序：音调音频子类型支持纯合成音调的传输，例如，当前电话系统中常用的用于发出呼叫进程信号的纯音合成音调。
Additional information:
其他信息：
1. Magic number(s): N/A
1. 幻数：不适用
2. File extension(s): N/A
2. 文件扩展名：不适用
3. Macintosh file type code: N/A
3. Macintosh文件类型代码：不适用
7 Security Considerations
7安全考虑
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification (RFC 1889 [1]), and any appropriate RTP profile (for example RFC 1890 [19]).This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范（RFC 1889[1]）和任何适当的RTP配置文件（例如RFC 1890[19]）中讨论的安全注意事项的约束。这意味着通过加密实现媒体流的机密性。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩之后执行加密，因此两个操作之间没有冲突。
This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
这种有效负载类型在数据包处理的接收方计算复杂性方面没有表现出任何显著的不均匀性，从而导致潜在的拒绝服务威胁。
In older networks employing in-band signaling and lacking appropriate tone filters, the tones in Section 3.14 may be used to commit toll fraud.
在采用带内信令且缺乏适当音调滤波器的较旧网络中，第3.14节中的音调可用于实施收费欺诈。
Additional security considerations are described in RFC 2198 [6].
RFC 2198[6]中描述了其他安全注意事项。
8 IANA Considerations
8 IANA考虑因素
This document defines two new RTP payload formats, named telephone-event and tone, and associated Internet media (MIME) types, audio/telephone-event and audio/tone.
本文档定义了两种新的RTP有效负载格式，命名为电话事件和音调，以及相关的Internet媒体（MIME）类型，音频/电话事件和音频/音调。
Within the audio/telephone-event type, additional events MUST be registered with IANA. Registrations are subject to approval by the current chair of the IETF audio/video transport working group, or by an expert designated by the transport area director if the AVT group has closed.
在音频/电话事件类型中，必须向IANA注册其他事件。注册须经IETF音频/视频传输工作组现任主席批准，如果AVT组已关闭，则须经传输区主任指定的专家批准。
The meaning of new events MUST be documented either as an RFC or an equivalent standards document produced by another standardization body, such as ITU-T.
新事件的含义必须记录为RFC或其他标准化机构（如ITU-T）编制的同等标准文件。
9 Acknowledgements
9致谢
The suggestions of the Megaco working group are gratefully acknowledged. Detailed advice and comments were provided by Fred Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins.
感谢Megaco工作组的建议。Fred Burg、Steve Casner、Fatih Erdin、Bill Foster、Mike Fox、Gunnar Hellstrom、Terry Lyons、Steve Magnell、Vern Paxson和Colin Perkins提供了详细的建议和意见。
10 Authors' Addresses
10作者地址
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Scott Petrack MetaTel 45 Rumford Avenue Waltham, MA 02453 USA
美国马萨诸塞州沃尔瑟姆伦福德大道45号斯科特·佩特拉克酒店
EMail: scott.petrack@metatel.com
EMail: scott.petrack@metatel.com
11 Bibliography
11参考书目
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network," Recommendation V.8, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[3] 国际电信联盟，“通过公共交换电话网开始数据传输会话的程序”，建议V.8，国际电联电信标准化部门，瑞士日内瓦，1998年2月。
[4] R. Kocen and T. Hatala, "Voice over frame relay implementation agreement", Implementation Agreement FRF.11, Frame Relay Forum, Foster City, California, Jan. 1997.
[4] R.Kocen和T.Hatala，“画外音帧中继实施协议”，实施协议FRF.11，帧中继论坛，加利福尼亚州福斯特市，1997年1月。
[5] International Telecommunication Union, "Multifrequency push-button signal reception," Recommendation Q.24, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1988.
[5] 国际电信联盟，“多频按钮信号接收”，建议Q.24，国际电联电信标准化部门，瑞士日内瓦，1988年。
[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[6] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[7] Handley M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[8] International Telecommunication Union, "Automatic answering equipment and general procedures for automatic calling equipment on the general switched telephone network including procedures for disabling of echo control devices for both manually and automatically established calls," Recommendation V.25, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Oct. 1996.
[8] 国际电信联盟，“自动应答设备和通用交换电话网络上自动呼叫设备的一般程序，包括手动和自动建立呼叫的回声控制装置禁用程序”，建议V.25，国际电联电信标准化部门，日内瓦，瑞士，1996年10月。
[9] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network," Recommendation T.30, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 1996.
[9] 国际电信联盟，“通用交换电话网中文件传真传输程序”，建议T.30，国际电联电信标准化部门，瑞士日内瓦，1996年7月。
[10] International Telecommunication Union, "Echo cancellers," Recommendation G.165, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.
[10] 国际电信联盟，“回声消除器”，建议G.165，国际电联电信标准化部门，瑞士日内瓦，1993年3月。
[11] International Telecommunication Union, "A modem operating at data signaling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits," Recommendation V.34, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[11] 国际电信联盟，“在一般交换电话网络和租用的点对点双线电话电路上使用的数据信令速率高达33 600比特/秒的调制解调器”，建议V.34，国际电联电信标准化部门，瑞士日内瓦，1998年2月。
[12] International Telecommunication Union, "Procedures for the identification and selection of common modes of operation between data circuit-terminating equipments (DCEs) and between data terminal equipments (DTEs) over the public switched telephone network and on leased point-to-point telephone-type circuits," Recommendation V.8bis, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998.
[12] 国际电信联盟，“公共交换电话网和租用点对点电话型电路上数据电路终端设备（DCE）之间和数据终端设备（DTE）之间通用操作模式的识别和选择程序”，建议V.8bis，国际电联电信标准化部门，日内瓦，瑞士，1998年9月。
[13] International Telecommunication Union, "Application of tones and recorded announcements in telephone services," Recommendation E.182, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1998.
[13] 国际电信联盟，“电话服务中音调和录音公告的应用”，建议E.182，国际电联电信标准化部门，瑞士日内瓦，1998年3月。
[14] Bellcore, "Functional criteria for digital loop carrier systems," Technical Requirement TR-NWT-000057, Telcordia (formerly Bellcore), Morristown, New Jersey, Jan. 1993.
[14] Bellcore，“数字环路载波系统的功能标准”，技术要求TR-NWT-000057，Telcordia（原Bellcore），新泽西州莫里斯镇，1993年1月。
[15] J. G. van Bosse, Signaling in Telecommunications Networks Telecommunications and Signal Processing, New York, New York: Wiley, 1998.
[15] J.G.van Bosse，《电信网络中的信令——电信和信号处理》，纽约，纽约：Wiley，1998年。
[16] International Telecommunication Union, "AAL type 2 service specific convergence sublayer for trunking," Recommendation I.366.2, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Feb. 1999.
[16] 国际电信联盟，“用于中继的AAL 2类特定服务汇聚子层”，建议I.366.2，ITU电信标准化部门，瑞士日内瓦，1999年2月。
[17] International Telecommunication Union, "Various tones used in national networks," Recommendation Supplement 2 to Recommendation E.180, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
[17] 国际电信联盟，“国家网络中使用的各种音调”，建议E.180的补充建议2，国际电联电信标准化部门，瑞士日内瓦，1994年1月。
[18] International Telecommunication Union, "Technical characteristics of tones for telephone service," Recommendation Supplement 2 to Recommendation E.180, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
[18] 国际电信联盟，“电话业务音调的技术特征”，建议E.180的补充建议2，国际电联电信标准化部门，瑞士日内瓦，1994年1月。
[19] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[19] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
12 Full Copyright Statement
12完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。