Network Working Group H. Schulzrinne
Request for Comments: 4733 Columbia U.
Obsoletes: 2833 T. Taylor
Category: Standards Track Nortel
December 2006
Network Working Group H. Schulzrinne
Request for Comments: 4733 Columbia U.
Obsoletes: 2833 T. Taylor
Category: Standards Track Nortel
December 2006
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.
本备忘录描述了如何在RTP数据包中传输双音多频（DTMF）信号、其他音信号和电话事件。它淘汰了RFC 2833。
This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.
本备忘录捕获并扩展了RFC 2833中定义的基本框架，但仅保留最基本的事件代码。它设置了一个IANA注册表，可以向其中添加其他事件代码分配。附带文档将事件代码添加到此注册表中，这些代码与调制解调器、传真、文本电话和信道相关的信令事件有关。RFC 2833中定义的其余事件代码有条件保留，以备其他文件重新使用。
This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events.
本文件对原始文件进行了一些澄清。但是，它与RFC 2833的具体区别在于，它取消了所有兼容实现都支持DTMF事件的要求。相反，参与媒体流内容带外协商的合规实现表明它们支持哪些事件。本备忘录为RFC 2833框架添加了三个新程序：将长事件细分为段、在单个数据包中报告多个事件以及状态事件的概念和报告。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Overview ...................................................4
1.3. Potential Applications .....................................5
1.4. Events, States, Tone Patterns, and Voice-Encoded Tones .....6
2. RTP Payload Format for Named Telephone Events ...................8
2.1. Introduction ...............................................8
2.2. Use of RTP Header Fields ...................................8
2.2.1. Timestamp ...........................................8
2.2.2. Marker Bit ..........................................8
2.3. Payload Format .............................................8
2.3.1. Event Field .........................................9
2.3.2. E ("End") Bit .......................................9
2.3.3. R Bit ...............................................9
2.3.4. Volume Field ........................................9
2.3.5. Duration Field ......................................9
2.4. Optional Media Type Parameters ............................10
2.4.1. Relationship to SDP ................................10
2.5. Procedures ................................................11
2.5.1. Sending Procedures .................................11
2.5.2. Receiving Procedures ...............................16
2.6. Congestion and Performance ................................19
2.6.1. Performance Requirements ...........................20
2.6.2. Reliability Mechanisms .............................20
2.6.3. Adjusting to Congestion ............................22
3. Specification of Event Codes for DTMF Events ...................23
3.1. DTMF Applications .........................................23
3.2. DTMF Events ...............................................25
3.3. Congestion Considerations .................................25
4. RTP Payload Format for Telephony Tones .........................26
4.1. Introduction ..............................................26
4.2. Examples of Common Telephone Tone Signals .................27
4.3. Use of RTP Header Fields ..................................27
4.3.1. Timestamp ..........................................27
4.3.2. Marker Bit .........................................27
4.3.3. Payload Format .....................................28
4.3.4. Optional Media Type Parameters .....................29
4.4. Procedures ................................................29
4.4.1. Sending Procedures .................................29
4.4.2. Receiving Procedures ...............................30
4.4.3. Handling of Congestion .............................30
5. Examples .......................................................31
6. Security Considerations ........................................38
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Overview ...................................................4
1.3. Potential Applications .....................................5
1.4. Events, States, Tone Patterns, and Voice-Encoded Tones .....6
2. RTP Payload Format for Named Telephone Events ...................8
2.1. Introduction ...............................................8
2.2. Use of RTP Header Fields ...................................8
2.2.1. Timestamp ...........................................8
2.2.2. Marker Bit ..........................................8
2.3. Payload Format .............................................8
2.3.1. Event Field .........................................9
2.3.2. E ("End") Bit .......................................9
2.3.3. R Bit ...............................................9
2.3.4. Volume Field ........................................9
2.3.5. Duration Field ......................................9
2.4. Optional Media Type Parameters ............................10
2.4.1. Relationship to SDP ................................10
2.5. Procedures ................................................11
2.5.1. Sending Procedures .................................11
2.5.2. Receiving Procedures ...............................16
2.6. Congestion and Performance ................................19
2.6.1. Performance Requirements ...........................20
2.6.2. Reliability Mechanisms .............................20
2.6.3. Adjusting to Congestion ............................22
3. Specification of Event Codes for DTMF Events ...................23
3.1. DTMF Applications .........................................23
3.2. DTMF Events ...............................................25
3.3. Congestion Considerations .................................25
4. RTP Payload Format for Telephony Tones .........................26
4.1. Introduction ..............................................26
4.2. Examples of Common Telephone Tone Signals .................27
4.3. Use of RTP Header Fields ..................................27
4.3.1. Timestamp ..........................................27
4.3.2. Marker Bit .........................................27
4.3.3. Payload Format .....................................28
4.3.4. Optional Media Type Parameters .....................29
4.4. Procedures ................................................29
4.4.1. Sending Procedures .................................29
4.4.2. Receiving Procedures ...............................30
4.4.3. Handling of Congestion .............................30
5. Examples .......................................................31
6. Security Considerations ........................................38
7. IANA Considerations ............................................38
7.1. Media Type Registrations ..................................40
7.1.1. Registration of Media Type audio/telephone-event ...40
7.1.2. Registration of Media Type audio/tone ..............42
8. Acknowledgements ...............................................43
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................44
Appendix A. Summary of Changes from RFC 2833 ......................46
7. IANA Considerations ............................................38
7.1. Media Type Registrations ..................................40
7.1.1. Registration of Media Type audio/telephone-event ...40
7.1.2. Registration of Media Type audio/tone ..............42
8. Acknowledgements ...............................................43
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................44
Appendix A. Summary of Changes from RFC 2833 ......................46
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]中的说明进行解释。
This document uses the following abbreviations:
本文件使用以下缩写：
ANSam Answer tone (amplitude modulated) [24]
ANSam应答音（调幅）[24]
DTMF Dual-Tone Multifrequency [10]
DTMF双音多频[10]
IVR Interactive Voice Response unit
交互式语音应答器
PBX Private branch exchange (telephone system)
PBX专用交换机（电话系统）
PSTN Public Switched (circuit) Telephone Network
公用交换（电路）电话网
RTP Real-time Transport Protocol [5]
RTP实时传输协议[5]
SDP Session Description Protocol [9]
SDP会话描述协议[9]
This memo defines two RTP [5] payload formats, one for carrying dual-tone multifrequency (DTMF) digits and other line and trunk signals as events (Section 2), and a second one to describe general multifrequency tones in terms only of their frequency and cadence (Section 4). Separate RTP payload formats for telephony tone signals are desirable since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition. In addition, tone properties such as the phase reversals in the ANSam tone will not survive speech coding. Defining separate payload formats also permits higher redundancy while maintaining a low bit rate. Finally, some telephony events such as "on-hook" occur out-of-band and cannot be transmitted as tones.
本备忘录定义了两种RTP[5]有效载荷格式，一种用于将双音多频（DTMF）数字和其他线路和中继信号作为事件进行传输（第2节），另一种用于仅根据频率和节奏描述一般多频音调（第4节）。由于不能保证低速率语音编解码器能够足够准确地再现这些语音信号以进行自动识别，因此需要为电话语音信号提供单独的RTP有效载荷格式。此外，ANSam音调中的相位反转等音调特性将无法在语音编码中存活。定义单独的有效负载格式还允许更高的冗余，同时保持较低的比特率。最后，一些电话事件（如“挂机”）发生在带外，不能作为音调传输。
The remainder of this section provides the motivation for defining the payload types described in this document. Section 2 defines the payload format and associated procedures for use of named events. Section 3 describes the events for which event codes are defined in this document. Section 4 describes the payload format and associated procedures for tone representations. Section 5 provides some examples of encoded events, tones, and combined payloads. Section 6 deals with security considerations. Section 7 defines the IANA requirements for registration of event codes for named telephone
本节的其余部分提供了定义本文档中描述的有效负载类型的动机。第2节定义了使用命名事件的有效负载格式和相关过程。第3节描述了本文件中定义了事件代码的事件。第4节描述了音调表示的有效载荷格式和相关程序。第5节提供了一些编码事件、音调和组合有效载荷的示例。第6节涉及安全考虑。第7节定义了IANA对命名电话事件代码注册的要求
events, establishes the initial content of that registry, and provides the media type registrations for the two payload formats. Appendix A describes the changes from RFC 2833 [12] and in particular indicates the disposition of the event codes defined in [12].
事件，建立该注册表的初始内容，并为两种有效负载格式提供媒体类型注册。附录A描述了RFC 2833[12]的变更，特别是说明了[12]中定义的事件代码的处置。
The payload formats described here may be useful in a number of different scenarios.
这里描述的有效负载格式在许多不同的场景中可能很有用。
On the sending side, there are two basic possibilities: either the sending side is an end system that originates the signals itself, or it is a gateway with the task of propagating incoming telephone signals into the Internet.
在发送端，有两种基本的可能性：一种是发送端是发送信号的终端系统，另一种是网关，负责将传入的电话信号传播到互联网。
On the receiving side, there are more possibilities. The first is that the receiver must propagate tone signalling accurately into the PSTN for machine consumption. One example of this is a gateway passing DTMF tones to an IVR. In this scenario, frequencies, amplitudes, tone durations, and the durations of pauses between tones are all significant, and individual tone signals must be delivered reliably and in order.
在接受方，有更多的可能性。首先，接收机必须将音频信号准确地传播到PSTN中，以供机器使用。其中一个例子是网关将DTMF音调传递给IVR。在这种情况下，频率、振幅、音调持续时间以及音调之间暂停的持续时间都是重要的，并且必须可靠且有序地传递各个音调信号。
In a second receiving scenario, the receiver must play out tones for human consumption. Typically, rather than a series of tone signals each with its own meaning, the content will consist of a single tone played out continuously or a single sequence of tones and possibly silence, repeated cyclically for some period of time. Often the end of the tone playout will be triggered by an event fed back in the other direction, using either in- or out-of-band means. Examples of this are dial tone or busy tone.
在第二个接收场景中，接收器必须播放音调供人类使用。通常，内容将由连续播放的单音或单音序列以及可能的静音组成，而不是一系列具有各自含义的音调信号，并循环重复一段时间。通常，音调播放结束时，会通过使用带内或带外方式在另一个方向反馈的事件触发。例如拨号音或忙音。
The relationship between position in the network and the tones to be played out is a complicating factor in this scenario. 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. Integrated Services Digital Network (ISDN) terminals may generate dial tone locally and then send a Q.931 [22] 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 key press digit information within Called Party or Keypad Facility Information Elements (IEs) of INFORMATION messages), and provides dial tone over
对于模拟线路，拨号音始终由本地交换机生成。综合业务数字网（ISDN）终端可在本地生成拨号音，然后发送包含拨号数字的Q.931[22]设置消息。如果终端只发送一条没有任何被叫方数字的设置消息，则交换机进行数字采集（由终端提供，作为被叫方或信息消息的键盘设施信息元素内的键盘按键数字信息），并提供拨号音
the B-channel. The terminal can either use the audio signal on the B-channel or use the Q.931 messages to trigger locally generated dial tone.
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 ISDN User Part (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.
铃声（也称回铃音）由被叫方的本地交换机生成，被叫方的电话一响，单向语音路径就会打开。（这减少了接听后立即切断被叫方响应的机会。它还允许接听前通知或带内通话进度指示在铃声之前或代替铃声到达呼叫者。）沿途的任何交换机都可以生成拥塞音和特殊信息音，并且可以由呼叫者的交换机基于接收到的ISDN用户部分（ISUP）消息生成。对于模拟仪表或ISDN终端，呼叫方交换机通过相应的ISUP消息触发，产生忙音。
In the third scenario, an end system is directly connected to the Internet and processes the incoming media stream directly. There is no need to regenerate tone signals, so that time alignment and power levels are not relevant. These systems rely on sending systems to generate events in place of tones and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice response (IVR) system.
在第三个场景中，终端系统直接连接到互联网，并直接处理传入的媒体流。不需要重新生成音调信号，因此时间对齐和功率级别不相关。这些系统不依赖于自己的音频波形分析来生成事件。这种系统的一个例子是因特网交互式语音应答（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, as in the IVR example, it may be preferable to use a reliable control protocol rather than RTP packets. In those circumstances, this payload format would not be used.
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, as in the IVR example, it may be preferable to use a reliable control protocol rather than RTP packets. In those circumstances, this payload format would not be used.translate error, please retry
Note that in a number of these cases it is possible that the gateway or end system will be both a sender and receiver of telephone signals. Sometimes the same class of signals will be sent as received -- in the case of "RTP trunking" or voice-band data, for instance. In other cases, such as that of an end system serving analogue lines, the signals sent will be in a different class from those received.
请注意，在许多情况下，网关或终端系统可能同时是电话信号的发送者和接收者。有时，发送的信号与接收的信号相同——例如，在“RTP中继”或声带数据的情况下。在其他情况下，例如为模拟线路服务的终端系统，发送的信号将与接收的信号处于不同的等级。
This document provides the means for in-band transport over the Internet of two broad classes of signalling information: in-band tones or tone sequences, and signals sent out-of-band in the PSTN. Tone signals can be carried using any of the three methods listed below. Depending on the application, it may be desirable to carry the signalling information in more than one form at once.
本文件提供了通过互联网进行两大类信令信息带内传输的方法：带内音调或音调序列，以及PSTN中带外发送的信号。可以使用以下三种方法中的任何一种来传送音调信号。根据应用，可能希望一次以多种形式携带信令信息。
1. The gateway or end system can change to a higher-bandwidth codec such as G.711 [19] when tone signals are to be conveyed. See new ITU-T Recommendation V.152 [26] for a formal treatment of this approach. Alternatively, for fax, text, or modem signals respectively, a specialized transport such as T.38 [23], RFC 4103 [15], or V.150.1 modem relay [25] may be used. Finally, 64 kbit/s channels may be carried transparently using the RFC 4040 Clearmode payload type [14]. These methods are out of scope of the present document, but may be used along with the payload types defined here.
1. 当要传送音调信号时，网关或终端系统可以改变为更高带宽的编解码器，例如G.711[19]。有关此方法的正式处理方法，请参见新的ITU-T建议V.152[26]。或者，对于传真、文本或调制解调器信号，可分别使用T.38[23]、RFC 4103[15]或V.150.1调制解调器中继[25]等专用传输。最后，可以使用RFC 4040 Clearmode有效负载类型透明地携带64 kbit/s信道[14]。这些方法不在本文档的范围内，但可与此处定义的有效负载类型一起使用。
2. The sending gateway can simply measure the frequency components of the voice-band signals and transmit this information to the RTP receiver using the tone representation defined in this document (Section 4). In this mode, the gateway makes no attempt to discern the meaning of the tones, but simply distinguishes tones from speech signals. An end system may use the same approach using configured rather than measured frequencies.
2. 发送网关可以简单地测量声带信号的频率分量，并使用本文件（第4节）中定义的音调表示将该信息发送到RTP接收器。在这种模式下，网关不试图辨别音调的含义，而只是将音调与语音信号区分开来。终端系统可以使用相同的方法，使用配置的频率而不是测量的频率。
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. (However, some modem signals such as the ANSam tone [24] or systems dependent on phase shift keying cannot be conveyed so simply.)
PSTN中使用的、供人使用的所有音调信号都是正弦波的简单组合序列，可以是添加的，也可以是调制的。（然而，一些调制解调器信号，如ANSam音调[24]或依赖相移键控的系统不能如此简单地传送。）
3. As a third option, a sending gateway can recognize tones such as ringing or busy tone or DTMF digit '0', and transmit a code that identifies them using the telephone-event payload defined in this document (Section 2). The receiver then produces a tone signal or other indication appropriate to the signal. Generally, since the recognition of signals at the sender 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 signalling information that generates the tones and thus can generate the RTP packet immediately, without the detour through acoustic signals.
3. 作为第三个选项，发送网关可以识别铃声，如铃声、忙音或DTMF数字“0”，并使用本文档（第2节）中定义的电话事件有效负载发送识别这些铃声的代码。然后，接收器产生适合于该信号的音调信号或其它指示。通常，由于发送方对信号的识别通常取决于信号的开/关模式或几个音调的序列，因此该识别可能需要几秒钟。另一方面，网关可以访问生成音调的实际信令信息，因此可以立即生成RTP分组，而无需绕道声音信号。
The third option (use of named events) is the only feasible method for transmitting out-of-band PSTN signals as content within RTP sessions.
第三种选择（使用命名事件）是将带外PSTN信号作为RTP会话中的内容传输的唯一可行方法。
The RTP payload format for named telephone events is designated as "telephone-event", the media type as "audio/telephone-event". In accordance with current practice, this payload format does not have a static payload type number, but uses an RTP payload type number established dynamically and out-of-band. The default clock frequency is 8000 Hz, but the clock frequency can be redefined when assigning the dynamic payload type.
指定电话事件的RTP有效负载格式指定为“电话事件”，媒体类型指定为“音频/电话事件”。根据当前实践，此有效负载格式没有静态有效负载类型编号，但使用动态和带外建立的RTP有效负载类型编号。默认时钟频率为8000 Hz，但在分配动态有效负载类型时，可以重新定义时钟频率。
Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. The named telephone-event payload type can be considered to be a very highly-compressed audio codec and is treated the same as other codecs.
命名电话事件作为音频流的一部分进行，必须使用与常规音频通道相同的序列号和时间戳基数，以简化网关上音频波形的生成。命名的电话事件有效负载类型可以被视为是一个高度压缩的音频编解码器，并与其他编解码器一样处理。
The event duration described in Section 2.5 begins at the time given by the RTP timestamp. For events that span multiple RTP packets, the RTP timestamp identifies the beginning of the event, i.e., several RTP packets may carry the same timestamp. For long-lasting events that have to be split into segments (see below, Section 2.5.1.3), the timestamp indicates the beginning of the segment.
第2.5节中描述的事件持续时间从RTP时间戳给出的时间开始。对于跨越多个RTP分组的事件，RTP时间戳标识事件的开始，即，多个RTP分组可以携带相同的时间戳。对于必须分为段的长期事件（见下文第2.5.1.3节），时间戳表示段的开始。
The RTP marker bit indicates the beginning of a new event. For long-lasting events that have to be split into segments (see below, Section 2.5.1.3), only the first segment will have the marker bit set.
RTP标记位表示新事件的开始。对于必须拆分为段的长期事件（见下文第2.5.1.3节），只有第一段设置了标记位。
The payload format for named telephone events is shown in Figure 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：命名事件的有效负载格式
The event field is a number between 0 and 255 identifying a specific telephony event. An IANA registry of event codes for this field has been established (see IANA Considerations, Section 7). The initial content of this registry consists of the events defined in Section 3.
事件字段是一个介于0和255之间的数字，用于标识特定的电话事件。已建立该领域的IANA事件代码登记册（参见IANA注意事项，第7节）。此注册表的初始内容由第3节中定义的事件组成。
If set to a value of one, the "end" bit indicates that this packet contains the end of the event. For long-lasting events that have to be split into segments (see below, Section 2.5.1.3), only the final packet for the final segment will have the E bit set.
如果设置为值1，“结束”位表示此数据包包含事件的结束。对于必须拆分为段的长期事件（见下文第2.5.1.3节），只有最后一段的最终数据包才会设置E位。
This field is reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it.
此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
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. Thus, larger values denote lower volume. This value is defined only for events for which the documentation indicates that volume is applicable. For other events, the sender MUST set volume to zero and the receiver MUST ignore the value.
对于DTMF数字和其他可表示为音调的事件，此字段描述音调的功率级别，在删除符号后以dBm0表示。功率级别范围从0到-63 dBm0。因此，值越大表示体积越小。此值仅针对文档中指出卷适用的事件定义。对于其他事件，发送方必须将音量设置为零，接收方必须忽略该值。
The duration field indicates the duration of the event or segment being reported, in timestamp units, expressed as an unsigned integer in network byte order. For a non-zero value, the event or segment 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. If the event duration exceeds the maximum representable by the duration field, the event is split into several contiguous segments as described below (Section 2.5.1.3).
duration（持续时间）字段以时间戳为单位表示报告的事件或段的持续时间，以网络字节顺序表示为无符号整数。对于非零值，事件或段从RTP时间戳标识的瞬间开始，并一直持续到该参数指示的时间。事件可能已经结束，也可能尚未结束。如果事件持续时间超过“持续时间”字段可表示的最大值，则事件被分割为几个连续段，如下所述（第2.5.1.3节）。
The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state.
保留0的特殊持续时间值，以表示事件“永远”持续，即是一种状态，在更新之前被视为有效。对于定义为状态以外的事件，发送方不得传输零持续时间。如果事件不是状态，则接收方应忽略持续时间为零的事件报告。
Events defined as states MAY contain a non-zero duration, indicating that the sender intends to refresh the state before the time duration has elapsed ("soft state").
定义为状态的事件可能包含非零持续时间，表示发送方打算在持续时间过去之前刷新状态（“软状态”）。
For a sampling rate of 8000 Hz, the duration field is sufficient to express event durations of up to approximately 8 seconds.
对于8000 Hz的采样率，持续时间字段足以表示高达约8秒的事件持续时间。
As indicated in the media type registration for named events in Section 7.1.1, the telephone-event media type supports two optional parameters: the "events" parameter and the "rate" parameter.
如第7.1.1节中命名事件的媒体类型注册所示，电话事件媒体类型支持两个可选参数：“事件”参数和“速率”参数。
The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can be either a single integer providing the value of an event code or an integer followed by a hyphen and a larger integer, presenting a range of consecutive event code values. The list does not have to be sorted. No white space is allowed in the argument. The union of all of the individual event codes and event code ranges designates the complete set of event numbers supported by the implementation.
“events”参数列出了实现支持的事件。事件以一个或多个逗号分隔的元素列出。每个元素可以是提供事件代码值的单个整数，也可以是后跟连字符和较大整数的整数，表示一系列连续的事件代码值。列表不必排序。参数中不允许有空格。所有单个事件代码和事件代码范围的并集指定了实现支持的完整事件编号集。
The "rate" parameter describes the sampling rate, in Hertz, and hence the units for the RTP timestamp and event duration fields. The number is written as an integer. If omitted, the default value is 8000 Hz.
“rate”参数描述采样率（以赫兹为单位），因此RTP时间戳和事件持续时间字段的单位。该数字被写为整数。如果省略，默认值为8000 Hz。
The recommended mapping of media type optional parameters to SDP is given in Section 3 of RFC 3555 [6]. The "rate" media type parameter for the named event payload type follows this convention: it is expressed as usual as the <clock rate> component of the a=rtpmap: attribute line.
RFC 3555[6]第3节给出了介质类型可选参数到SDP的推荐映射。命名事件有效负载类型的“速率”媒体类型参数遵循此约定：它通常表示为a=rtpmap:属性行的<clock rate>组件。
The "events" media type parameter deviates from the convention suggested in RFC 3555 because it omits the string "events=" before the list of supported events.
“events”media type参数与RFC 3555中建议的约定不同，因为它在支持的事件列表之前省略了字符串“events=”。
a=fmtp:<format> <list of values>
a=fmtp:<format> <list of values>
The list of values has the format and meaning described above.
值列表具有上述格式和含义。
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 (assuming as an example that these were defined as events with codes 66 and 70, respectively), it would include the following description in its SDP message:
例如，如果有效载荷格式使用有效载荷类型编号100，并且实现可以处理DTMF音调（事件0到15）以及拨号和铃声（例如，假设这些分别被定义为代码为66和70的事件），则其SDP消息中将包括以下描述：
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
The following sample media type definition corresponds to the SDP example above:
以下示例媒体类型定义对应于上面的SDP示例：
audio/telephone-event;events="0-15,66,70";rate="8000"
audio/telephone-event;events="0-15,66,70";rate="8000"
This section defines the procedures associated with the named event payload type. Additional procedures may be specified in the documentation associated with specific event codes.
本节定义与命名事件有效负载类型关联的过程。与特定事件代码相关的文件中可能会规定其他程序。
Events are usually sent in combination with or alternating with other payload types. Payload negotiation may specify separate event and other payload streams, or it may specify a combined stream that mixes other payload types with events using RFC 2198 [2] redundancy headers. The purpose of using a combined stream may be for debugging or to ease the transition between general audio and events.
事件通常与其他有效负载类型一起发送，或与其他有效负载类型交替发送。有效负载协商可以指定单独的事件和其他有效负载流，或者可以指定使用RFC 2198[2]冗余报头将其他有效负载类型与事件混合的组合流。使用组合流的目的可能是为了调试或简化一般音频和事件之间的转换。
Negotiation of payloads between sender and receiver is achieved by out-of-band means, using SDP, for example.
发送方和接收方之间的有效负载协商是通过带外方式实现的，例如使用SDP。
The sender SHOULD indicate what events it supports, using the optional "events" parameter associated with the telephone-event media type. If the sender receives an "events" parameter from the receiver, it MUST restrict the set of events it sends to those listed in the received "events" parameter. For backward compatibility, if no "events" parameter is received, the sender SHOULD assume support for the DTMF events 0-15 but for no other events.
发送方应使用与电话事件媒体类型相关联的可选“events”参数指示其支持的事件。如果发送方从接收方接收到“事件”参数，则必须将其发送的事件集限制为已接收“事件”参数中列出的事件集。为了向后兼容，如果未收到“events”参数，发送方应假定支持DTMF事件0-15，但不支持其他事件。
Events MAY be sent in combination with older events using RFC 2198 [2] redundancy. Section 2.5.1.4 describes how this can be used to avoid packet and RTP header overheads when retransmitting final event reports. Section 2.6 discusses the use of additional levels of RFC 2198 redundancy to increase the probability that at least one copy of
事件可以使用RFC 2198[2]冗余与旧事件一起发送。第2.5.1.4节描述了如何在重新传输最终事件报告时使用此方法避免数据包和RTP报头开销。第2.6节讨论了使用额外级别的RFC 2198冗余，以增加至少一个副本
the report of the end of an event reaches the receiver. The following SDP shows an example of such usage, where G.711 audio appears in a separate stream, and the primary component of the redundant payload is events.
事件结束的报告到达接收者。以下SDP显示了此类使用的示例，其中G.711音频出现在单独的流中，冗余负载的主要组件是事件。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12346 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
m=audio 12344 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12346 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
When used in accordance with the offer-answer model (RFC 3264 [4]), the SDP a=ptime: attribute indicates the packetization period that the author of the session description expects when receiving media. This value does not have to be the same in both directions. The appropriate period may vary with the application, since increased packetization periods imply increased end-to-end response times in instances where one end responds to events reported from the other.
根据要约-应答模型（RFC 3264[4]）使用时，SDP a=ptime:属性表示会话描述的作者在接收媒体时预期的打包周期。该值在两个方向上不必相同。适当的周期可能因应用程序而异，因为在一端响应另一端报告的事件的情况下，增加的打包周期意味着增加的端到端响应时间。
Negotiation of telephone-events sessions using SDP MAY specify such differences by separating events corresponding to different applications into different streams. In the example below, events 0-15 are DTMF events, which have a fairly wide tolerance on timing. Events 32-49 and 52-60 are events related to data transmission and are subject to end-to-end response time considerations. As a result, they are assigned a smaller packetization period than the DTMF events.
使用SDP的电话事件会话的协商可以通过将对应于不同应用的事件分离到不同流中来指定这种差异。在下面的示例中，事件0-15是DTMF事件，它在计时方面具有相当大的容差。事件32-49和52-60是与数据传输相关的事件，需要考虑端到端响应时间。因此，它们被指定为比DTMF更小的打包周期。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:50
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 32-49,52-60
a=ptime:30
m=audio 12344 RTP/AVP 99
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:50
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 32-49,52-60
a=ptime:30
For further discussion of packetization periods see Section 2.6.3.
关于包装周期的进一步讨论，见第2.6.3节。
DTMF digits and other named telephone events are carried as part of the audio stream, and they MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway.
DTMF数字和其他命名电话事件作为音频流的一部分进行传输，它们必须使用与常规音频通道相同的序列号和时间戳，以简化网关上音频波形的生成。
An audio source SHOULD start transmitting event packets as soon as it recognizes an event and continue to send updates until the event has ended. The update packets MUST have the same RTP timestamp value as the initial packet for the event, but the duration MUST be increased to reflect the total cumulative duration since the beginning of the event.
音频源应在识别到事件后立即开始传输事件包，并继续发送更新，直到事件结束。更新数据包必须与事件的初始数据包具有相同的RTP时间戳值，但必须增加持续时间以反映自事件开始以来的总累积持续时间。
The first packet for an event MUST have the M bit set. The final packet for an event MUST have the E bit set, but setting of the "E" bit MAY be deferred until the final packet is retransmitted (see Section 2.5.1.4). Intermediate packets for an event MUST NOT have either the M bit or the E bit set.
事件的第一个数据包必须设置M位。事件的最终数据包必须设置E位，但“E”位的设置可以推迟到最终数据包被重新传输（见第2.5.1.4节）。事件的中间数据包不得设置M位或E位。
Sending of a packet with the E bit set is OPTIONAL if the packet reports two events that are defined as mutually exclusive states, or if the final packet for one state is immediately followed by a packet reporting a mutually exclusive state. (For events defined as states, the appearance of a mutually exclusive state implies the end of the previous state.)
如果数据包报告两个定义为互斥状态的事件，或者如果一个状态的最终数据包紧接着一个报告互斥状态的数据包，则发送带有E位集的数据包是可选的。（对于定义为状态的事件，互斥状态的出现意味着前一状态的结束。）
A source has wide latitude as to how often it sends event updates. A natural interval is the spacing between non-event audio packets. (Recall that a single RTP packet can contain multiple audio frames for frame-based codecs and that the packet interval can vary during a session.) Alternatively, a source MAY decide to use a different spacing for event updates, with a value of 50 ms RECOMMENDED.
对于发送事件更新的频率，源有很大的自由度。自然间隔是非事件音频数据包之间的间隔。（回想一下，对于基于帧的编解码器，单个RTP数据包可以包含多个音频帧，并且数据包间隔可以在会话期间变化。）或者，源可以决定使用不同的间隔进行事件更新，建议使用50 ms的值。
Timing information is contained in the RTP timestamp, allowing precise recovery of inter-event times. Thus, the sender does not in theory need to maintain precise or consistent time intervals between event packets. However, the sender SHOULD minimize the need for buffering at the receiving end by sending event reports at constant intervals.
RTP时间戳中包含计时信息，允许精确恢复事件间时间。因此，发送方在理论上不需要在事件包之间保持精确或一致的时间间隔。然而，发送方应该通过以固定的间隔发送事件报告来最小化接收端的缓冲需求。
DTMF digits and other tone events are sent incrementally to avoid having the receiver wait for the completion of the event. In some cases (for example, data session startup protocols), waiting until the end of a tone before reporting it will cause the session to fail. In other cases, it will simply cause undesirable delays in playout at the receiving end.
DTMF数字和其他音调事件以增量方式发送，以避免接收器等待事件完成。在某些情况下（例如，数据会话启动协议），在报告之前等待音调结束将导致会话失败。在其他情况下，它只会导致接收端播放的不希望的延迟。
For robustness, the sender SHOULD retransmit "state" events periodically.
为了健壮性，发送方应该定期重新传输“状态”事件。
If an event persists beyond the maximum duration expressible in the duration field (0xFFFF), the sender MUST send a packet reporting this maximum duration but MUST NOT set the E bit in this packet. The sender MUST then begin reporting a new "segment" with the RTP timestamp set to the time at which the previous segment ended and the duration set to the cumulative duration of the new segment. The M bit of the first packet reporting the new segment MUST NOT be set. The sender MUST repeat this procedure as required until the end of the complete event has been reached. The final packet for the complete event MUST have the E bit set (either on initial transmission or on retransmission as described below).
如果事件持续时间超过持续时间字段（0xFFFF）中可表示的最大持续时间，则发送方必须发送报告此最大持续时间的数据包，但不得设置此数据包中的E位。然后，发送方必须开始报告新的“段”，RTP时间戳设置为前一段结束的时间，持续时间设置为新段的累计持续时间。不得设置报告新段的第一个数据包的M位。发送方必须根据需要重复此过程，直到完成事件结束。完整事件的最终数据包必须设置E位（在初始传输时或在如下所述的重新传输时）。
If events are combined as a redundant payload with another payload type using RFC 2198 [2] redundancy, the above procedure SHALL be applied, but using a maximum duration that ensures that the timestamp offset of the oldest generation of events in an RFC 2198 packet never exceeds 0x3FFF. If the sender is using a constant packetization period, the maximum segment duration can be calculated from the following formula:
如果使用RFC 2198[2]冗余将事件作为冗余有效负载与另一种有效负载类型组合，则应采用上述程序，但使用的最大持续时间应确保RFC 2198数据包中最早生成的事件的时间戳偏移量不超过0x3FFF。如果发送方使用恒定的打包周期，则可根据以下公式计算最大段持续时间：
maximum duration = 0x3FFF - (R-1)*(packetization period in timestamp units)
最大持续时间=0x3FFF-（R-1）*（以时间戳为单位的打包周期）
where R is the highest redundant layer number consisting of event payload.
其中R是由事件有效载荷组成的最高冗余层编号。
The RFC 2198 redundancy header timestamp offset value is only 14 bits, compared with the 16 bits in the event payload duration field. Since with other payloads the RTP timestamp typically increments for each new sample, the timestamp offset value becomes limiting on reported event duration. The limit becomes more constraining when older generations of events are also included in the combined payload.
RFC 2198冗余报头时间戳偏移值仅为14位，而事件有效负载持续时间字段中为16位。由于对于其他有效负载，RTP时间戳通常会为每个新样本递增，因此时间戳偏移值会限制报告的事件持续时间。当旧一代的事件也包含在组合的有效负载中时，限制变得更具约束性。
The final packet for each event and for each segment SHOULD be sent a total of three times at the interval used by the source for updates. This ensures that the duration of the event or segment can be recognized correctly even if an instance of the last packet is lost.
每个事件和每个段的最终数据包应按照源用于更新的间隔总共发送三次。这确保即使最后一个数据包的实例丢失，也能正确识别事件或数据段的持续时间。
A sender MAY use RFC 2198 [2] with up to two levels of redundancy to combine retransmissions with reports of new events, thus saving on header overheads. In this usage, the primary payload is new event
发送方可以使用RFC 2198[2]和高达两级的冗余来将重传与新事件的报告结合起来，从而节省报头开销。在这种用法中，主要有效负载是新事件
reports, while the first and (if necessary) second levels of redundancy report first and second retransmissions of final event reports. Within a session negotiated to allow such usage, packets containing the RFC 2198 payload SHOULD NOT be sent except when both primary and retransmitted reports are to be included. All other packets of the session SHOULD contain only the simple, non-redundant telephone-event payload. Note that the expected proportion of simple versus redundant packets affects the order in which they should be specified on an SDP m= line.
报告，而第一级和（如有必要）第二级冗余报告最终事件报告的第一次和第二次重传。在协商以允许这种使用的会话中，不应发送包含RFC 2198有效载荷的数据包，除非同时包括主报告和重传报告。会话的所有其他数据包应仅包含简单、非冗余的电话事件有效负载。请注意，简单数据包与冗余数据包的预期比例会影响在SDP m=行上指定它们的顺序。
There is little point in sending initial or interim event reports redundantly because each succeeding packet describes the event fully (except for typically irrelevant variations in volume).
冗余发送初始或临时事件报告没有什么意义，因为每个后续数据包都完整地描述了事件（通常不相关的量变化除外）。
A sender MAY delay setting the E bit until retransmitting the last packet for a tone, rather than setting the bit on its first transmission. This avoids having to wait to detect whether the tone has indeed ended. Once the sender has set the E bit for a packet, it MUST continue to set the E bit for any further retransmissions of that packet.
发送方可以延迟设置E比特，直到重新传输音调的最后一个分组，而不是在第一次传输时设置该比特。这样可以避免等待检测音调是否确实结束。一旦发送方为数据包设置了E位，它必须继续为该数据包的任何进一步重传设置E位。
Multiple named events can be packed into a single RTP packet if and only if the events are consecutive and contiguous, i.e., occur without overlap and without pause between them, and if the last event packed into a packet occurs quickly enough to avoid excessive delays at the receiver.
如果且仅当事件是连续的且连续的，即事件之间没有重叠且没有暂停，并且如果打包到数据包中的最后一个事件发生得足够快以避免接收器处的过度延迟，则可以将多个命名事件打包到单个RTP数据包中。
This approach is similar to having multiple frames of frame-based audio in one RTP packet.
这种方法类似于在一个RTP包中包含多个基于帧的音频帧。
The constraint that packed events not overlap implies that events designated as states can be followed in a packet only by other state events that are mutually exclusive to them. The constraint itself is needed so that the beginning time of each event can be calculated at the receiver.
压缩事件不重叠的约束意味着指定为状态的事件只能在数据包中由相互排斥的其他状态事件跟随。需要约束本身，以便可以在接收器处计算每个事件的开始时间。
In a packet containing events packed in this way, the RTP timestamp MUST identify the beginning of the first event or segment in the packet. The M bit MUST be set if the packet records the beginning of at least one event. (This will be true except when the packet carries the end of one segment and the beginning of the next segment of the same long-lasting event.) The E bit and duration for each event in the packet MUST be set using the same rules as if that event were the only event contained in the packet.
在包含以这种方式打包的事件的数据包中，RTP时间戳必须标识数据包中第一个事件或段的开始。如果数据包记录至少一个事件的开始，则必须设置M位。（除非数据包携带同一长期事件的一段结束和下一段开始，否则这将是正确的。）必须使用相同的规则设置数据包中每个事件的E位和持续时间，就像该事件是数据包中包含的唯一事件一样。
The RTP sequence number MUST be incremented by one in each successive RTP packet sent. Incrementing applies to retransmitted as well as initial instances of event reports, to permit the receiver to detect lost packets for RTP Control Protocol (RTCP) receiver reports.
在每个连续发送的RTP数据包中，RTP序列号必须增加1。递增适用于事件报告的重新传输和初始实例，以允许接收器检测RTP控制协议（RTCP）接收器报告的丢失数据包。
Receivers can indicate which named events they can handle, for example, by using the Session Description Protocol (RFC 4566 [9]). SDP descriptions using the event payload MUST contain an fmtp format attribute that lists the event values that the receiver can process.
接收者可以指示他们可以处理哪些命名事件，例如，通过使用会话描述协议（RFC 4566[9]）。使用事件有效负载的SDP描述必须包含列出接收器可以处理的事件值的fmtp格式属性。
In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN re-creates the DTMF or other tones 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. The receiver may also choose to delay playout of the tones by some small interval after playout of the preceding audio has ended, to ensure that downstream equipment can discriminate the tones properly.
在网关方案中，将分组语音网络连接到PSTN的Internet电话网关重新创建DTMF或其他音调，并将其注入PSTN。例如，由于DTMF数字识别需要几十毫秒，因此数字的前几毫秒将作为常规音频数据包到达。因此，音频样本和事件之间需要仔细的时间和功率（音量）对齐，以避免在接收器处产生虚假数字。接收机还可以选择在前一音频的播放结束后将音调的播放延迟一小段时间，以确保下游设备能够正确区分音调。
Some implementations send events and encoded audio packets (e.g., PCMU or the codec used for speech signals) for the same time instant for the duration of the event. It is RECOMMENDED that gateways render only the telephone-event payload once it is received, 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.
一些实现在事件持续时间内同时发送事件和编码音频包（例如，PCMU或用于语音信号的编解码器）。建议网关在收到电话事件有效载荷后仅呈现该有效载荷，因为音频可能包含由音频压缩算法引入的杂音。然而，预计这些额外的音调通常不会干扰远端的识别。
Receiver implementations MAY use different algorithms to create tones, including the two described here. (Note that not all implementations have the need to re-create a tone; some may only care about recognizing the events.) With either algorithm, a receiver may impose a playout delay to provide robustness against packet loss or delay. The tradeoff between playout delay and other factors is discussed further in Section 2.6.3.
接收机实现可以使用不同的算法来创建音调，包括这里描述的两种算法。（注意，并非所有实现都需要重新创建音调；有些可能只关心识别事件。）对于这两种算法，接收机都可以施加播放延迟，以提供对分组丢失或延迟的鲁棒性。第2.6.3节将进一步讨论播放延迟和其他因素之间的权衡。
In the first algorithm, 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 one of the following occurs:
或者，接收器可以启动音调并播放，直到出现以下情况之一：
o it receives a packet with the E bit set;
o 它接收设置了E位的数据包；
o it receives the next tone, distinguished by a different timestamp value (noting that new segments of long-duration events also appear with a new timestamp value);
o 它接收下一个音调，以不同的时间戳值区分（注意，长持续时间事件的新段也以新的时间戳值出现）；
o it receives an alternative non-event media stream (assuming none was being received while the event stream was active); or
o 它接收替代的非事件媒体流（假设事件流处于活动状态时未接收到任何媒体流）；或
o a given time period elapses.
o 一个给定的时间段过去了。
This is more robust against packet loss, but may extend the tone beyond its original duration 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". This algorithm is not a license for senders to set the duration field to zero; it MUST be set to the current duration as described, since this is needed to create accurate events if the first event packet is lost, among other reasons.
这对分组丢失更具鲁棒性，但如果事件中最后一个分组的所有重传丢失，则可能会将音调延长到其原始持续时间之外。有必要限制延长音调的时间段，以避免音调“卡住”。此算法不是发件人将持续时间字段设置为零的许可证；必须将其设置为如上所述的当前持续时间，因为如果第一个事件数据包丢失，除其他原因外，这是创建准确事件所必需的。
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.
无论使用哪种算法，音调扩展不应超过三个数据包间隔时间。轻微延长音调持续时间和缩短停顿通常是无害的。
A receiver SHOULD NOT restart a tone once playout has stopped. It MAY do so if the tone is of a type meant for human consumption or is one for which interruptions will not cause confusion at the receiving device.
一旦播放停止，接收器不应重新启动音调。如果音调是供人类使用的类型，或者是中断不会在接收设备上引起混淆的类型，则可以这样做。
If a receiver receives an event packet for an event that it is not currently playing out and the packet does not have the M bit set, earlier packets for that event have evidently been lost. This can be confirmed by gaps in the RTP sequence number. The receiver MAY determine on the basis of retained history and the timestamp and
如果接收器接收到当前未播放的事件的事件数据包，且该数据包未设置M位，则该事件的早期数据包显然已丢失。这可以通过RTP序列号中的间隙来确认。接收机可以基于保留的历史和时间戳来确定
event code of the current packet that it corresponds to an event already played out and lapsed. In that case, further reports for the event MUST be ignored, as indicated in the previous paragraph.
当前数据包的事件代码，该数据包对应于已播放并失效的事件。在这种情况下，如前一段所述，必须忽略事件的进一步报告。
If, on the other hand, the event has not been played out at all, the receiver MAY attempt to play the event out to the complete duration indicated in the event report. The appropriate behavior will depend on the event type, and requires consideration of the relationship of the event to audio media flows and whether correct event duration is essential to the correct operation of the media session.
另一方面，如果事件根本没有播放完，则接收者可尝试播放事件至事件报告中指示的完整持续时间。适当的行为取决于事件类型，需要考虑事件与音频媒体流的关系，以及正确的事件持续时间是否对媒体会话的正确操作至关重要。
A receiver SHOULD NOT rely on a particular event packet spacing, but instead MUST use the event timestamps and durations to determine timing and duration of playout.
接收器不应依赖于特定的事件数据包间隔，而是必须使用事件时间戳和持续时间来确定播放的时间和持续时间。
The receiver MUST calculate 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.
接收器必须根据具有给定时间戳的所有数据包计算RTCP接收器报告的抖动。注：抖动值应主要用作比较两个用户或两个时间段之间接收质量的方法，而不是绝对测量值。
If a zero volume is indicated for an event for which the volume field is defined, then the receiver MAY reconstruct the volume from the volume of non-event audio or MAY use the nominal value specified by the ITU Recommendation or other document defining the tone. This ensures backwards compatibility with RFC 2833 [12], where the volume field was defined only for DTMF events.
如果为定义了音量字段的事件指示零音量，则接收器可以从非事件音频的音量重建音量，或者可以使用ITU建议或定义音调的其他文件指定的标称值。这确保了与RFC 2833[12]的向后兼容性，在RFC 2833[12]中，仅为DTMF事件定义了音量字段。
If an event report is received with duration equal to the maximum duration expressible in the duration field (0xFFFF) and the E bit for the report is not set, the event report may mark the end of a segment generated according to the procedures of Section 2.5.1.3. If another report for the same event type is received, the receiver MUST compare the RTP timestamp for the new event with the sum of the RTP timestamp of the previous report plus the duration (0xFFFF). The receiver uses the absence of a gap between the events to detect that it is receiving a single long-duration event.
如果收到的事件报告的持续时间等于持续时间字段（0xFFFF）中可表示的最大持续时间，且未设置报告的E位，则事件报告可标记根据第2.5.1.3节的程序生成的段的结束。如果收到相同事件类型的另一个报告，则接收方必须将新事件的RTP时间戳与上一个报告的RTP时间戳加上持续时间（0xFFFF）之和进行比较。接收器使用事件之间没有间隙来检测它正在接收单个长持续时间事件。
The total duration of a long-duration event is (obviously) the sum of the durations of the segments used to report it. This is equal to the duration of the final segment (as indicated in the final packet for that segment), plus 0xFFFF multiplied by the number of segments preceding the final segment.
长持续时间事件的总持续时间（显然）是用于报告它的段的持续时间之和。这等于最终段的持续时间（如该段的最终数据包所示），加上0xFFFF乘以最终段之前的段数。
If events are combined as a redundant payload with another payload type using RFC 2198 [2] redundancy, segments are generated at intervals of 0x3FFF or less, rather than 0xFFFF, as required by the procedures of Section 2.5.1.3.1 in this case. If a receiver is using the events component of the payload, event duration may be only an approximate indicator of division into segments, but the lack of an E bit and the adjacency of two reports with the same event code are strong indicators in themselves.
如果使用RFC 2198[2]冗余将事件作为冗余有效负载与另一种有效负载类型组合，则按照第2.5.1.3.1节中的程序的要求，以0x3FFF或更小的间隔生成段，而不是0xFFFF。如果接收器正在使用有效载荷的事件组件，则事件持续时间可能只是划分为段的近似指示器，但是缺少E位和具有相同事件代码的两个报告的邻接本身是强指示器。
The procedures of Section 2.5.1.5 require that if multiple events are reported in the same packet, they are contiguous and non-overlapping. As a result, it is not strictly necessary for the receiver to know the start times of the events following the first one in order to play them out -- it needs only to respect the duration reported for each event. Nevertheless, if knowledge of the start time for a given event after the first one is required, it is equal to the sum of the start time of the preceding event plus the duration of the preceding event.
第2.5.1.5节的程序要求，如果在同一数据包中报告了多个事件，则这些事件是连续且不重叠的。因此，接收者不一定要知道第一个事件之后的事件的开始时间才能播放它们——只需要遵守为每个事件报告的持续时间。然而，如果需要知道第一个事件之后给定事件的开始时间，则它等于前一个事件的开始时间加上前一个事件的持续时间之和。
If the duration of a soft state event expires, the receiver SHOULD consider the value of the state to be "unknown" unless otherwise indicated in the event documentation.
如果软状态事件的持续时间过期，除非事件文档中另有指示，否则接收方应将状态值视为“未知”。
Packet transmission through the Internet is marked by occasional periods of congestion lasting on the order of second, during which network delay, jitter, and packet loss are all much higher than they are in between these periods. Reference [28] characterizes this phenomenon. Well-behaved applications are expected, preferably, to reduce their demands on the network during such periods of congestion. At the least, they should not increase their demands. This section explores both application performance and the possibilities for good behavior in the face of congestion.
通过互联网的数据包传输的特点是偶尔会出现几秒钟的拥塞，在此期间，网络延迟、抖动和数据包丢失都比这两个时间段之间的要高得多。参考文献[28]描述了这种现象。性能良好的应用程序最好能够在这种拥塞期间减少它们对网络的需求。至少，他们不应该增加需求。本节探讨应用程序性能以及在遇到拥塞时良好行为的可能性。
Typically, an implementation of the telephone-event payload will aim to limit the rate at which each of the following impairments occurs:
通常，电话事件有效载荷的实施旨在限制以下每种损伤发生的速率：
a. an event encoded at the sender fails to be played out at the receiver, either because the event report is lost or because it arrives after playout of later content has started;
a. 在发送方编码的事件无法在接收方播放，这可能是因为事件报告丢失，或者是因为它在后期内容播放开始后到达；
b. the start of playout of an event at the receiver is delayed relative to other events or other media operating on the same timestamp base;
b. 相对于在相同时间戳基础上操作的其他事件或其他媒体，在接收器处开始播放事件被延迟；
c. the duration of playout of a given event differs from the correct duration as detected at the sender by more than a given amount;
c. 给定事件的播放持续时间与发送方检测到的正确持续时间相差超过给定量；
d. gaps occur in playout of a given event;
d. 在给定事件的播放过程中出现间隙；
e. end-to-end delay for the media stream exceeds a given value.
e. 媒体流的端到端延迟超过给定值。
The relative importance of these constraints varies between applications.
这些约束的相对重要性因应用程序而异。
To improve reliability, all payload types including telephone-events can use a jitter buffer, i.e., impose a playout delay, at the receiving end. This mechanism addresses the first four requirements listed above, but at the expense of the last one.
为了提高可靠性，包括电话事件在内的所有有效负载类型都可以在接收端使用抖动缓冲器，即施加播放延迟。该机制解决了上面列出的前四个需求，但以牺牲最后一个需求为代价。
The named event procedures provide two complementary redundancy mechanisms to deal with lost packets:
命名事件过程提供两种互补的冗余机制来处理丢失的数据包：
a. Intra-event updates:
a. 事件内更新：
Events that last longer than one packetization period (e.g., 50 ms) are updated periodically, so that the receiver can reconstruct the event and its duration if it receives any of the update packets, albeit with delay.
持续时间超过一个分组化周期（例如，50 ms）的事件被周期性地更新，以便如果接收机接收到任何更新分组（尽管有延迟），则可以重构事件及其持续时间。
During an event, the RTP event payload format provides incremental updates on the event. The error resiliency afforded by this mechanism depends on whether the first or second algorithm in Section 2.5.2.2 is used and on the playout delay at the receiver. For example, if the receiver uses the first algorithm and only places the current duration of tone signal in the playout buffer, for a playout delay of 120 ms and a
在事件期间，RTP事件有效负载格式提供事件的增量更新。该机制提供的错误恢复能力取决于是否使用第2.5.2.2节中的第一个或第二个算法，以及接收机的播放延迟。例如，如果接收机使用第一种算法并且仅将音调信号的当前持续时间放置在播放缓冲器中，则播放延迟为120 ms，并且
packetization interval of 50 ms, two packets in a row can get lost without causing a premature end of the tone generated.
分组间隔为50毫秒，连续两个分组可能丢失，而不会导致生成的音调过早结束。
b. Repeat last event packet:
b. 重复上一个事件包：
As described in Section 2.5.1.4, the last report for an event is transmitted a total of three times. This mechanism adds robustness to the reporting of the end of an event.
如第2.5.1.4节所述，事件的最后报告总共传输三次。此机制增加了事件结束报告的健壮性。
It may be necessary to extend the level of redundancy to achieve requirement a) (in Section 2.6.1) in a specific network environment. Taking the 25-30% loss rate during congestion periods illustrated in [28] as typical, and setting an objective that at least 99% of end-of-event reports will eventually get through to the receiver under these conditions, simple probability calculations indicate that each event completion has to be reported four times. This is one more level of redundancy than required by the basic "Repeat last event packet" algorithm. Of course, the objective is probably unrealistically stringent; it was chosen to make a point.
在特定网络环境中，可能需要扩展冗余级别以达到要求a（第2.6.1节）。以[28]中所示的拥堵期间25-30%的损失率为典型，并设定至少99%的事件结束报告最终将在这些条件下传递给接收者的目标，简单的概率计算表明，每个事件完成必须报告四次。这比基本的“重复最后一个事件包”算法所需的冗余级别多了一个级别。当然，目标可能过于严格；选择它是为了说明问题。
Where Section 2.5.1.4 indicates that it is appropriate to use the RFC 2198 [2] audio redundancy mechanism to carry retransmissions of final event reports, this mechanism MAY also be used to extend the number of final report retransmissions. This is done by using more than two levels of redundancy when necessary. The use of RFC 2198 helps to mitigate the extra bandwidth demands that would be imposed simply by retransmitting final event packets more than three times.
如果第2.5.1.4节指出使用RFC 2198[2]音频冗余机制进行最终事件报告的重传是合适的，则该机制也可用于延长最终报告的重传次数。这是通过在必要时使用两个以上的冗余级别来实现的。RFC 2198的使用有助于减轻额外的带宽需求，这种额外的带宽需求只需将最终事件数据包重传三次以上即可实现。
These two redundancy mechanisms clearly address requirement a) in the previous section. They also help meet requirement c), to the extent that the redundant packets arrive before playout of the events they report is due to expire. They are not helpful in meeting the other requirements, although they do not directly cause impairments themselves in the way that a large jitter buffer increases end-to-end delay.
这两种冗余机制清楚地解决了上一节中的需求a）。它们也有助于满足要求c），因为冗余数据包在它们报告的事件播放到期之前到达。它们在满足其他要求方面没有帮助，尽管它们本身不会以大抖动缓冲器增加端到端延迟的方式直接造成损害。
The playout algorithm is an additional mechanism for meeting the performance requirements. In particular, using the second algorithm in Section 2.5.2.2 will meet requirement d) of the previous section by preventing gaps in playout, but at the potential cost of increases in duration (requirement c)).
播放算法是满足性能要求的附加机制。特别是，使用第2.5.2.2节中的第二种算法将通过防止播放间隔来满足上一节的要求d），但可能会增加持续时间（要求c）。
Finally, there is an interaction between the packetization period used by a sender, the playout delay used by the receiver, and the vulnerability of an event flow to packet losses. Assuming packet losses are independent, a shorter packetization interval means that
最后，发送方使用的打包周期、接收方使用的播放延迟以及事件流对数据包丢失的脆弱性之间存在交互作用。假设数据包丢失是独立的，则较短的分组间隔意味着
the receiver can use a smaller playout delay to recover from a given number of consecutive packet losses, at any stage of event playout. This improves end-to-end delays in applications where that matters.
接收机可以在事件播放的任何阶段使用较小的播放延迟来从给定数量的连续分组丢失中恢复。这改善了重要应用程序中的端到端延迟。
In view of the tradeoffs between the different reliability mechanisms, documentation of specific events SHOULD include a discussion of the appropriate design decisions for the applications of those events. This mandate is repeated in the section on IANA considerations.
鉴于不同可靠性机制之间的权衡，特定事件的文件应包括对这些事件应用的适当设计决策的讨论。关于IANA考虑因素的章节中重复了这一任务。
So far, the discussion has been about meeting performance requirements. However, there is also the question of whether applications of events can adapt to congestion to the point that they reduce their demands on the networks during congestion. In theory this can be done for events by increasing the packetization interval, so that fewer packets are sent per second. This has to be accompanied by an increased playout delay at the receiving end. Coordination between the two ends for this purpose is an interesting issue in itself. If it is done, however, such an action implies a one-time gap or extended playout of an event when the packetization interval is first extended, as well as increased end-to-end delay during the whole period of increased playout delay.
到目前为止，讨论的重点是满足性能要求。然而，还有一个问题是，事件应用程序是否能够适应拥塞，从而在拥塞期间减少对网络的需求。理论上，这可以通过增加分组间隔来实现，这样每秒发送的数据包就更少了。这必须伴随着接收端播放延迟的增加。为此目的，两端之间的协调本身就是一个有趣的问题。但是，如果这样做，则当分组间隔首次延长时，该动作意味着事件的一次性间隔或延长播放时间，以及在整个增加播放时间延迟期间增加的端到端延迟。
The benefit from such a measure varies primarily depending on the average duration of the events being handled. In the worst case, as a first example shows, the reduction in aggregate bandwidth usage due to an increased packetization interval may be quite modest. Suppose the average event duration is 3.33 ms (V.21 bits, for instance). Suppose further that four transmissions in total are required for a given event report to meet the loss objective. Table 1 shows the impact of varying packetization intervals on the aggregate bit rate of the media stream.
这种措施的好处主要取决于所处理事件的平均持续时间。在最坏的情况下，如第一个示例所示，由于分组间隔的增加而导致的聚合带宽使用的减少可能是相当温和的。假设平均事件持续时间为3.33毫秒（例如，V.21位）。进一步假设给定事件报告总共需要四次传输以满足损失目标。表1显示了不同分组间隔对媒体流的聚合比特率的影响。
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 2440 | 48800 |
| 33.3 | 30 | 1800 | 54000 |
| 25 | 40 | 1480 | 59200 |
| 20 | 50 | 1288 | 64400 |
+--------------------+-----------+---------------+------------------+
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 2440 | 48800 |
| 33.3 | 30 | 1800 | 54000 |
| 25 | 40 | 1480 | 59200 |
| 20 | 50 | 1288 | 64400 |
+--------------------+-----------+---------------+------------------+
Table 1: Data Rate at the IP Level versus Packetization Interval (three retransmissions, 3.33 ms per event)
表1:IP级别的数据速率与分组间隔（三次重传，每次事件3.33毫秒）
As can be seen, a doubling of the interval (from 25 to 50 ms) drops aggregate bit rate by about 20% while increasing end-to-end delay by 25 ms and causing a one-time gap of the same amount. (Extending the playout of a specific V.21 tone event is out of the question, so the first algorithm of Section 2.5.2.2 must be used in this application.) The reduction in number of packets per second with longer packetization periods is countered by the increase in packet size due to the increase in number of events per packet.
可以看出，间隔加倍（从25到50毫秒）会使聚合比特率降低约20%，同时使端到端延迟增加25毫秒，并导致相同数量的一次性间隔。（扩展特定V.21音调事件的播放时间是不可能的，因此在本应用中必须使用第2.5.2.2节的第一个算法。）由于每个数据包的事件数量增加，每秒数据包数量的减少与更长的数据包化周期相抵消。
For events of longer duration, the reduction in bandwidth is more proportional to the increase in packetization interval. The loss of final event reports may also be less critical, so that lower redundancy levels are acceptable. Table 2 shows similar data to Table 1, but assuming 70-ms events separated by 50 ms of silence (as in an idealized DTMF-based text messaging session) with only the basic two retransmissions for event completions.
对于持续时间较长的事件，带宽的减少与打包间隔的增加更成比例。最终事件报告的丢失也可能不那么严重，因此可以接受较低的冗余级别。表2显示了与表1类似的数据，但假设70毫秒的事件间隔50毫秒的静默（如在理想化的基于DTMF的文本消息会话中），只有两次基本的事件完成重传。
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 448/520 | 10040 |
| 33.3 | 30 | 448/520 | 14280 |
| 25 | 40 | 448/520 | 18520 |
| 20 | 50 | 448 | 22400 |
+--------------------+-----------+---------------+------------------+
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 448/520 | 10040 |
| 33.3 | 30 | 448/520 | 14280 |
| 25 | 40 | 448/520 | 18520 |
| 20 | 50 | 448 | 22400 |
+--------------------+-----------+---------------+------------------+
Table 2: Data Rate at the IP Level versus Packetization Interval (two retransmissions, 70 ms per event, 50 ms between events)
表2:IP级别的数据速率与分组间隔（两次重传，每个事件70毫秒，事件之间50毫秒）
In the third column of the table, the packet size is 448 bits when only one event is being reported and 520 bits when the previous event is also included. No more than one level of redundancy is needed up to a packetization interval of 50 ms, although at that point most packets are reporting two events. Longer intervals require a second level of redundancy in at least some packets.
在表的第三列中，当仅报告一个事件时，数据包大小为448位，当还包括前一个事件时，数据包大小为520位。在50ms的分组化间隔内，不需要超过一个级别的冗余，尽管此时大多数分组报告两个事件。更长的间隔要求至少在某些数据包中有第二级冗余。
This document defines one class of named events: DTMF tones.
本文档定义了一类命名事件：DTMF音调。
DTMF signalling [10] is typically generated by a telephone set or possibly by a PBX (Private branch telephone exchange). DTMF digits may be consumed by entities such as gateways or application servers in the IP network, or by entities such as telephone switches or IVRs in the circuit switched network.
DTMF信令[10]通常由电话机或PBX（专用分支电话交换机）生成。DTMF数字可由诸如IP网络中的网关或应用服务器之类的实体使用，或由诸如电路交换网络中的电话交换机或IVR之类的实体使用。
The DTMF events support two possible applications at the sending end:
DTMF事件在发送端支持两种可能的应用程序：
1. 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 having low bit-rate codecs like G.723.1 [20] render DTMF tones unintelligible.
1. Internet电话网关检测输入电路上的DTMF，并发送此处描述的RTP有效负载，而不是常规音频数据包。网关可能具有必要的数字信号处理器和算法，因为它通常需要检测DTMF，例如两级拨号。使用网关检测音调可以免除接收互联网终端系统的这项工作，也可以避免像G.723.1[20]这样的低比特率编解码器使DTMF音调无法理解。
2. An Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver.
2. 诸如“互联网电话”之类的互联网终端系统可以模拟DTMF功能，而无需考虑生成精确的音调对，也无需将音调识别的负担强加给接收器。
A similar distinction occurs at the receiving end.
在接收端也有类似的区别。
1. In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN re-creates the DTMF tones or other telephony events and injects them into the PSTN.
1. 在网关场景中，将分组语音网络连接到PSTN的Internet电话网关重新创建DTMF音调或其他电话事件，并将它们注入PSTN。
2. In the end system scenario, the DTMF events are consumed by the receiving entity itself.
2. 在终端系统场景中，DTMF事件由接收实体本身使用。
In the most common application, DTMF tones are sent in one direction only, typically from the calling end. The consuming device is most commonly an IVR. DTMF may alternate with voice from either end. In most cases, the only constraint on tone duration is that it exceed a minimum value. However, in some cases a long-duration tone (in excess of 1-2 seconds) has special significance.
在最常见的应用中，DTMF音调仅向一个方向发送，通常从主叫端发送。消费设备通常是IVR。DTMF可以与来自任意一端的语音交替。在大多数情况下，音调持续时间的唯一限制是超过最小值。然而，在某些情况下，长持续时间音调（超过1-2秒）具有特殊意义。
ITU-T Recommendation Q.24 [11], Table A-1, indicates that the legacy switching equipment in the countries surveyed expects a minimum recognizable signal duration of 40 ms, a minimum pause between signals of 40 ms, and a maximum signalling rate of 8 to 10 digits per second depending on the country. Human-generated DTMF signals, of course, are generally longer with larger pauses between them.
ITU-T建议Q.24[11]，表A-1表明，受调查国家的传统交换设备预计最小可识别信号持续时间为40 ms，信号之间的最小暂停时间为40 ms，最大信令速率为8到10位/秒，具体取决于国家。当然，人类产生的DTMF信号通常较长，其间的停顿也较大。
DTMF tones may also be used for text telephony. This application is documented in ITU-T Recommendation V.18 [27] Annex B. In this case, DTMF is sent alternately from either end (half-duplex mode), with a minimum 300-ms turn-around time. The only constraints on tone durations in this application are that they and the pauses between them must exceed specified minimum values. It is RECOMMENDED that a gateway at the sending end be capable of detecting DTMF signals as specified by V.18 Annex B (tones and pauses >=40 ms), but should send
DTMF音调也可用于文本电话。该应用程序记录在ITU-T建议V.18[27]附录B中。在这种情况下，DTMF从任意一端交替发送（半双工模式），最小周转时间为300 ms。在此应用程序中，音调持续时间的唯一限制是它们和它们之间的暂停必须超过指定的最小值。建议发送端的网关能够检测V.18附录B中规定的DTMF信号（音调和暂停>=40 ms），但应发送
event durations corresponding to those of a V.18 DTMF sender (tones >=70 ms, pauses >=50 ms). This may occasionally imply some degree of buffering of outgoing events, but if the source terminal conforms to V.18 Annex B, this should not get out of hand.
与V.18 DTMF发送器对应的事件持续时间（音调>=70毫秒，暂停>=50毫秒）。这可能偶尔意味着对传出事件进行某种程度的缓冲，但如果源终端符合V.18附录B，则这不应失控。
Since minor increases in tone duration are harmless for all applications of DTMF, but unintended breaks in playout of a DTMF digit can confuse the receiving endpoint by creating the appearance of extra digits, receiving applications that are converting DTMF events back to tones SHOULD use the second playout algorithm rather than the first one in Section 2.5.2.2. This provides some robustness against packet loss or congestion.
由于音调持续时间的轻微增加对DTMF的所有应用都是无害的，但DTMF数字播放中的意外中断会造成额外数字的出现，从而混淆接收端点，接收将DTMF事件转换回音调的应用程序时，应使用第二种播放算法，而不是第2.5.2.2节中的第一种算法。这提供了一些抗数据包丢失或拥塞的健壮性。
Table 3 shows the DTMF-related event codes within the telephone-event payload format. The DTMF digits 0-9 and * and # are commonly supported. DTMF digits A through D are less frequently encountered, typically in special applications such as military networks.
表3显示了电话事件有效负载格式中的DTMF相关事件代码。通常支持DTMF数字0-9和*和#。DTMF数字A到D不太常见，通常在军事网络等特殊应用中。
+-------+--------+------+---------+
| Event | Code | Type | Volume? |
+-------+--------+------+---------+
| 0--9 | 0--9 | tone | yes |
| * | 10 | tone | yes |
| # | 11 | tone | yes |
| A--D | 12--15 | tone | yes |
+-------+--------+------+---------+
+-------+--------+------+---------+
| Event | Code | Type | Volume? |
+-------+--------+------+---------+
| 0--9 | 0--9 | tone | yes |
| * | 10 | tone | yes |
| # | 11 | tone | yes |
| A--D | 12--15 | tone | yes |
+-------+--------+------+---------+
Table 3: DTMF Named Events
表3：DTMF命名事件
The key considerations for the delivery of DTMF events are reliability and avoidance of unintended breaks within the playout of a given tone. End-to-end round-trip delay is not a major consideration except in the special case where DTMF tones are being used for text telephony. Assuming that, as recommended in Section 3.1 above, the second playout algorithm of Section 2.5.2.2 is in use, a temporary increase in packetization interval to as much as 100 ms or double the normal interval, whichever is less, should be harmless.
DTMF事件交付的关键考虑因素是可靠性和避免在给定音调播放过程中出现意外中断。端到端往返延迟不是主要考虑因素，除非在文本电话使用DTMF音的特殊情况下。假设按照上述第3.1节的建议，第2.5.2.2节中的第二个播放算法正在使用，则将打包间隔临时增加至100ms或正常间隔的两倍（以较小者为准）应该是无害的。
As an alternative to describing tones and events by name, as described in Section 2, 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.
作为第2节中描述的按名称描述音调和事件的替代方法，有时最好通过其波形特性来描述音调和事件。特别是，识别比命名信号更快，因为它不依赖于识别持续时间或暂停。
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, ITU-T Recommendation E.180 [18] notes that across all countries, these tones share a number of characteristics:
对于电话铃声，如拨号音、铃声（回铃）、忙音、拥塞（“快速忙音”）、特别公告音或其他一些特殊铃声，如付费电话识别、呼叫等待或录音音，没有单一的国际标准。然而，ITU-T建议E.180[18]指出，在所有国家，这些音调都有许多共同特征：
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 In-band tones for telephony events are in the range of 25 Hz (ringing tone in Angola) to 2600 Hz (the tone used for line signalling in SS No. 5 and R1). The in-band telephone frequency range is limited to 3400 Hz. R2 defines a 3825 Hz out-of-band tone for line signalling on analogue trunks. (The piano has a range from 27.5 to 4186 Hz.)
o 电话事件的带内音调范围为25 Hz（安哥拉的铃声）至2600 Hz（SS 5和R1中用于线路信令的音调）。带内电话频率范围限制为3400 Hz。R2为模拟中继线上的线路信令定义了3825 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.
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 4 summarizes some common tones. The rows labeled "ITU ..." refer to ITU-T Recommendation E.180 [18]. In these rows, the on and off durations are suggested ranges within which local standards would set specific values. The symbol "+" in the table indicates addition of the tones, without modulation, while "*" indicates amplitude modulation.
作为对实施者的帮助，表4总结了一些常见的音调。标有“ITU…”的行参考ITU-T建议E.180[18]。在这些行中，打开和关闭持续时间是建议的范围，本地标准将在该范围内设置特定值。表中的符号“+”表示添加音调，不进行调制，而“*”表示振幅调制。
+-------------------------+-------------------+----------+----------+
| Tone Name | Frequency | On Time | Off Time |
| | | (s) | (s) |
+-------------------------+-------------------+----------+----------+
| 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 bit | 980 or 1180 or | 0.00333 | -- |
| | 1650 or 1850 | | |
| ------------- | ---------- | -------- | -------- |
| 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 | 0.1-0.6 | 0.1-0.7 |
| U.S. busy tone | 480+620 | 0.5 | 0.5 |
| ITU congestion tone | 425 | 0.1-0.6 | 0.1-0.7 |
| U.S. congestion tone | 480+620 | 0.25 | 0.25 |
+-------------------------+-------------------+----------+----------+
+-------------------------+-------------------+----------+----------+
| Tone Name | Frequency | On Time | Off Time |
| | | (s) | (s) |
+-------------------------+-------------------+----------+----------+
| 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 bit | 980 or 1180 or | 0.00333 | -- |
| | 1650 or 1850 | | |
| ------------- | ---------- | -------- | -------- |
| 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 | 0.1-0.6 | 0.1-0.7 |
| U.S. busy tone | 480+620 | 0.5 | 0.5 |
| ITU congestion tone | 425 | 0.1-0.6 | 0.1-0.7 |
| U.S. congestion tone | 480+620 | 0.25 | 0.25 |
+-------------------------+-------------------+----------+----------+
Table 4: Examples of Telephony Tones
表4：电话铃声示例
The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 4.3.3 begins at that time.
RTP时间戳反映了当前数据包的测量点。第4.3.3节中描述的事件持续时间从该时间开始。
The tone payload type uses the marker bit to distinguish the first RTP packet reporting a given instance of a tone from succeeding packets for that tone. The marker bit SHOULD be set to 1 for the first packet, and to 0 for all succeeding packets relating to the same tone.
音调有效负载类型使用标记位来区分报告给定音调实例的第一个RTP分组与该音调的后续分组。对于第一个数据包，标记位应设置为1，对于与同一音调相关的所有后续数据包，标记位应设置为0。
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 media type is "audio/tone".) The default timestamp rate is 8000 Hz, but other rates may be defined. Note that the timestamp rate does not affect the interpretation of the frequency, just the durations.
基于上述特征，本文档定义了一种称为“音调”的RTP有效载荷格式，该格式可以表示由一个或多个频率组成的音调。（相应的媒体类型为“音频/音调”。）默认时间戳速率为8000 Hz，但可以定义其他速率。请注意，时间戳速率不影响频率的解释，只影响持续时间。
In accordance with current practice, this payload format does not have a static payload type number, but uses an RTP payload type number established dynamically and out-of-band.
根据当前实践，此有效负载格式没有静态有效负载类型编号，但使用动态和带外建立的RTP有效负载类型编号。
The payload format is shown in Figure 2.
有效负载格式如图2所示。
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 2: Payload Format for Tones
图2：音调的有效负载格式
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. Note that the amplitude of modulation is not indicated in the payload and must be determined by out-of-band means.
调制：调制频率，单位为Hz。该字段为9位无符号整数，允许调制频率高达511 Hz。如果没有调制，该字段的值为零。注意，有效载荷中未指示调制幅度，必须通过带外方式确定。
T: If the T bit is set (one), the modulation frequency is to be divided by three. Otherwise, the modulation frequency is taken as is.
T：如果设置了T位（1），则调制频率将除以3。否则，调制频率按原样取。
This bit allows frequencies accurate to 1/3 Hz, since modulation frequencies such as 16 2/3 Hz are in practical use.
该位允许频率精确到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 and presented in network byte order. The tone begins at the instant identified by the RTP timestamp and lasts for the duration value. The value of zero is not permitted, and tones with such a duration SHOULD be ignored.
持续时间：音调的持续时间，以时间戳单位测量，并以网络字节顺序显示。音调从RTP时间戳标识的瞬间开始，持续时间值。不允许值为零，并且应忽略具有此持续时间的音调。
The definition of duration corresponds to that for sample-based codecs, where the timestamp represents the sampling point for the first sample.
持续时间的定义与基于样本的编解码器的定义相对应，其中时间戳表示第一个样本的采样点。
frequency: The frequencies of the tones to be added, measured in Hz and represented as a 12-bit unsigned integer. The field size is sufficient to represent frequencies up to 4095 Hz, which exceeds the range of telephone systems. A value of zero indicates silence. A single tone can contain any number of frequencies. If no frequencies are specified, the packet reports a period of silence.
频率：要添加的音调的频率，单位为Hz，表示为12位无符号整数。字段大小足以表示高达4095 Hz的频率，这超出了电话系统的范围。值为零表示静默。单音可以包含任意数量的频率。如果未指定频率，则数据包报告一段静默时间。
R: This field is reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it.
R：此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz.
“速率”参数描述采样速率，单位为赫兹。该数字被写为整数。如果省略，默认值为8000 Hz。
This section defines the procedures associated with the tone payload type.
本节定义了与音调有效负载类型相关的程序。
The sender MAY send an initial tones packet as soon as a tone is recognized, or MAY wait until a pre-negotiated packetization period has elapsed. The first RTP packet for a tone SHOULD have the marker bit set to 1.
发送方可以在识别出音调后立即发送初始音调分组，或者可以等待直到经过预协商的分组化周期。音调的第一个RTP数据包的标记位应设置为1。
In the case of longer-duration tones, the sender SHOULD generate multiple RTP packets for the same tone instance. The RTP timestamp MUST be updated for each packet generated (in contrast, for instance, to the timestamp for packets carrying telephone events). Subsequent packets for the same tone SHOULD have the marker bit set to 0, and the RTP timestamp in each subsequent packet MUST equal the sum of the timestamp and the duration in the preceding packet.
对于持续时间较长的音调，发送方应为同一音调实例生成多个RTP数据包。必须为生成的每个数据包更新RTP时间戳（例如，与承载电话事件的数据包的时间戳相反）。相同音调的后续数据包的标记位应设置为0，并且每个后续数据包中的RTP时间戳必须等于前一数据包中的时间戳和持续时间之和。
A final RTP packet MAY be generated as soon as the end of the tone is detected, without waiting for the latest packetization period to elapse.
一旦检测到音调结束，就可以生成最终RTP分组，而不必等待最近的分组化周期过去。
The telephone-event payload described in Section 2 is inherently redundant, in that later packets for the same event carry all of the earlier history of the event except for variations in volume. In contrast, each packet for the tone payload type stands alone; a lost packet means a gap in the information available at the receiving end. Thus, for increased reliability, the sender SHOULD combine new and old tone reports in the same RTP packet using RFC 2198 [2] audio redundancy.
第2节中描述的电话事件有效载荷本质上是冗余的，因为同一事件的后续数据包包含事件的所有早期历史，但音量变化除外。相反，音调有效载荷类型的每个分组是独立的；丢失的数据包是指接收端可用信息中的间隙。因此，为了提高可靠性，发送方应使用RFC 2198[2]音频冗余将新的和旧的音调报告组合在同一RTP包中。
Receiving implementations play out the tones as received, typically with a playout delay to allow for lost packets. When playing out successive tone reports for the same tone (marker bit is zero, the RTP timestamp is contiguous with that of the previous RTP packet, and payload content is identical), the receiving implementation SHOULD continue the tone without change or a break.
接收实现按接收方式播放音调，通常具有播放延迟以允许丢失数据包。当播放同一音调的连续音调报告时（标记位为零，RTP时间戳与前一个RTP数据包的时间戳相邻，有效负载内容相同），接收实现应继续该音调而不改变或中断。
If the sender determines that packets are being lost due to congestion (e.g., through RTCP receiver reports), it SHOULD increase the packetization interval for initial and interim tone reports so as to reduce traffic volume to the receiver. The degree to which this is possible without causing damaging consequences at the receiving end depends both upon the playout delay used at that end and upon the specific application associated with the tones. Both the maximum packetization interval and maximum increase in packetization interval at any one time are therefore a matter of configuration or out-of-band negotiation.
如果发送方确定数据包由于拥塞而丢失（例如，通过RTCP接收器报告），则应增加初始和中间音调报告的数据包化间隔，以减少对接收器的通信量。这在接收端不造成破坏性后果的情况下可能达到的程度取决于该端使用的播放延迟和与音调相关联的特定应用。因此，任何时候的最大打包间隔和打包间隔的最大增加都是配置或带外协商的问题。
Consider a DTMF dialling sequence, where the user dials the digits "911" and a sending gateway detects them. The first digit is 200 ms long (1600 timestamp units) and starts at time 0; the second digit lasts 250 ms (2000 timestamp units) and starts at time 880 ms (7040 timestamp units); the third digit is pressed at time 1.4 s (11,200 timestamp units) and lasts 220 ms (1760 timestamp units). The frame duration is 50 ms.
考虑DTMF拨号序列，其中用户拨数字“911”，发送网关检测它们。第一个数字长200毫秒（1600个时间戳单位），从时间0开始；第二个数字持续250毫秒（2000个时间戳单位），开始于880毫秒（7040个时间戳单位）；第三个数字在时间1.4秒（11200个时间戳单位）时按下，持续220毫秒（1760个时间戳单位）。帧持续时间为50毫秒。
Table 5 shows the complete sequence of events assuming that only the telephone-event payload type is being reported. For simplicity: the timestamp is assumed to begin at 0, the RTP sequence number at 1, and volume settings are omitted.
表5显示了假设仅报告电话事件有效负载类型的完整事件序列。为简单起见：假定时间戳从0开始，RTP序列号为1，并且省略了卷设置。
+-------+-----------+------+--------+------+--------+--------+------+
| Time | Event | M | Time- | Seq | Event | Dura- | E |
| (ms) | | bit | stamp | No | Code | tion | bit |
+-------+-----------+------+--------+------+--------+--------+------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" |
| | packet 3 | | | | | | |
| | sent | | | | | | |
| 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
+-------+-----------+------+--------+------+--------+--------+------+
| Time | Event | M | Time- | Seq | Event | Dura- | E |
| (ms) | | bit | stamp | No | Code | tion | bit |
+-------+-----------+------+--------+------+--------+--------+------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" |
| | packet 3 | | | | | | |
| | sent | | | | | | |
| 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 7 | 1 | 400 | "0" |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | RTP | "0" | 7040 | 11 | 1 | 2000 | "0" |
| | packet 9 | | | | | | |
| | sent | | | | | | |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1180 | RTP | "0" | 7040 | 12 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1230 | RTP | "0" | 7040 | 13 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 14 | 1 | 400 | "0" |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 11200 | 18 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | sent | | | | | | |
| 1700 | RTP | "0" | 11200 | 19 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1750 | RTP | "0" | 11200 | 20 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
+-------+-----------+------+--------+------+--------+--------+------+
| 930 | RTP | "1" | 7040 | 7 | 1 | 400 | "0" |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | RTP | "0" | 7040 | 11 | 1 | 2000 | "0" |
| | packet 9 | | | | | | |
| | sent | | | | | | |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1180 | RTP | "0" | 7040 | 12 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1230 | RTP | "0" | 7040 | 13 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 14 | 1 | 400 | "0" |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 11200 | 18 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | sent | | | | | | |
| 1700 | RTP | "0" | 11200 | 19 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1750 | RTP | "0" | 11200 | 20 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
+-------+-----------+------+--------+------+--------+--------+------+
Table 5: Example of Event Reporting
表5：事件报告示例
Table 6 shows the same sequence assuming that only the tone payload type is being reported. This looks somewhat different. For simplicity: the timestamp is assumed to begin at 0, the sequence number at 1. Volume, the T bit, and the modulation frequency are omitted. The latter two are always 0.
表6显示了相同的序列，假设仅报告音调有效负载类型。这看起来有些不同。为简单起见：假定时间戳从0开始，序列号从1开始。省略音量、T位和调制频率。后两者始终为0。
+-------+-----------+-----+--------+------+--------+-------+--------+
| Time | Event | M | Time- | Seq | Dura- | Freq 1| Freq 2 |
| (ms) | | bit | stamp | No | tion | (Hz) | (Hz) |
+-------+-----------+-----+--------+------+--------+-------+--------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 400 | 852 | 1477 |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 400 | 2 | 400 | 852 | 1477 |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 200 | RTP | "0" | 1200 | 4 | 400 | 852 | 1477 |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 5 | 400 | 697 | 1209 |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| 980 | RTP | "0" | 7440 | 6 | 400 | 697 | 1209 |
| | packet 6 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 10 | 400 | 697 | 1209 |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 12800 | 14 | 160 | 697 | 1209 |
| | packet 14 | | | | | | |
| | sent | | | | | | |
+-------+-----------+-----+--------+------+--------+-------+--------+
Table 6: Example of Tone Reporting
+-------+-----------+-----+--------+------+--------+-------+--------+
| Time | Event | M | Time- | Seq | Dura- | Freq 1| Freq 2 |
| (ms) | | bit | stamp | No | tion | (Hz) | (Hz) |
+-------+-----------+-----+--------+------+--------+-------+--------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 400 | 852 | 1477 |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 400 | 2 | 400 | 852 | 1477 |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 200 | RTP | "0" | 1200 | 4 | 400 | 852 | 1477 |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 5 | 400 | 697 | 1209 |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| 980 | RTP | "0" | 7440 | 6 | 400 | 697 | 1209 |
| | packet 6 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 10 | 400 | 697 | 1209 |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 12800 | 14 | 160 | 697 | 1209 |
| | packet 14 | | | | | | |
| | sent | | | | | | |
+-------+-----------+-----+--------+------+--------+-------+--------+
Table 6: Example of Tone Reporting
Now consider a combined payload, where the tone payload is the primary payload type and the event payload is treated as a redundant encoding (one level of redundancy). Because the primary payload is tones, the tone payload rules determine the setting of the RTP header fields. This means that the RTP timestamp always advances. As a corollary, the timestamp offset for the events payload in the RFC 2198 header increases by the same amount.
现在考虑一个组合的有效载荷，其中音调有效载荷是主要的有效载荷类型，并且事件有效载荷被视为冗余编码（一个冗余级别）。由于主要有效载荷是音调，因此音调有效载荷规则确定RTP报头字段的设置。这意味着RTP时间戳总是提前。作为推论，RFC 2198报头中的事件有效负载的时间戳偏移增加相同的量。
One issue that has to be considered in a combined payload is how to handle retransmissions of final event reports. The tone payload specification does not recommend retransmissions of final packets, so it is unclear what to put in the primary payload fields of the combined packet. In the interests of simplicity, it is suggested that the retransmitted packets copy the fields relating to the primary payload (including the RTP timestamp) from the original packet. The same principle can be applied if the packet includes multiple levels of event payload redundancy.
在组合有效载荷中必须考虑的一个问题是如何处理最终事件报告的重传。音调有效载荷规范不建议重新传输最终分组，因此不清楚在组合分组的主要有效载荷字段中放置什么。为了简单起见，建议重传分组从原始分组复制与主有效载荷（包括RTP时间戳）相关的字段。如果数据包包括多个级别的事件有效负载冗余，则可以应用相同的原理。
The figures below all illustrate "RTP packet 14" in the above tables. Figure 3 shows an event-only payload, corresponding to Table 5. Figure 4 shows a tone-only payload, corresponding to Table 6. Finally, Figure 5 shows a combined payload, with tones primary and events as a single redundant layer. Note that the combined payload has the RTP sequence numbers shown in Table 5, because the transmitted sequence includes the retransmitted packets.
下图均说明了上表中的“RTP数据包14”。图3显示了与表5相对应的仅事件有效负载。图4显示了与表6相对应的纯音频有效负载。最后，图5显示了一个组合的有效负载，其中音调和事件作为一个单一的冗余层。注意，组合的有效载荷具有表5中所示的RTP序列号，因为发送的序列包括重传的分组。
Figure 3 assumes that the following SDP specification was used. This session description provides for separate streams of G.729 [21] audio and events. Packets reported within the G.729 stream are not considered here.
图3假设使用了以下SDP规范。本会话描述提供了G.729[21]音频和事件的单独流。此处不考虑G.729流中报告的数据包。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
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| 100 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 100 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example RTP Packet for Event Payload
图3：事件负载的示例RTP数据包
Figure 4 assumes that an SDP specification similar to that of the previous case was used.
图4假设使用了与前一个案例类似的SDP规范。
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 101
a=rtpmap:101 tone/8000
a=ptime:50
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 101
a=rtpmap:101 tone/8000
a=ptime:50
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| 101 | 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 12800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
| 0 |0| 20 | 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
|0 0 0 0| 697 |0 0 0 0| 1209 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 101 | 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 12800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
| 0 |0| 20 | 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
|0 0 0 0| 697 |0 0 0 0| 1209 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example RTP Packet for Tone Payload
图4：音调有效负载的RTP包示例
Figure 5, for the combined payload, assumes the following SDP session description:
图5，对于组合有效负载，假设以下SDP会话描述：
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 102 101 100
a=rtpmap:102 red/8000/1
a=fmtp:102 101/100
a=rtpmap:101 tone/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 102 101 100
a=rtpmap:102 red/8000/1
a=fmtp:102 101/100
a=rtpmap:101 tone/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
For ease of presentation, Figure 5 presents the actual payloads as if they began on 32-bit boundaries. In the actual packet, they follow immediately after the end of the RFC 2198 header, and thus are displaced one octet into successive words.
为了便于演示，图5显示了实际有效负载，就好像它们是从32位边界开始的一样。在实际数据包中，它们紧跟在RFC 2198报头的末尾之后，因此将一个八位组替换为连续的字。
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| 102 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 12800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 100 | 1600 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | event payload begins ... /
|0| 101 | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 102 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 12800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 100 | 1600 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | event payload begins ... /
|0| 101 | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event payload
事件有效载荷
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tone payload
音频有效载荷
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
| 0 |0| 20 | 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
|0 0 0 0| 697 |0 0 0 0| 1209 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
| 0 |0| 20 | 160 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
|0 0 0 0| 697 |0 0 0 0| 1209 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example RTP Packet for Combined Tone and Event Payloads
图5：组合音调和事件有效载荷的示例RTP数据包
RTP packets using the payload formats defined in this specification are subject to the security considerations discussed in the RTP specification (RFC 3550 [5]), and any appropriate RTP profile (for example, RFC 3551 [13]). The RFC 3550 discussion focuses on requirements for confidentiality. Additional security considerations relating to implementation are described in RFC 2198 [2].
使用本规范中定义的有效负载格式的RTP数据包受RTP规范（RFC 3550[5]）和任何适当RTP配置文件（例如，RFC 3551[13]）中讨论的安全注意事项的约束。RFC 3550讨论的重点是保密要求。RFC 2198[2]中描述了与实施相关的其他安全注意事项。
The telephone-event payload defined in this specification is highly compressed. A change in value of just one bit can result in a major change in meaning as decoded at the receiver. Thus, message integrity MUST be provided for the telephone-event payload type.
本规范中定义的电话事件有效负载是高度压缩的。仅一位值的变化可能导致接收器解码时意义的重大变化。因此，必须为电话事件有效负载类型提供消息完整性。
To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP) [7].
为了满足机密性和完整性保护的需要，兼容的实现应该实现安全实时传输协议（SRTP）[7]。
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提供的保护等效的保护。
Provided that gateway design includes robust, low-overhead tone generation, 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.
如果网关设计包括稳健的、低开销的音调生成，则该有效负载类型在用于分组处理的接收器端计算复杂度方面不会表现出任何显著的非均匀性，从而导致潜在的拒绝服务威胁。
This document updates the descriptions of two RTP payload formats, 'telephone-event' and 'tone', and associated Internet media types, audio/telephone-event and audio/tone. It also documents the event codes for DTMF tone events.
本文档更新了两种RTP有效负载格式“电话事件”和“音调”的描述，以及相关的互联网媒体类型、音频/电话事件和音频/音调。它还记录了DTMF音调事件的事件代码。
Within the audio/telephone-event type, events MUST be registered with IANA. Registrations are subject to the policies "Specification Required" and "Expert Review" as defined in RFC 2434 [3]. The IETF-appointed expert must ensure that:
在音频/电话事件类型中，事件必须向IANA注册。注册须遵守RFC 2434[3]中定义的“要求规范”和“专家审查”政策。IETF指定的专家必须确保：
a. the meaning and application of the proposed events are clearly documented;
a. 明确记录拟定事件的含义和应用；
b. the events cannot be represented by existing event codes, possibly with some minor modification of event definitions;
b. 现有事件代码无法表示事件，可能对事件定义进行了一些小的修改；
c. the number of events is the minimum necessary to fulfill the purpose of their application(s).
c. 事件数量是实现其应用目的所需的最小数量。
The expert is further responsible for providing guidance on the allocation of event codes to the proposed events. Specifically, the expert must indicate whether the event appears to be the same as one defined in RFC 2833 but not specified in any new document. In this case, the event code specified in RFC 2833 for that event SHOULD be assigned to the proposed event. Otherwise, event codes MUST be assigned from the set of available event codes listed below. If this set is exhausted, the criterion for assignment from the reserved set of event codes is to first assign those that appear to have the lowest probability of being revived in their RFC 2833 meaning in a new specification.
专家还负责就拟议事件的事件代码分配提供指导。具体而言，专家必须指出事件是否与RFC 2833中定义的事件相同，但未在任何新文件中指定。在这种情况下，应将RFC 2833中为该事件指定的事件代码分配给提议的事件。否则，必须从下面列出的一组可用事件代码中指定事件代码。如果该集合用尽，则从保留的事件代码集合进行分配的标准是首先分配那些在新规范中RFC 2833含义中似乎具有最低恢复概率的代码。
The documentation for each event MUST indicate whether the event is a state, tone, or other type of event (e.g., an out-of-band electrical event such as on-hook or an indication that will not itself be played out as tones at the receiving end). For tone events, the documentation MUST indicate whether the volume field is applicable or must be set to 0.
每个事件的文档必须表明事件是状态、音调还是其他类型的事件（例如，带外电气事件，如挂机事件或本身不会在接收端作为音调播放的指示）。对于音调事件，文档必须指明音量字段是否适用或必须设置为0。
In view of the tradeoffs between the different reliability mechanisms discussed in Section 2.6, documentation of specific events SHOULD include a discussion of the appropriate design decisions for the applications of those events.
鉴于第2.6节讨论的不同可靠性机制之间的权衡，特定事件的文件应包括对这些事件应用的适当设计决策的讨论。
Legal event codes range from 0 to 255. The initial registry content is shown in Table 7, and consists of the sixteen events defined in Section 3 of this document. The remaining codes have the following disposition:
法律事件代码的范围从0到255。初始注册表内容如表7所示，由本文件第3节中定义的16个事件组成。其余代码具有以下配置：
o codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available for assignment;
o 代码17-22、50-51、90-95、113-120、169和206-255可供分配；
o codes 23-40, 49, and 52-63 are reserved for events defined in [16];
o 代码23-40、49和52-63为[16]中定义的事件保留；
o codes 121-137 and 174-205 are reserved for events defined in [17];
o 代码121-137和174-205为[17]中定义的事件保留；
o codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved in the first instance for specifications reviving the corresponding RFC 2833 events, and in the second instance for general assignment after all other codes have been assigned.
o 代码16、41-48、64-88、96-112、138-168和170-173在第一个实例中保留，用于规范恢复相应的RFC 2833事件，在第二个实例中保留，用于分配所有其他代码后的一般分配。
+------------+--------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+--------------------------------+-----------+
| 0 | DTMF digit "0" | RFC 4733 |
| 1 | DTMF digit "1" | RFC 4733 |
| 2 | DTMF digit "2" | RFC 4733 |
| 3 | DTMF digit "3" | RFC 4733 |
| 4 | DTMF digit "4" | RFC 4733 |
| 5 | DTMF digit "5" | RFC 4733 |
| 6 | DTMF digit "6" | RFC 4733 |
| 7 | DTMF digit "7" | RFC 4733 |
| 8 | DTMF digit "8" | RFC 4733 |
| 9 | DTMF digit "9" | RFC 4733 |
| 10 | DTMF digit "*" | RFC 4733 |
| 11 | DTMF digit "#" | RFC 4733 |
| 12 | DTMF digit "A" | RFC 4733 |
| 13 | DTMF digit "B" | RFC 4733 |
| 14 | DTMF digit "C" | RFC 4733 |
| 15 | DTMF digit "D" | RFC 4733 |
+------------+--------------------------------+-----------+
+------------+--------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+--------------------------------+-----------+
| 0 | DTMF digit "0" | RFC 4733 |
| 1 | DTMF digit "1" | RFC 4733 |
| 2 | DTMF digit "2" | RFC 4733 |
| 3 | DTMF digit "3" | RFC 4733 |
| 4 | DTMF digit "4" | RFC 4733 |
| 5 | DTMF digit "5" | RFC 4733 |
| 6 | DTMF digit "6" | RFC 4733 |
| 7 | DTMF digit "7" | RFC 4733 |
| 8 | DTMF digit "8" | RFC 4733 |
| 9 | DTMF digit "9" | RFC 4733 |
| 10 | DTMF digit "*" | RFC 4733 |
| 11 | DTMF digit "#" | RFC 4733 |
| 12 | DTMF digit "A" | RFC 4733 |
| 13 | DTMF digit "B" | RFC 4733 |
| 14 | DTMF digit "C" | RFC 4733 |
| 15 | DTMF digit "D" | RFC 4733 |
+------------+--------------------------------+-----------+
Table 7: audio/telephone-event Event Code Registry
表7：音频/电话事件代码注册表
This registration is done in accordance with [6] and [8].
本注册按照[6]和[8]进行。
Type name: audio
类型名称：音频
Subtype name: telephone-event
子类型名称：电话事件
Required parameters: none.
所需参数：无。
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 be either a single integer providing the value of an event code or an integer followed by a hyphen and a larger integer, presenting a range of consecutive event code values. The list does not have to be sorted. No white space is allowed in the argument. The union of all of the individual event codes and event code ranges designates the complete set of event numbers supported by the implementation. If the "events" parameter is omitted, support for events 0-15 (the DTMF tones) is assumed.
“events”参数列出了实现支持的事件。事件以一个或多个逗号分隔的元素列出。每个元素可以是提供事件代码值的单个整数，也可以是后跟连字符和较大整数的整数，表示一系列连续的事件代码值。列表不必排序。参数中不允许有空格。所有单个事件代码和事件代码范围的并集指定了实现支持的完整事件编号集。如果省略“events”（事件）参数，则假定支持事件0-15（DTMF音调）。
The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz.
“速率”参数描述采样速率，单位为赫兹。该数字被写为整数。如果省略，默认值为8000 Hz。
Encoding considerations:
编码注意事项：
In the terminology defined by [8] section 4.8, this type is framed and binary.
在[8]第4.8节定义的术语中，该类型为框架和二进制。
Security considerations:
安全考虑：
See Section 6, "Security Considerations", in this document.
见本文件第6节“安全注意事项”。
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:
其他信息：
Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.
幻数：不适用。文件扩展名：不适用。Macintosh文件类型代码：不适用。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Tom Taylor, taylor@nortel.com. IETF AVT Working Group.
汤姆·泰勒，taylor@nortel.com. IETF AVT工作组。
Intended usage: COMMON.
预期用途：普通。
Restrictions on usage:
使用限制：
This type is defined only for transfer via RTP [5].
此类型仅为通过RTP传输而定义[5]。
Author: IETF Audio/Video Transport Working Group.
作者：IETF音频/视频传输工作组。
Change controller:
更改控制器：
IETF Audio/Video Transport Working Group as delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
This registration is done in accordance with [6] and [8].
本注册按照[6]和[8]进行。
Type name: audio
类型名称：音频
Subtype name: tone
子类型名称：音调
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
The "rate" parameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz.
“速率”参数描述采样速率，单位为赫兹。该数字被写为整数。如果省略，默认值为8000 Hz。
Encoding considerations:
编码注意事项：
In the terminology defined by [8] section 4.8, this type is framed and binary.
在[8]第4.8节定义的术语中，该类型为框架和二进制。
Security considerations:
安全考虑：
See Section 6, "Security Considerations", in this document.
见本文件第6节“安全注意事项”。
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.
tone audio子类型支持传输纯合成音，例如，当前电话系统中常用的用于发出呼叫进程信号的合成音。
Additional information:
其他信息：
Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.
幻数：不适用。文件扩展名：不适用。Macintosh文件类型代码：不适用。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Tom Taylor, taylor@nortel.com. IETF AVT Working Group.
汤姆·泰勒，taylor@nortel.com. IETF AVT工作组。
Intended usage: COMMON.
预期用途：普通。
Restrictions on usage:
使用限制：
This type is defined only for transfer via RTP [5].
此类型仅为通过RTP传输而定义[5]。
Author: IETF Audio/Video Transport Working Group.
作者：IETF音频/视频传输工作组。
Change controller:
更改控制器：
IETF Audio/Video Transport Working Group as delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
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上对音调进行紧凑编码的想法背后的能量。
In RFC 2833, the suggestions of the Megaco working group were acknowledged. Colin Perkins and Magnus Westerland, Chairs of the AVT Working Group, provided helpful advice in the formation of the present document. Over the years, detailed advice and comments for RFC 2833, this document, or both were provided by Hisham Abdelhamid, Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom, Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Tim Melanchuk, Kai Miao, Satish Mundra, Kevin Noll, Vern Paxson, Oren Peleg, Raghavendra Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi, Yaakov Stein, Mira Stevanovic, Alex Urquizo, and Herb Wildfeur.
在RFC 2833中，Megaco工作组的建议得到了认可。AVT工作组主席Colin Perkins和Magnus Westerland为本文件的编写提供了有益的建议。多年来，Hisham Abdelhamid、Flemming Andreasen、Fred Burg、Steve Casner、Dan Delelabato、Fatih Erdin、Bill Foster、Mike Fox、Mehryar Garakani、Gunnar Hellstrom、Rajesh Kumar、Terry Lyons、Steve Magnell、Zarko Markov、Tim Melanchuk、Kai Miao、Satish Mundra、，Kevin Noll、Vern Paxson、Oren Peleg、Raghavendra Prabhu、Moshe Samoha、Todd Sherr、Adrian Soncodi、Yaakov Stein、Mira Stevanovic、Alex Urquizo和Herb Wildfour。
[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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[5] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[6] Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 3555，2003年7月。
[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[7] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[9] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[10] International Telecommunication Union, "Technical features of push-button telephone sets", ITU-T Recommendation Q.23, November 1988.
[10] 国际电信联盟，“按钮电话机的技术特征”，ITU-T建议Q.23，1988年11月。
[11] International Telecommunication Union, "Multifrequency push-button signal reception", ITU-T Recommendation Q.24, November 1988.
[11] 国际电信联盟，“多频按钮信号接收”，ITU-T建议Q.241988年11月。
[12] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[12] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[13] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[14] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[14] Kreuter，R.，“64 kbit/s透明呼叫的RTP有效负载格式”，RFC 4040，2005年4月。
[15] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[15] Hellstrom，G.和P.Jones，“文本对话的RTP有效载荷”，RFC 4103，2005年6月。
[16] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006.
[16] Schulzrinne，H.和T.Taylor，“调制解调器、传真和文本电话信号事件的定义”，RFC 47342006年12月。
[17] Schulzrinne, H. and T. Taylor, "Definition of Events For Channel-Oriented Telephony Signalling", Work In Progress , November 2005.
[17] Schulzrinne，H.和T.Taylor，“面向信道的电话信令事件的定义”，正在进行的工作，2005年11月。
[18] International Telecommunication Union, "Technical characteristics of tones for the telephone service", ITU-T Recommendation E.180/Q.35, March 1998.
[18] 国际电信联盟，“电话业务音调的技术特征”，ITU-T建议E.180/Q.35，1998年3月。
[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, "Speech coders : Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996.
[20] 国际电信联盟，“语音编码器：以5.3和6.3 kbit/s传输的多媒体通信用双速率语音编码器”，ITU-T建议G.723.1，1996年3月。
[21] International Telecommunication Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[21] 国际电信联盟，“使用共轭结构代数码激励线性预测（CS-ACELP）对8kbit/s语音进行编码”，ITU-T建议G.729，1996年3月。
[22] International Telecommunication Union, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998.
[22] 国际电信联盟，“基本呼叫控制的ISDN用户网络接口第3层规范”，ITU-T建议Q.931，1998年5月。
[23] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
[23] 国际电信联盟，“通过IP网络进行实时第3组传真通信的程序”，ITU-T建议T.38，2003年7月。
[24] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000.
[24] 国际电信联盟，“通过公共交换电话网开始数据传输会话的程序”，ITU-T建议V.8，2000年11月。
[25] 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.
[25] 国际电信联盟，“IP网络上的调制解调器：V系列DCE端到端连接程序”，ITU-T建议V.150.1，2003年1月。
[26] International Telecommunication Union, "Procedures for supporting Voice-Band Data over IP Networks", ITU-T Recommendation V.152, January 2005.
[26] 国际电信联盟，“支持IP网络上语音带数据的程序”，ITU-T建议V.152，2005年1月。
[27] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000.
[27] 国际电信联盟，“在文本电话模式下运行的{DCE的操作和互通要求”，ITU-T建议V.18，2000年11月。
See also Recommendation V.18 Amendment 1, Nov. 2002. [28] VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness", 2005, <http://www.voiptroubleshooter.com/indepth/burstloss.html>.
另见建议V.18修正案1，2002年11月。[28]VOIP疑难解答有限责任公司，“深入：数据包丢失突发性”，2005年<http://www.voiptroubleshooter.com/indepth/burstloss.html>.
The memo has been significantly restructured, incorporating a large number of clarifications to the specification. With the exception of those items noted below, the changes to the memo are intended to be backwards-compatible clarifications. However, due to inconsistencies and unclear definitions in RFC 2833 [12] it is likely that some implementations interpreted that memo in ways that differ from this version.
备忘录经过了重大调整，对规范进行了大量澄清。除以下所述项目外，备忘录的变更旨在向后兼容澄清。然而，由于RFC 2833[12]中的不一致和定义不明确，一些实现可能以不同于此版本的方式解释该备忘录。
RFC 2833 required that all implementations be capable of receiving the DTMF events (event codes 0-15). Section 2.5.1.1 of the present document requires that a sender transmit only the events that the receiver is capable of receiving. In the absence of a knowledge of receiver capabilities, the sender SHOULD assume support of the DTMF events but of no other events. The sender SHOULD indicate what events it can send. Section 2.5.2.1 requires that a receiver signalling its capabilities using SDP MUST indicate which events it can receive.
RFC 2833要求所有实现都能够接收DTMF事件（事件代码0-15）。本文件第2.5.1.1节要求发送方仅发送接收方能够接收的事件。在不了解接收器功能的情况下，发送方应假定支持DTMF事件，但不支持其他事件。发送方应指明它可以发送哪些事件。第2.5.2.1节要求使用SDP发送其能力信号的接收器必须指示其可以接收哪些事件。
Non-zero values in the volume field of the payload were applicable only to DTMF tones in RFC 2833, and for other events the receiver was required to ignore them. The present memo requires that the definition of each event indicate whether the volume field is applicable to that event. The last paragraph of Section 2.5.2.2 indicates what a receiver may do if it receives volumes with zero values for events to which the volume field is applicable. Along with the RFC 2833 receiver rule, this ensures backward compatibility in both directions of transmission.
有效载荷音量字段中的非零值仅适用于RFC 2833中的DTMF音调，对于其他事件，要求接收器忽略它们。本备忘录要求每个事件的定义表明音量字段是否适用于该事件。第2.5.2.2节的最后一段说明了如果接收到的卷中的卷字段适用的事件的值为零时，接收器可以做什么。与RFC 2833接收器规则一起，这确保了在两个传输方向上的向后兼容性。
Section 2.5.1.3 and Section 2.5.2.3 introduce a new procedure for reporting and playing out events whose duration exceeds the capacity of the payload duration field. This procedure may cause momentary confusion at an old (RFC 2833) receiver, because the timestamp is updated without setting the E bit of the preceding event report and without setting the M bit of the new one.
第2.5.1.3节和第2.5.2.3节介绍了报告和播放持续时间超过有效负载持续时间字段容量的事件的新程序。此过程可能会在旧（RFC 2833）接收器上造成暂时混淆，因为时间戳在更新时未设置前一事件报告的E位，也未设置新事件报告的M位。
Section 2.5.1.5 and Section 2.5.2.4 introduce a new procedure whereby a sequence of short-duration events may be packed into a single event report. If an old (RFC 2833) receiver receives such a report, it may discard the packet as invalid, since the packet holds more content than the receiver was expecting. In any event, the additional events in the packet will be lost.
第2.5.1.5节和第2.5.2.4节引入了一个新的程序，在此程序中，短时间事件序列可以打包到单个事件报告中。如果旧（RFC 2833）接收器接收到这样的报告，它可能会丢弃无效的数据包，因为数据包包含的内容比接收器预期的多。在任何情况下，数据包中的附加事件都将丢失。
Section 2.3.5 introduces the possibility of "state" events and defines procedures for setting the duration field for reports of such events. Section 2.5.1.2 defines special exemptions from the setting of the E bit for state events. Three more sections mention procedures related to these events.
第2.3.5节介绍了“状态”事件的可能性，并定义了设置此类事件报告持续时间字段的程序。第2.5.1.2节定义了状态事件E位设置的特殊豁免。还有三节提到了与这些事件相关的程序。
The Security Considerations section is updated to mention the requirement for protection of integrity. More importantly, it makes implementation of SRTP [7] mandatory for compliant implementations, without specifying a mandatory-to-implement method of key distribution.
安全注意事项部分已更新，以提及完整性保护的要求。更重要的是，它使得SRTP[7]的实现对于兼容的实现是强制性的，而没有指定实现密钥分配方法的强制性。
Finally, this document establishes an IANA registry for event codes and establishes criteria for their documentation. This document provides an initial population for the new registry, consisting solely of the sixteen DTMF events. Two companion documents [16] and [17] describe events related to modems, fax, and text telephony and to channel-associated telephony signalling, respectively. Some changes were made to the latter because of errors and redundancies in the RFC 2833 assignments. The remaining events defined in RFC 2833 are deprecated because they do not appear to have been implemented, but their codes have been conditionally reserved in case any of them is needed in the future. Table 8 indicates the disposition of the event codes in detail. Event codes not mentioned in this table were not allocated by RFC 2833 and continue to be unused.
最后，本文件为事件代码建立了IANA注册中心，并为其文档建立了标准。本文档提供了新注册表的初始填充，仅由16个DTMF事件组成。两份配套文件[16]和[17]分别描述了与调制解调器、传真和文本电话以及与信道相关的电话信令相关的事件。由于RFC 2833作业中的错误和冗余，对后者进行了一些更改。RFC 2833中定义的其余事件已被弃用，因为它们似乎尚未实现，但它们的代码已被有条件地保留，以备将来需要。表8详细说明了事件代码的配置。本表中未提及的事件代码未由RFC 2833分配，并继续未使用。
+-------------+---------------------------------------+-------------+
| Event Codes | RFC 2833 Description | Disposition |
+-------------+---------------------------------------+-------------+
| 0-15 | DTMF digits | RFC 4733 |
| 16 | Line flash (deprecated) | Reserved |
| 23-31 | Unused | [16] |
| 32-40 | Data and fax | [16] |
| 41-48 | Data and fax (V.8bis, deprecated) | Reserved |
| 52-63 | Unused | [16] |
| 64-89 | E.182 line events (deprecated) | Reserved |
| 96-112 | Country-specific line events | Reserved |
| | (deprecated) | |
| 121-127 | Unused | [17] |
| 128-137 | Trunks: MF 0-9 | [17] |
| 138-143 | Trunks: other MF (deprecated) | Reserved |
| 144-159 | Trunks: ABCD signalling | [17] |
| 160-168 | Trunks: various (deprecated) | Reserved |
| 170-173 | Trunks: various (deprecated) | Reserved |
| 174-205 | Unused | [17] |
+-------------+---------------------------------------+-------------+
+-------------+---------------------------------------+-------------+
| Event Codes | RFC 2833 Description | Disposition |
+-------------+---------------------------------------+-------------+
| 0-15 | DTMF digits | RFC 4733 |
| 16 | Line flash (deprecated) | Reserved |
| 23-31 | Unused | [16] |
| 32-40 | Data and fax | [16] |
| 41-48 | Data and fax (V.8bis, deprecated) | Reserved |
| 52-63 | Unused | [16] |
| 64-89 | E.182 line events (deprecated) | Reserved |
| 96-112 | Country-specific line events | Reserved |
| | (deprecated) | |
| 121-127 | Unused | [17] |
| 128-137 | Trunks: MF 0-9 | [17] |
| 138-143 | Trunks: other MF (deprecated) | Reserved |
| 144-159 | Trunks: ABCD signalling | [17] |
| 160-168 | Trunks: various (deprecated) | Reserved |
| 170-173 | Trunks: various (deprecated) | Reserved |
| 174-205 | Unused | [17] |
+-------------+---------------------------------------+-------------+
Table 8: Disposition of RFC 2833-defined Event Codes
表8:RFC 2833定义事件代码的处置
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编辑功能的资金目前由互联网协会提供。