Network Working Group H. Schulzrinne
Request for Comments: 5244 Columbia U.
Updates: 4733 T. Taylor
Category: Standards Track Nortel
June 2008
Network Working Group H. Schulzrinne
Request for Comments: 5244 Columbia U.
Updates: 4733 T. Taylor
Category: Standards Track Nortel
June 2008
Definition of Events for Channel-Oriented Telephony Signalling
面向信道的电话信令的事件定义
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）。本备忘录的分发不受限制。
Abstract
摘要
This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833.
本备忘录更新RFC 4733，以添加电话事件RTP有效载荷中承载时用于信道相关信令的电话信号的事件代码。它取代并增加了RFC 2833第3.14节中的事件代码的原始分配。如RFC 4733附录A所述，一些RFC 2833事件已被弃用，因为其规范不明确、错误或冗余。事实上，RFC 2833第3.14节的变化程度使得本文件的实现仅在完全ABCD位信令的情况下才与RFC 2833实现完全向后兼容。与RFC 2833相比，本文件扩展并改进了信号系统的覆盖范围。
Table of Contents
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Terminology ................................................3
2. Event Definitions ...............................................4
2.1. Signalling System No. 5 ....................................6
2.1.1. Signalling System No. 5 Line Signals ................6
2.1.2. Signalling System No. 5 Register Signals ............7
2.2. Signalling System R1 and North American MF .................8
2.2.1. Signalling System R1 Line Signals ...................8
2.2.2. Signalling System R1 Register Signals ...............8
2.3. Signalling System R2 ......................................10
2.3.1. Signalling System R2 Line Signals ..................10
2.3.2. Signalling System R2 Register Signals ..............10
2.4. ABCD Transitional Signalling for Digital Trunks ...........12
2.5. Continuity Tones ..........................................14
2.6. Trunk Unavailable Event ...................................14
2.7. Metering Pulse Event ......................................15
3. Congestion Considerations ......................................15
4. Security Considerations ........................................16
5. IANA Considerations ............................................17
6. Acknowledgements ...............................................20
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
Table of Contents
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Terminology ................................................3
2. Event Definitions ...............................................4
2.1. Signalling System No. 5 ....................................6
2.1.1. Signalling System No. 5 Line Signals ................6
2.1.2. Signalling System No. 5 Register Signals ............7
2.2. Signalling System R1 and North American MF .................8
2.2.1. Signalling System R1 Line Signals ...................8
2.2.2. Signalling System R1 Register Signals ...............8
2.3. Signalling System R2 ......................................10
2.3.1. Signalling System R2 Line Signals ..................10
2.3.2. Signalling System R2 Register Signals ..............10
2.4. ABCD Transitional Signalling for Digital Trunks ...........12
2.5. Continuity Tones ..........................................14
2.6. Trunk Unavailable Event ...................................14
2.7. Metering Pulse Event ......................................15
3. Congestion Considerations ......................................15
4. Security Considerations ........................................16
5. IANA Considerations ............................................17
6. Acknowledgements ...............................................20
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
This document extends the set of telephony events defined within the framework of RFC 4733 [4] to include signalling events that can appear on a circuit in the telephone network. Most of these events correspond to signals within one of several channel-associated signalling systems still in use in the PSTN.
本文件扩展了RFC 4733[4]框架内定义的电话事件集，以包括可能出现在电话网络电路上的信令事件。这些事件中的大多数对应于PSTN中仍在使用的多个信道相关信令系统之一内的信号。
Trunks (or circuits) in the PSTN are the media paths between telephone switches. A succession of protocols have been developed using tones and electrical conditions on individual trunks to set up telephone calls using them. The events defined in this document support an application where such PSTN signalling is carried between two gateways without being signalled in the IP network: the "RTP trunk" application.
PSTN中的中继线（或电路）是电话交换机之间的媒体路径。已经开发了一系列协议，使用各个中继上的音调和电气条件来建立使用它们的电话呼叫。本文档中定义的事件支持这样一种应用，即在两个网关之间传输PSTN信令，而不在IP网络中发送信令：“RTP中继”应用。
In the "RTP trunk" application, RTP is used to replace a normal circuit-switched trunk between two nodes. This is particularly of interest in a telephone network that is still mostly circuit-switched. In this case, each end of the RTP trunk encodes
在“RTP中继”应用程序中，RTP用于替换两个节点之间的正常电路交换中继。这在仍然主要是电路交换的电话网络中尤其令人感兴趣。在这种情况下，RTP中继的每一端都进行编码
audio channels into the appropriate encoding, such as G.723.1 [13] or G.729 [14]. However, this encoding process destroys in-band signalling information that is carried using the least-significant bit ("robbed bit signalling") and may also interfere with in-band signalling tones, such as the MF (multi-frequency) digit tones.
将音频通道转换为适当的编码，如G.723.1[13]或G.729[14]。然而，该编码过程破坏使用最低有效位（“抢位信令”）携带的带内信令信息，并且还可能干扰带内信令音调，例如MF（多频）数字音调。
In a typical application, the gateways may exchange roles from one call to the next: they must be capable of either sending or receiving each implemented signal in Table 1.
在典型应用中，网关可以从一个调用到下一个调用交换角色：它们必须能够发送或接收表1中的每个实现的信号。
This document defines events related to four different signalling systems. Three of these are based on the exchange of multi-frequency tones. The fourth operates on digital trunks only, and makes use of low-order bits stolen from the encoded media. In addition, this document defines tone events for supporting tasks such as continuity testing of the media path.
本文件定义了与四种不同信号系统相关的事件。其中三种是基于多频音调的交换。第四种仅在数字中继上运行，并利用从编码媒体窃取的低阶位。此外，本文档还定义了用于支持任务（如介质路径的连续性测试）的音调事件。
Implementors are warned that the descriptions of signalling systems given below are incomplete. They are provided to give context to the related event definitions, but omit many details important to implementation.
警告实施者，下面给出的信令系统描述不完整。提供它们是为了提供相关事件定义的上下文，但省略了许多对实现非常重要的细节。
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] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释，并指出符合性实施的要求级别。
In addition to the abbreviations defined below for specific events, this document uses the following abbreviations:
除了以下针对特定事件定义的缩写外，本文件还使用以下缩写：
KP Key Pulse
关键脉冲
MF Multi-frequency
中频多频
PSTN Public Switched (circuit) Telephone Network
公用交换（电路）电话网
RTP Real-time Transport Protocol [2]
RTP实时传输协议[2]
ST Start
ST Start
Table 1 lists all of the events defined in this document. As indicated in Table 8 (Appendix A) of RFC 4733 [4], use of some of the RFC 2833 [11] event codes has been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833.
表1列出了本文档中定义的所有事件。如RFC 4733[4]表8（附录A）所示，一些RFC 2833[11]事件代码的使用已被弃用，因为它们的规范不明确、错误或冗余。事实上，RFC 2833第3.14节的变化程度使得本文件的实现仅在完全ABCD位信令的情况下才与RFC 2833实现完全向后兼容。与RFC 2833相比，本文件扩展并改进了信号系统的覆盖范围。
Note that the IANA registry for telephony event codes was set up by RFC 4733, not by RFC 2833. Thus, event code assignments originally made in RFC 2833 appear in the registry only if reaffirmed in RFC 4733 or an update to RFC 4733, such as the present document.
请注意，电话事件代码的IANA注册表是由RFC 4733设置的，而不是由RFC 2833设置的。因此，最初在RFC 2833中进行的事件代码分配只有在RFC 4733或RFC 4733更新（如本文件）中重申时才会出现在注册表中。
+---------------------+------------+-------------+--------+---------+
| Event | Frequency | Event Code | Event | Volume? |
| | (Hz) | | Type | |
+---------------------+------------+-------------+--------+---------+
| MF 0...9 | (Table 2) | 128...137 | tone | yes |
| | | | | |
| MF Code 11 (SS No. | 700+1700 | 123 | tone | yes |
| 5) or KP3P/ST3P | | | | |
| (R1) | | | | |
| | | | | |
| MF KP (SS No. 5) or | 1100+1700 | 124 | tone | yes |
| KP1 (R1) | | | | |
| | | | | |
| MF KP2 (SS No. 5) | 1300+1700 | 125 | tone | yes |
| or KP2P/ST2P (R1) | | | | |
| | | | | |
| MF ST (SS No. 5 and | 1500+1700 | 126 | tone | yes |
| R1) | | | | |
| | | | | |
| MF Code 12 (SS No. | 900+1700 | 127 | tone | yes |
| 5) or KP'/STP (R1) | | | | |
| | | | | |
| ABCD signalling | N/A | 144...159 | state | no |
| | | | | |
| AB signalling (C, D | N/A | 208...211 | state | no |
| unused) | | | | |
| | | | | |
| A bit signalling | N/A | 206...207 | state | no |
| (B, C, D unused) | | | | |
| | | | | |
| Continuity | 2000 | 121 | tone | yes |
| check-tone | | | | |
| | | | | |
| Continuity | 1780 | 122 | tone | yes |
| verify-tone | | | | |
| | | | | |
| Metering pulse | N/A | 174 | other | no |
| | | | | |
| Trunk unavailable | N/A | 175 | other | no |
| | | | | |
| MFC Forward 1...15 | (Table 4) | 176...190 | tone | yes |
| | | | | |
| MFC Backward 1...15 | (Table 5) | 191...205 | tone | yes |
+---------------------+------------+-------------+--------+---------+
+---------------------+------------+-------------+--------+---------+
| Event | Frequency | Event Code | Event | Volume? |
| | (Hz) | | Type | |
+---------------------+------------+-------------+--------+---------+
| MF 0...9 | (Table 2) | 128...137 | tone | yes |
| | | | | |
| MF Code 11 (SS No. | 700+1700 | 123 | tone | yes |
| 5) or KP3P/ST3P | | | | |
| (R1) | | | | |
| | | | | |
| MF KP (SS No. 5) or | 1100+1700 | 124 | tone | yes |
| KP1 (R1) | | | | |
| | | | | |
| MF KP2 (SS No. 5) | 1300+1700 | 125 | tone | yes |
| or KP2P/ST2P (R1) | | | | |
| | | | | |
| MF ST (SS No. 5 and | 1500+1700 | 126 | tone | yes |
| R1) | | | | |
| | | | | |
| MF Code 12 (SS No. | 900+1700 | 127 | tone | yes |
| 5) or KP'/STP (R1) | | | | |
| | | | | |
| ABCD signalling | N/A | 144...159 | state | no |
| | | | | |
| AB signalling (C, D | N/A | 208...211 | state | no |
| unused) | | | | |
| | | | | |
| A bit signalling | N/A | 206...207 | state | no |
| (B, C, D unused) | | | | |
| | | | | |
| Continuity | 2000 | 121 | tone | yes |
| check-tone | | | | |
| | | | | |
| Continuity | 1780 | 122 | tone | yes |
| verify-tone | | | | |
| | | | | |
| Metering pulse | N/A | 174 | other | no |
| | | | | |
| Trunk unavailable | N/A | 175 | other | no |
| | | | | |
| MFC Forward 1...15 | (Table 4) | 176...190 | tone | yes |
| | | | | |
| MFC Backward 1...15 | (Table 5) | 191...205 | tone | yes |
+---------------------+------------+-------------+--------+---------+
Table 1: Trunk Signalling Events
表1：中继信令事件
Signalling System No. 5 (SS No. 5) is defined in ITU-T Recommendations Q.140 through Q.180 [5]. It has two systems of signals: "line" signalling to acquire and release the trunk, and "register" signalling to pass digits forward from one switch to the next.
ITU-T建议Q.140至Q.180[5]中定义了5号信令系统（SS 5）。它有两个信号系统：“线路”信号用于获取和释放中继，而“寄存器”信号用于将数字从一个交换机转发到下一个交换机。
No. 5 line signalling uses tones at two frequencies: 2400 and 2600 Hz. The tones are used singly for most signals, but together for the Clear-forward and Release-guard. (This reduces the chance of an accidental call release due to carried media content duplicating one of the frequencies.) The specific signal indicated by a tone depends on the stage of call set-up at which it is applied.
5号线信令使用两种频率的音调：2400和2600 Hz。这些音调单独用于大多数信号，但同时用于清除前进和释放防护。（这降低了由于携带的媒体内容复制了其中一个频率而导致意外释放呼叫的可能性。）音调指示的特定信号取决于应用该信号的呼叫设置阶段。
No events are defined in support of No. 5 line signalling. However, implementations MAY use the AB bit events described in Section 2.4 and shown in Table 1 to propagate SS No. 5 line signals. If they do so, they MUST use the following mappings. These mappings are based on an underlying mapping equating A=0 to presence of 2400 Hz signal and B=0 to presence of 2600 Hz signal in the indicated direction.
没有定义支持5号线信号的事件。然而，实现可以使用第2.4节中描述的和表1中所示的AB位事件来传播SS 5号线信号。如果这样做，则必须使用以下映射。这些映射基于基本映射，即A=0表示指示方向上存在2400 Hz信号，B=0表示指示方向上存在2600 Hz信号。
o both 2400 and 2600 Hz present: event code 208;
o 出现2400和2600 Hz：事件代码208；
o 2400 Hz present: event code 210;
o 存在2400 Hz：事件代码210；
o 2600 Hz present: event code 209;
o 存在2600 Hz：事件代码209；
o neither signal present: event code 211.
o 两个信号均不存在：事件代码211。
The initial event report for each signal SHOULD be generated as soon as the signal is recognized, and in any case no later than the time of recognition as indicated in ITU-T Recommendation Q.141, Table 1 (i.e., 40 ms for "seizing" and "proceed-to-send", 125 ms for all other signals). The packetization interval following the initial report SHOULD be chosen with considerations of reliable transmission given first priority. Note that the receiver must supply its own volume values for converting these events back to tones. Moreover, the receiver MAY extend the playout of "seizing" until it has received the first report of a KP event (see below), so that it has better control of the interval between ending of the seizing signal and start of KP playout.
每个信号的初始事件报告应在识别出信号后立即生成，并且在任何情况下都不得晚于ITU-T建议Q.141表1中所示的识别时间（即，“捕捉”和“继续发送”为40毫秒，所有其他信号为125毫秒）。在选择初始报告之后的打包间隔时，应首先考虑可靠传输。请注意，接收器必须提供自己的音量值，以便将这些事件转换回音调。此外，接收器可延长“捕捉”的播放时间，直到其已接收到KP事件的第一次报告（见下文），以便其更好地控制捕捉信号结束与KP播放开始之间的间隔。
The KP has to be sent beginning 80 +/- 20 ms after the SS No. 5 "seizing" signal has stopped.
必须在SS 5号“卡住”信号停止后80+/-20 ms开始发送KP。
No. 5 register signalling uses pairs of tones to convey digits and signals framing them. The tone combinations and corresponding signals are shown in the Table 2. All signals except KP1 and KP2 are sent for a duration of 55 ms. KP1 and KP2 are sent for a duration of 100 ms. Inter-signal pauses are always 55 ms.
5号寄存器信令使用成对的音调来传送数字和信号，并将其帧化。音调组合和相应信号如表2所示。除KP1和KP2之外的所有信号发送的持续时间为55毫秒。KP1和KP2发送的持续时间为100毫秒。信号间暂停始终为55毫秒。
Upper Frequency (Hz)
高频（Hz）
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 900 | 1100 | 1300 | 1500 | 1700 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | Code 11 |
| | | | | | |
| 900 | | Digit 3 | Digit 5 | Digit 8 | Code 12 |
| | | | | | |
| 1100 | | | Digit 6 | Digit 9 | KP1 |
| | | | | | |
| 1300 | | | | Digit 0 | KP2 |
| | | | | | |
| 1500 | | | | | ST |
+-----------------+---------+---------+---------+---------+---------+
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 900 | 1100 | 1300 | 1500 | 1700 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | Code 11 |
| | | | | | |
| 900 | | Digit 3 | Digit 5 | Digit 8 | Code 12 |
| | | | | | |
| 1100 | | | Digit 6 | Digit 9 | KP1 |
| | | | | | |
| 1300 | | | | Digit 0 | KP2 |
| | | | | | |
| 1500 | | | | | ST |
+-----------------+---------+---------+---------+---------+---------+
Table 2: SS No. 5 Register Signals
表2:SS 5号寄存器信号
The KP signals are used to indicate the start of digit signalling. KP1 indicates a call expected to terminate in a national network served by the switch to which the signalling is being sent. KP2 indicates a call that is expected to transit through the switch to which the signalling is being sent, to another international exchange. The end of digit signalling is indicated by the ST signal. Code 11 or Code 12 following a country code (and possibly another digit) indicates a call to be directed to an operator position in the destination country. A Code 12 may be followed by other digits indicating a particular operator to whom the call is to be directed.
KP信号用于指示数字信号的开始。KP1表示一个呼叫预期将在由发送信令的交换机所服务的国家网络中终止。KP2表示一个呼叫，该呼叫预计将通过发送信令的交换机转接到另一个国际交换机。数字结束信号由ST信号指示。国家代码（可能还有另一个数字）后面的代码11或代码12表示呼叫要定向到目的地国家的操作员位置。代码12后面可能跟有其他数字，指示呼叫将被定向到的特定操作员。
Implementations using the telephone-events payload to carry SS No. 5 register signalling MUST use the following events from Table 1 to convey the register signals shown in Table 2:
使用电话事件有效载荷来承载5号SS寄存器信令的实现必须使用表1中的以下事件来传递表2中所示的寄存器信号：
o event code 128 to convey Digit 0;
o 事件代码128表示数字0；
o event codes 129-137 to convey Digits 1 through 9, respectively;
o 事件代码129-137分别表示数字1至9；
o event code 123 to convey Code 11;
o 事件代码123传达代码11；
o event code 124 to convey KP1;
o 传达KP1的事件代码124；
o event code 125 to convey KP2;
o 传递KP2的事件代码125；
o event code 126 to convey ST;
o 事件代码126，用于传递ST；
o event code 127 to convey Code 12.
o 事件代码127传达代码12。
The sending implementation SHOULD send an initial event report for the KP signals as soon as they are recognized, and it MUST send an event report for all of these signals as soon as they have completed.
一旦KP信号被识别，发送实现应立即发送KP信号的初始事件报告，并且必须在所有这些信号完成后立即发送所有这些信号的事件报告。
Signalling System R1 is mainly used in North America, as is the more common variant designated simply as "MF". R1 is defined in ITU-T Recommendations Q.310-Q.332 [6], while MF is defined in [9].
信号系统R1主要用于北美，更常见的变体也被简单地命名为“MF”。R1在ITU-T建议Q.310-Q.332[6]中定义，而MF在[9]中定义。
Like SS No. 5, R1/MF has both line and register signals. The line signals (not counting Busy and Reorder) are implemented on analog trunks through the application of a 2600 Hz tone, and on digital trunks by using ABCD signalling. Interpretation of the line signals is state-dependent (as with SS No. 5).
与SS No.5一样，R1/MF具有行信号和寄存器信号。线路信号（不计算忙和重排序）通过应用2600 Hz音调在模拟中继线上实现，并通过使用ABCD信令在数字中继线上实现。线路信号的解释取决于状态（如SS 5）。
In accordance with Table 1/Q.311, implementations MAY use the A bit events described in Section 2.4 and shown in Table 1 to propagate R1 line signals. If they do so, they MUST use the following mappings. These mappings are based on an underlying mapping equating A=0 to the presence of a 2600 Hz signal in the indicated direction and A=1 to the absence of that signal.
根据表1/Q.311，实施可使用第2.4节所述和表1所示的A位事件来传播R1线路信号。如果这样做，则必须使用以下映射。这些映射基于基本映射，即A=0表示指示方向上存在2600 Hz信号，A=1表示不存在该信号。
o 2600 Hz present: event code 206;
o 存在2600 Hz：事件代码206；
o no signal present: event code 207.
o 不存在信号：事件代码207。
R1 has a signal capacity of 15 codes for forward inter-register signals but no backward inter-register signals. Each code or digit is transmitted by a tone pair from a set of 6 frequencies. The R1 register signals consist of KP, ST, and the digits "0" through "9". The frequencies allotted to the signals are shown in Table 3. Note
R1的信号容量为前向寄存器间信号的15个代码，但没有后向寄存器间信号。每个代码或数字由一组6个频率的音调对传输。R1寄存器信号由KP、ST和数字“0”至“9”组成。分配给信号的频率如表3所示。笔记
that these frequencies are the same as those allotted to the similarly named SS No. 5 register signals, except that KP uses the frequency combination corresponding to KP1 in SS No. 5. Table 3 also shows additional signals used in North American practice: KP', KP2P, KP3P, STP or ST', ST2P, and ST3P [9].
这些频率与分配给类似命名的SS 5号寄存器信号的频率相同，但KP使用与SS 5中KP1对应的频率组合。表3还显示了北美实践中使用的其他信号：KP'，KP2P，KP3P，STP或ST'，ST2P和ST3P[9]。
Upper Frequency (Hz)
高频（Hz）
+------------+---------+---------+---------+---------+--------------+
| Lower | 900 | 1100 | 1300 | 1500 | 1700 |
| Frequency | | | | | |
| (Hz) | | | | | |
+------------+---------+---------+---------+---------+--------------+
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | KP3P or ST3P |
| | | | | | |
| 900 | | Digit 3 | Digit 5 | Digit 8 | KP' or STP |
| | | | | | |
| 1100 | | | Digit 6 | Digit 9 | KP |
| | | | | | |
| 1300 | | | | Digit 0 | KP2P or ST2P |
| | | | | | |
| 1500 | | | | | ST |
+------------+---------+---------+---------+---------+--------------+
+------------+---------+---------+---------+---------+--------------+
| Lower | 900 | 1100 | 1300 | 1500 | 1700 |
| Frequency | | | | | |
| (Hz) | | | | | |
+------------+---------+---------+---------+---------+--------------+
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | KP3P or ST3P |
| | | | | | |
| 900 | | Digit 3 | Digit 5 | Digit 8 | KP' or STP |
| | | | | | |
| 1100 | | | Digit 6 | Digit 9 | KP |
| | | | | | |
| 1300 | | | | Digit 0 | KP2P or ST2P |
| | | | | | |
| 1500 | | | | | ST |
+------------+---------+---------+---------+---------+--------------+
Table 3: R1/MF Register Signals
表3:R1/MF寄存器信号
Implementations using the telephone-events payload to carry North American R1 register signalling MUST use the following events from Table 1 to convey the register signals shown in Table 3:
使用电话事件有效载荷来承载北美R1寄存器信令的实现必须使用表1中的以下事件来传递表3中所示的寄存器信号：
o event code 128 to convey Digit 0;
o 事件代码128表示数字0；
o event codes 129-137 to convey Digits 1 through 9, respectively;
o 事件代码129-137分别表示数字1至9；
o event code 123 to convey KP3P or ST3P;
o 传达KP3P或ST3P的事件代码123；
o event code 124 to convey KP;
o 传达KP的事件代码124；
o event code 125 to convey KP2P or ST2P;
o 传递KP2P或ST2P的事件代码125；
o event code 126 to convey ST;
o 事件代码126，用于传递ST；
o event code 127 to convey KP' or STP.
o 事件代码127，用于传达KP'或STP。
As with the original telephony signals, the receiver interprets codes 123, 125, and 127 as KPx or STx signals based on their position in the signalling sequence.
与原始电话信号一样，接收机基于代码123、125和127在信令序列中的位置将其解释为KPx或STx信号。
Unlike SS No. 5, R1 allows a large tolerance for the time of onset of register signalling following the recognition of start-dialling line signal. This means that sending implementations MAY wait to send a KP event report until the KP has completed.
与SS No.5不同，R1允许在识别开始拨号线路信号后，寄存器信号开始的时间具有较大的容差。这意味着发送实现可能会等待发送KP事件报告，直到KP完成。
The International Signalling System R2 is described in ITU-T Recommendations Q.400-Q.490 [7], but there are many national variants. R2 line signals are continuous, out-of-band, link by link, and channel associated. R2 (inter)register signals are multi-frequency, compelled, in-band, end-to-end, and also channel associated.
国际信令系统R2在ITU-T建议Q.400-Q.490[7]中有描述，但有许多国家变体。R2线路信号是连续的、带外的、逐链路的和相关信道的。R2（内部）寄存器信号是多频、强制、带内、端到端以及信道相关的信号。
R2 line signals may be analog, one-bit digital using the A bit in the 16th channel, or digital using both A and B bits. Implementations MAY use the A bit or AB bit events described in Section 2.4 and shown in Table 1 to propagate these signals. If they do so, they MUST use the following mappings.
R2线路信号可以是模拟信号、使用第16通道中的A位的一位数字信号，或同时使用A位和B位的数字信号。实现可以使用第2.4节中描述的和表1中所示的A位或AB位事件来传播这些信号。如果这样做，则必须使用以下映射。
1. For the analog R2 line signals shown in Table 1 of ITU-T Recommendation Q.411, implementations MUST map as follows. This mapping is based on an underlying mapping of A bit = 0 when tone is present.
1. 对于ITU-T建议Q.411表1中所示的模拟R2线路信号，实施必须映射如下。此映射基于存在音调时位=0的基础映射。
* event code 206 (Table 1) is used to indicate the Q.411 "tone-on" condition;
* 事件代码206（表1）用于指示Q.411“音调开启”条件；
* event code 207 (Table 1), is used to indicate the Q.411 "tone-off" condition.
* 事件代码207（表1）用于指示Q.411“音调关闭”状态。
2. The digital R2 line signals, as described by ITU-T Recommendation Q.421, are carried in two bits, A and B. The mapping between A and B bit values and event codes SHALL be the same in both directions and SHALL follow the principles for A and B bit mapping specified in Section 2.4.
2. 如ITU-T建议Q.421所述，数字R2线路信号以两位A和B进行传输。A和B位值与事件代码之间的映射在两个方向上应相同，并应遵循第2.4节中规定的A和B位映射原则。
In R2 signalling, the signalling sequence is initiated from the outgoing exchange by sending a line "seizing" signal. After the line "seizing" signal (and "seizing acknowledgment" signal in R2D), the signalling sequence continues using MF register signals. ITU-T Recommendation Q.441 classifies the forward MF register signals
在R2信令中，通过发送线路“占用”信号，从输出交换机启动信令序列。在线路“捕捉”信号（以及R2D中的“捕捉确认”信号）之后，信令序列继续使用MF寄存器信号。ITU-T建议Q.441对前向MF寄存器信号进行分类
(upper frequencies) into Groups I and II, the backward MF register signals (lower frequencies) into Groups A and B. These groups are significant with respect both to what sort of information they convey and where they can occur in the signalling sequence.
（较高频率）分为I组和II组，反向MF寄存器信号（较低频率）分为A组和B组。这些组对于它们传递的信息类型以及它们在信号序列中出现的位置都很重要。
The tones used in R2 register signalling are combinations of two out of six frequencies. National versions may be reduced to 10 signals (two out of five frequencies) or 6 signals (two out of four frequencies).
R2寄存器信令中使用的音调是六个频率中两个频率的组合。国家版本可减少至10个信号（五个频率中的两个）或6个信号（四个频率中的两个）。
R2 register signalling is a compelled tone signalling protocol, meaning that one tone is played until an "acknowledgment or directive for the next tone" is received that indicates that the original tone should cease. A R2 forward register signal is acknowledged by a backward signal. A backward signal is acknowledged by the end of the forward signal. In exceptional circumstances specified in ITU-T Rec. Q.442, the downstream entity may send backward signals autonomously rather than in response to specific forward signals.
R2寄存器信令是一种强制音调信令协议，意味着在接收到指示原始音调应停止的“下一音调确认或指令”之前播放一个音调。R2正向寄存器信号由反向信号确认。前向信号的末端确认后向信号。在ITU-T Rec.Q.442中规定的特殊情况下，下游实体可自主发送后向信号，而不是响应特定的前向信号。
In R2 signalling, the signalling sequence is initiated from the outgoing exchange by sending a forward Group I signal. The first forward signal is typically the first digit of the called number. The incoming exchange typically replies with a backward Group A-1 indicating to the outgoing exchange to send the next digit of the called number.
在R2信令中，通过发送前向I组信号，从出站交换机启动信令序列。第一转发信号通常是被叫号码的第一位。入局交换机通常使用向后组a-1进行应答，该组指示出局交换机发送被叫号码的下一位数字。
The tones have meaning; however, the meaning varies depending on where the tone occurs in the signalling. The meaning may also depend on the country. Thus, to avoid an unmanageable number of events, this document simply provides means to indicate the 15 forward and 15 backward MF R2 tones (i.e., using event codes 176-190 and 191-205, respectively, as shown in Table 1). The frequency pairs for these tones are shown in Table 4 and Table 5.
音调有意义；然而，其含义取决于信号中音调出现的位置。含义也可能取决于国家。因此，为了避免无法管理的事件数量，本文件仅提供了指示15个向前和15个向后MF R2音调的方法（即，分别使用事件代码176-190和191-205，如表1所示）。这些音调的频率对如表4和表5所示。
Note that a naive strategy for onward relay of R2 inter-register signals may result in unacceptably long call setup times and timeouts when the call passes through several exchanges as well as a gateway before terminating. Several strategies are available for speeding up the transfer of signalling information across a given relay point. In the worst case, the relay point has to act as an exchange, terminating the signalling on one side and reoriginating the call on the other.
请注意，R2寄存器间信号的前向中继的简单策略可能会导致呼叫在终止前通过多个交换机以及网关时出现不可接受的长呼叫设置时间和超时。有几种策略可用于加速给定中继点上的信令信息传输。在最坏的情况下，中继点必须充当交换机，在一端终止信令，在另一端重新安排呼叫。
Upper Frequency (Hz)
高频（Hz）
+----------------------+-------+-------+-------+--------+--------+
| Lower Frequency (Hz) | 1500 | 1620 | 1740 | 1860 | 1980 |
+----------------------+-------+-------+-------+--------+--------+
| 1380 | Fwd 1 | Fwd 2 | Fwd 4 | Fwd 7 | Fwd 11 |
| | | | | | |
| 1500 | | Fwd 3 | Fwd 5 | Fwd 8 | Fwd 12 |
| | | | | | |
| 1620 | | | Fwd 6 | Fwd 9 | Fwd 13 |
| | | | | | |
| 1740 | | | | Fwd 10 | Fwd 14 |
| | | | | | |
| 1860 | | | | | Fwd 15 |
+----------------------+-------+-------+-------+--------+--------+
+----------------------+-------+-------+-------+--------+--------+
| Lower Frequency (Hz) | 1500 | 1620 | 1740 | 1860 | 1980 |
+----------------------+-------+-------+-------+--------+--------+
| 1380 | Fwd 1 | Fwd 2 | Fwd 4 | Fwd 7 | Fwd 11 |
| | | | | | |
| 1500 | | Fwd 3 | Fwd 5 | Fwd 8 | Fwd 12 |
| | | | | | |
| 1620 | | | Fwd 6 | Fwd 9 | Fwd 13 |
| | | | | | |
| 1740 | | | | Fwd 10 | Fwd 14 |
| | | | | | |
| 1860 | | | | | Fwd 15 |
+----------------------+-------+-------+-------+--------+--------+
Table 4: R2 Forward Register Signals
表4:R2前向寄存器信号
Upper Frequency (Hz)
高频（Hz）
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 1140 | 1020 | 900 | 780 | 660 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 1020 | Bkwd 1 | | | | |
| | | | | | |
| 900 | Bkwd 2 | Bkwd 3 | | | |
| | | | | | |
| 780 | Bkwd 4 | Bkwd 5 | Bkwd 6 | | |
| | | | | | |
| 660 | Bkwd 7 | Bkwd 8 | Bkwd 9 | Bkwd 10 | |
| | | | | | |
| 540 | Bkwd 11 | Bkwd 12 | Bkwd 13 | Bkwd 14 | Bkwd 15 |
+-----------------+---------+---------+---------+---------+---------+
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 1140 | 1020 | 900 | 780 | 660 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 1020 | Bkwd 1 | | | | |
| | | | | | |
| 900 | Bkwd 2 | Bkwd 3 | | | |
| | | | | | |
| 780 | Bkwd 4 | Bkwd 5 | Bkwd 6 | | |
| | | | | | |
| 660 | Bkwd 7 | Bkwd 8 | Bkwd 9 | Bkwd 10 | |
| | | | | | |
| 540 | Bkwd 11 | Bkwd 12 | Bkwd 13 | Bkwd 14 | Bkwd 15 |
+-----------------+---------+---------+---------+---------+---------+
Table 5: R2 Backward Register Signals
表5:R2反向寄存器信号
ABCD is a 4-bit signalling system used by digital trunks, where A, B, C, and D are the designations of the individual bits. Signalling may be 16-state (all four bits used), 4-state (A and B bits used), or 2-state (A-bit only used). ABCD signalling events are all mutually exclusive states. The most recent state transition determines the current state.
ABCD是数字中继使用的4位信令系统，其中a、B、C和D是各个位的名称。信令可以是16状态（使用全部四位）、4状态（使用A和B位）或2状态（仅使用A位）。ABCD信号发送事件都是相互排斥的状态。最近的状态转换确定当前状态。
When using Extended Super Frame (ESF) T1 framing, signalling information is sent as robbed bits in frames 6, 12, 18, and 24. A D4 superframe only transmits 4-state signalling with A and B bits. On the Conference of European Postal and Telecommunications (CEPT) E1 frame, all signalling is carried in timeslot 16, and two channels of 16-state (ABCD) signalling are sent per frame. ITU-T Recommendation G.704 [10] gives the details of ABCD bit placement within the various framing arrangements.
当使用扩展超级帧（ESF）T1帧时，信令信息作为帧6、12、18和24中的抢夺位发送。D4超帧仅传输具有A和B位的4态信令。在欧洲邮政和电信会议（CEPT）E1帧上，所有信令都在时隙16中传输，并且每帧发送两个信道的16状态（ABCD）信令。ITU-T建议G.704[10]给出了各种成帧安排中ABCD位放置的细节。
The meaning of ABCD signals varies with the application. One example of a specification of ABCD signalling codes is T1.403.02 [16], which reflects North American practice for "loop" signalling as opposed to the trunk signalling discussed in previous sections.
ABCD信号的含义因应用而异。ABCD信令代码规范的一个示例是T1.403.02[16]，它反映了北美的“环路”信令实践，而不是前面章节中讨论的中继信令。
Since ABCD information is a state rather than a changing signal, implementations SHOULD use the following triple-redundancy mechanism, similar to the one specified in ITU-T Rec. I.366.2 [15], Annex L. At the time of a transition, the same ABCD information is sent 3 times at an interval of 5 ms. If another transition occurs during this time, then this continues. After a period of no change, the ABCD information is sent every 5 seconds.
由于ABCD信息是一种状态，而不是一种变化的信号，因此实施应使用以下三重冗余机制，类似于ITU-T Rec.I.366.2[15]附录L中规定的机制。在过渡时，相同的ABCD信息以5ms的间隔发送3次。如果在此期间发生另一个过渡，然后继续。在一段时间不变后，ABCD信息每5秒发送一次。
As shown in Table 1, the 16 possible states are represented by event codes 144 to 159, respectively. Implementations using these event codes MUST map them to and from the ABCD information based on the following principles:
如表1所示，16种可能的状态分别由事件代码144至159表示。使用这些事件代码的实现必须根据以下原则将它们映射到ABCD信息或从ABCD信息映射到ABCD信息：
1. State numbers are derived from the used subset of ABCD bits by treating them as a single binary number, where the A bit is the high-order bit.
1. 通过将ABCD位的子集视为单个二进制数（其中a位为高阶位），可以从使用的ABCD位子集中导出状态号。
2. State numbers map to event codes by order of increasing value (i.e., state number 0 maps to event code 144, ..., state number 15 maps to event code 159).
2. 州编号按值的递增顺序映射到事件代码（即，州编号0映射到事件代码144，…，州编号15映射到事件代码159）。
If only the A and B bits are being used, then the mapping to event codes shall be as follows:
如果仅使用A和B位，则事件代码的映射应如下所示：
o A=0, B=0 maps to event code 208;
o A=0，B=0映射到事件代码208；
o A=0, B=1 maps to event code 209;
o A=0，B=1映射到事件代码209；
o A=1, B=0 maps to event code 210;
o A=1，B=0映射到事件代码210；
o A=1, B=1 maps to event code 211;
o A=1，B=1映射到事件代码211；
Finally, if only the A bit is used,
最后，如果只使用A位，
o A = 0 maps to event code 206;
o A＝0映射到事件代码206；
o A = 1 maps to event code 207;
o A=1映射到事件代码207；
Separate event codes are assigned to A-bit and AB-bit signalling because, as indicated in Rec. G.704 [10], when the B, C, and D bits are unused, their default values differ between transmission systems. By specifying codes for only the used bits, this memo allows the receiving gateway to fill in the remaining bits according to local configuration.
单独的事件代码分配给A位和AB位信令，因为如记录G.704[10]所示，当B、C和D位未使用时，其默认值在传输系统之间不同。通过仅为使用的位指定代码，此备忘录允许接收网关根据本地配置填写剩余位。
Continuity tones are used for testing circuit continuity during call setup. Two basic procedures are used. In international practice, clause 7 of ITU-T Recommendation Q.724 [8] describes a procedure applicable to four-wire trunk circuits, where a single 2000 +/- 20 Hz check-tone is transmitted from the initiating telephone switch. The remote switch sets up a loopback, and the continuity check passes if the sending switch can detect the tone on the return path. Clause 8 of Q.724 describes the procedure for two-wire trunk circuits. The two-wire procedure involves two tones: a 2000 Hz tone sent in the forward direction and a 1780 +/- 20 Hz tone sent in response.
连续性音调用于在呼叫设置期间测试电路的连续性。使用两个基本程序。在国际实践中，ITU-T建议Q.724[8]第7条描述了适用于四线中继电路的程序，其中从起始电话交换机发送单个2000+/-20 Hz检查音。远程开关设置环回，如果发送开关能够检测到返回路径上的音调，则连续性检查通过。Q.724第8条描述了双线主干电路的程序。双线程序涉及两种音调：正向发送的2000 Hz音调和响应发送的1780+/-20 Hz音调。
Note that implementations often send a slightly different check-tone, e.g., 2010 Hz, because of undesirable aliasing properties of 2000 Hz.
请注意，由于2000 Hz的不良混叠特性，实现通常会发送稍有不同的检查音调，例如2010 Hz。
If implementations use the telephone-events payload type to propagate continuity check-tones, they MUST map these tones to event codes as follows:
如果实现使用电话事件有效负载类型来传播连续性检查音调，则必须将这些音调映射到事件代码，如下所示：
o For four-wire continuity testing, the 2000 Hz check-tone is mapped to event code 121.
o 对于四线连续性测试，2000 Hz检查音映射到事件代码121。
o For two-wire continuity testing, the initial 2000 Hz check-tone Hz tone is mapped to event code 121. The 1780 Hz continuity verify-tone is mapped to event code 122.
o 对于双线连续性测试，初始2000 Hz检查音映射到事件代码121。1780 Hz连续性验证音映射到事件代码122。
This event indicates that the trunk is unavailable for service. The length of the downtime is indicated in the duration field. The duration field is set to a value that allows adequate granularity in describing downtime. A value of 1 second is RECOMMENDED. When the
此事件表示中继不可用于服务。停机时间的长度在持续时间字段中指示。“持续时间”字段设置为允许在描述停机时间时有足够的粒度的值。建议使用1秒的值。当
trunk becomes unavailable, this event is sent with the same timestamp three times at an interval of 20 ms. If the trunk persists in the unavailable state at the end of the indicated duration, then the event is retransmitted, preferably with the same redundancy scheme.
中继变为不可用时，此事件将以20毫秒的间隔使用相同的时间戳发送三次。如果中继在指定的持续时间结束时仍处于不可用状态，则事件将被重新传输，最好使用相同的冗余方案。
Unavailability of the trunk might result from a failure or an administrative action. This event is used in a stateless manner to synchronize trunk unavailability between equipment connected through provisioned RTP trunks. It avoids the unnecessary consumption of bandwidth in sending a continuous stream of RTP packets with a fixed payload for the duration of the downtime, as would be required in certain E1-based applications. In T1-based applications, trunk conditioning via the ABCD transitional events can be used instead.
主干不可用可能是由故障或管理操作造成的。此事件以无状态方式用于同步通过配置的RTP中继连接的设备之间的中继不可用性。它避免了在停机期间发送具有固定负载的连续RTP数据包流时不必要的带宽消耗，这在某些基于E1的应用程序中是必需的。在基于T1的应用程序中，可以使用通过ABCD过渡事件的中继条件。
The metering pulse event may be used to transmit meter pulsing for billing purposes. For background information, one possible reference is http://www.seg.co.uk/telecomm/automat3.htm. Since the metering pulse is a discrete event, each metering pulse event report MUST have both the 'M' and 'E' bits set. Meter pulsing is normally transmitted by out-of-band means while conversation is in progress. Senders MUST therefore be prepared to transmit both the telephone-event and audio payload types simultaneously. Metering pulse events MUST be retransmitted as recommended in Section 2.5.1.4 of RFC 4733 [4]. It is RECOMMENDED that the retransmission interval be the lesser of 50 ms and the pulsing rate but no less than audio packetization rate.
计量脉冲事件可用于传输用于计费目的的计量脉冲。关于背景信息，一个可能的参考是http://www.seg.co.uk/telecomm/automat3.htm. 由于计量脉冲是一个离散事件，每个计量脉冲事件报告必须设置“M”和“E”位。在通话过程中，仪表脉冲通常通过带外方式传输。因此，发送方必须准备好同时传输电话事件和音频有效负载类型。计量脉冲事件必须按照RFC 4733[4]第2.5.1.4节的建议重新传输。建议重传间隔为50 ms和脉冲率中的较小者，但不小于音频打包率。
The ability to adapt to congestion varies with the signalling system being used and also differs between line and register signals.
适应拥塞的能力因所使用的信令系统而异，线路和寄存器信号也不同。
With the specific exception of register signalling for S.S. No. 5 and R1/MF, the signals described in this document are fairly tolerant of lengthened durations, should these be necessary. Thus in congested conditions, the sender may adapt by lengthening the reporting interval for the tones concerned. At the receiving end, if a tone is being played out and an under-run occurs due to delayed or lost packets, it is best to continue playing the tone until the next packet arrives. Interrupting a tone prematurely, with or without resumption, can cause the call setup attempt to fail, whereas extended playout just increases the call setup time.
除5号S.S.和R1/MF的寄存器信号外，本文件中描述的信号对延长的持续时间（如有必要）具有相当的容忍度。因此，在拥挤的条件下，发送者可以通过延长相关音调的报告间隔来适应。在接收端，如果正在播放音调，并且由于延迟或丢失的数据包而出现欠播，则最好继续播放音调，直到下一个数据包到达。无论是否恢复，过早中断铃声都可能导致呼叫设置尝试失败，而延长播放时间只会增加呼叫设置时间。
Register signalling for S.S. No. 5 and R1/MF is subject to time constraints. Both the tone signals and the silent periods between them have specified durations and tolerances of the order of 5 to 10 ms. The durations of the individual tones are of the order of two to
5号S.S.和R1/MF的寄存器信令受时间限制。音调信号和它们之间的静音周期都有规定的持续时间和公差，大约为5到10毫秒。各个音调的持续时间大约为2到10毫秒
three packetization intervals (55/68 ms, with the initial KP lasting 100 ms). The critical requirement for transmission of the telephony-event payload is that the receiver knows which signal to play out at a given moment. It is less important that the receiver receive timely notification of the end of each tone. Rather, it should play out the sequence with the durations specified by the signalling standard instead of the actual durations reported.
三次打包间隔（55/68 ms，初始KP持续100 ms）。传输电话事件有效载荷的关键要求是接收器知道在给定时刻播放哪个信号。接收者及时收到每个音调结束的通知并不那么重要。相反，它应该按照信号标准规定的持续时间而不是报告的实际持续时间播放序列。
These considerations suggest that as soon as a register signal has been reliably identified, the sender should emit a report of that tone. It should then provide an update within 5 ms for reliability and no more updates until reporting the end of the tone.
这些考虑表明，一旦可靠地识别出寄存器信号，发送方应发出该音调的报告。然后，它应在5毫秒内提供可靠性更新，在报告音调结束之前，不再提供更新。
Increasing the playout buffer at the receiver during register signalling will increase reliability. This has to be weighed against the implied increase in call setup time.
在寄存器信令期间增加接收器处的播放缓冲区将提高可靠性。这必须与呼叫设置时间的隐含增加进行权衡。
The events for which event codes are provided in this document relate directly to the setup, billing, and takedown of telephone calls. As such, they are subject, using the terminology of RFC 3552 [12], to threats to both communications and system security. The attacks of concern are:
本文档中提供事件代码的事件与电话呼叫的设置、计费和记录直接相关。因此，使用RFC 3552[12]的术语，它们会受到通信和系统安全的威胁。令人关切的攻击是：
o confidentiality violations (monitoring of calling and called numbers);
o 违反保密规定（监控呼叫和被叫号码）；
o establishment of unauthorized telephone connections through message insertion;
o 通过插入信息建立未经授权的电话连接；
o hijacking of telephone connections through message insertion or man-in-the-middle modification of messages;
o 通过插入信息或中间人修改信息劫持电话连接；
o denial of service to individual telephone calls through message insertion, modification, deletion, or delay.
o 通过消息插入、修改、删除或延迟对单个电话呼叫的拒绝服务。
These attacks can be prevented by the use of appropriate confidentiality, authentication, or integrity protection. If confidentiality, authentication, or integrity protection are needed, then Secure Real-time Transport Protocol (SRTP) [3] SHOULD be used with automated key management.
可以通过使用适当的机密性、身份验证或完整性保护来防止这些攻击。如果需要保密性、身份验证或完整性保护，则安全实时传输协议（SRTP）[3]应与自动密钥管理一起使用。
Additional security considerations are described in RFC 4733 [4].
RFC 4733[4]中描述了其他安全注意事项。
This document defines the event codes shown in Table 6. These events are additions to the telephone-event registry established by RFC 4733 [4]. The reference for all of them is the present document.
本文件定义了表6所示的事件代码。这些事件是RFC 4733[4]建立的电话事件注册表的补充。所有这些文件的参考文件均为本文件。
+------------+-----------------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+-----------------------------------------+-----------+
| 121 | Continuity check-tone | [RFC5244] |
| | | |
| 122 | Continuity verify-tone | [RFC5244] |
| | | |
| 123 | MF Code 11 (SS No. 5) or KP3P/ST3P (R1) | [RFC5244] |
| | | |
| 124 | MF KP (SS No. 5) or KP1 (R1) | [RFC5244] |
| | | |
| 125 | MF KP2 (SS No. 5) or KP2P/ST2P (R1) | [RFC5244] |
| | | |
| 126 | MF ST (SS No. 5 and R1) | [RFC5244] |
| | | |
| 127 | MF Code 12 (SS No. 5) or KP'/STP (R1) | [RFC5244] |
| | | |
| 128 | SS No. 5 or R1 digit "0" | [RFC5244] |
| | | |
| 129 | SS No. 5 or R1 digit "1" | [RFC5244] |
| | | |
| 130 | SS No. 5 or R1 digit "2" | [RFC5244] |
| | | |
| 131 | SS No. 5 or R1 digit "3" | [RFC5244] |
| | | |
| 132 | SS No. 5 or R1 digit "4" | [RFC5244] |
| | | |
| 133 | SS No. 5 or R1 digit "5" | [RFC5244] |
| | | |
| 134 | SS No. 5 or R1 digit "6" | [RFC5244] |
| | | |
| 135 | SS No. 5 or R1 digit "7" | [RFC5244] |
| | | |
| 136 | SS No. 5 or R1 digit "8" | [RFC5244] |
| | | |
| 137 | SS No. 5 or R1 digit "9" | [RFC5244] |
| | | |
| 144 | ABCD signalling state '0000' | [RFC5244] |
| | | |
| 145 | ABCD signalling state '0001' | [RFC5244] |
| | | |
| 146 | ABCD signalling state '0010' | [RFC5244] |
+------------+-----------------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+-----------------------------------------+-----------+
| 121 | Continuity check-tone | [RFC5244] |
| | | |
| 122 | Continuity verify-tone | [RFC5244] |
| | | |
| 123 | MF Code 11 (SS No. 5) or KP3P/ST3P (R1) | [RFC5244] |
| | | |
| 124 | MF KP (SS No. 5) or KP1 (R1) | [RFC5244] |
| | | |
| 125 | MF KP2 (SS No. 5) or KP2P/ST2P (R1) | [RFC5244] |
| | | |
| 126 | MF ST (SS No. 5 and R1) | [RFC5244] |
| | | |
| 127 | MF Code 12 (SS No. 5) or KP'/STP (R1) | [RFC5244] |
| | | |
| 128 | SS No. 5 or R1 digit "0" | [RFC5244] |
| | | |
| 129 | SS No. 5 or R1 digit "1" | [RFC5244] |
| | | |
| 130 | SS No. 5 or R1 digit "2" | [RFC5244] |
| | | |
| 131 | SS No. 5 or R1 digit "3" | [RFC5244] |
| | | |
| 132 | SS No. 5 or R1 digit "4" | [RFC5244] |
| | | |
| 133 | SS No. 5 or R1 digit "5" | [RFC5244] |
| | | |
| 134 | SS No. 5 or R1 digit "6" | [RFC5244] |
| | | |
| 135 | SS No. 5 or R1 digit "7" | [RFC5244] |
| | | |
| 136 | SS No. 5 or R1 digit "8" | [RFC5244] |
| | | |
| 137 | SS No. 5 or R1 digit "9" | [RFC5244] |
| | | |
| 144 | ABCD signalling state '0000' | [RFC5244] |
| | | |
| 145 | ABCD signalling state '0001' | [RFC5244] |
| | | |
| 146 | ABCD signalling state '0010' | [RFC5244] |
| | | |
| 147 | ABCD signalling state '0011' | [RFC5244] |
| | | |
| 148 | ABCD signalling state '0100' | [RFC5244] |
| | | |
| 149 | ABCD signalling state '0101' | [RFC5244] |
| | | |
| 150 | ABCD signalling state '0110' | [RFC5244] |
| | | |
| 151 | ABCD signalling state '0111' | [RFC5244] |
| | | |
| 152 | ABCD signalling state '1000' | [RFC5244] |
| | | |
| 153 | ABCD signalling state '1001' | [RFC5244] |
| | | |
| 154 | ABCD signalling state '1010' | [RFC5244] |
| | | |
| 155 | ABCD signalling state '1011' | [RFC5244] |
| | | |
| 156 | ABCD signalling state '1100' | [RFC5244] |
| | | |
| 157 | ABCD signalling state '1101' | [RFC5244] |
| | | |
| 158 | ABCD signalling state '1110' | [RFC5244] |
| | | |
| 159 | ABCD signalling state '1111' | [RFC5244] |
| | | |
| 174 | Metering pulse | [RFC5244] |
| | | |
| 175 | Trunk unavailable | [RFC5244] |
| | | |
| 176 | MFC forward signal 1 | [RFC5244] |
| | | |
| 177 | MFC forward signal 2 | [RFC5244] |
| | | |
| 178 | MFC forward signal 3 | [RFC5244] |
| | | |
| 179 | MFC forward signal 4 | [RFC5244] |
| | | |
| 180 | MFC forward signal 5 | [RFC5244] |
| | | |
| 181 | MFC forward signal 6 | [RFC5244] |
| | | |
| 182 | MFC forward signal 7 | [RFC5244] |
| | | |
| 183 | MFC forward signal 8 | [RFC5244] |
| | | |
| 184 | MFC forward signal 9 | [RFC5244] |
| | | |
| 147 | ABCD signalling state '0011' | [RFC5244] |
| | | |
| 148 | ABCD signalling state '0100' | [RFC5244] |
| | | |
| 149 | ABCD signalling state '0101' | [RFC5244] |
| | | |
| 150 | ABCD signalling state '0110' | [RFC5244] |
| | | |
| 151 | ABCD signalling state '0111' | [RFC5244] |
| | | |
| 152 | ABCD signalling state '1000' | [RFC5244] |
| | | |
| 153 | ABCD signalling state '1001' | [RFC5244] |
| | | |
| 154 | ABCD signalling state '1010' | [RFC5244] |
| | | |
| 155 | ABCD signalling state '1011' | [RFC5244] |
| | | |
| 156 | ABCD signalling state '1100' | [RFC5244] |
| | | |
| 157 | ABCD signalling state '1101' | [RFC5244] |
| | | |
| 158 | ABCD signalling state '1110' | [RFC5244] |
| | | |
| 159 | ABCD signalling state '1111' | [RFC5244] |
| | | |
| 174 | Metering pulse | [RFC5244] |
| | | |
| 175 | Trunk unavailable | [RFC5244] |
| | | |
| 176 | MFC forward signal 1 | [RFC5244] |
| | | |
| 177 | MFC forward signal 2 | [RFC5244] |
| | | |
| 178 | MFC forward signal 3 | [RFC5244] |
| | | |
| 179 | MFC forward signal 4 | [RFC5244] |
| | | |
| 180 | MFC forward signal 5 | [RFC5244] |
| | | |
| 181 | MFC forward signal 6 | [RFC5244] |
| | | |
| 182 | MFC forward signal 7 | [RFC5244] |
| | | |
| 183 | MFC forward signal 8 | [RFC5244] |
| | | |
| 184 | MFC forward signal 9 | [RFC5244] |
| | | |
| 185 | MFC forward signal 10 | [RFC5244] |
| | | |
| 186 | MFC forward signal 11 | [RFC5244] |
| | | |
| 187 | MFC forward signal 12 | [RFC5244] |
| | | |
| 188 | MFC forward signal 13 | [RFC5244] |
| | | |
| 189 | MFC forward signal 14 | [RFC5244] |
| | | |
| 190 | MFC forward signal 15 | [RFC5244] |
| | | |
| 191 | MFC backward signal 1 | [RFC5244] |
| | | |
| 192 | MFC backward signal 2 | [RFC5244] |
| | | |
| 193 | MFC backward signal 3 | [RFC5244] |
| | | |
| 194 | MFC backward signal 4 | [RFC5244] |
| | | |
| 195 | MFC backward signal 5 | [RFC5244] |
| | | |
| 196 | MFC backward signal 6 | [RFC5244] |
| | | |
| 197 | MFC backward signal 7 | [RFC5244] |
| | | |
| 198 | MFC backward signal 8 | [RFC5244] |
| | | |
| 199 | MFC backward signal 9 | [RFC5244] |
| | | |
| 200 | MFC backward signal 10 | [RFC5244] |
| | | |
| 201 | MFC backward signal 11 | [RFC5244] |
| | | |
| 202 | MFC backward signal 12 | [RFC5244] |
| | | |
| 203 | MFC backward signal 13 | [RFC5244] |
| | | |
| 204 | MFC backward signal 14 | [RFC5244] |
| | | |
| 205 | MFC backward signal 15 | [RFC5244] |
| | | |
| 206 | A bit signalling state '0' | [RFC5244] |
| | | |
| 207 | A bit signalling state '1' | [RFC5244] |
| | | |
| 208 | AB bit signalling state '00' | [RFC5244] |
| | | |
| 185 | MFC forward signal 10 | [RFC5244] |
| | | |
| 186 | MFC forward signal 11 | [RFC5244] |
| | | |
| 187 | MFC forward signal 12 | [RFC5244] |
| | | |
| 188 | MFC forward signal 13 | [RFC5244] |
| | | |
| 189 | MFC forward signal 14 | [RFC5244] |
| | | |
| 190 | MFC forward signal 15 | [RFC5244] |
| | | |
| 191 | MFC backward signal 1 | [RFC5244] |
| | | |
| 192 | MFC backward signal 2 | [RFC5244] |
| | | |
| 193 | MFC backward signal 3 | [RFC5244] |
| | | |
| 194 | MFC backward signal 4 | [RFC5244] |
| | | |
| 195 | MFC backward signal 5 | [RFC5244] |
| | | |
| 196 | MFC backward signal 6 | [RFC5244] |
| | | |
| 197 | MFC backward signal 7 | [RFC5244] |
| | | |
| 198 | MFC backward signal 8 | [RFC5244] |
| | | |
| 199 | MFC backward signal 9 | [RFC5244] |
| | | |
| 200 | MFC backward signal 10 | [RFC5244] |
| | | |
| 201 | MFC backward signal 11 | [RFC5244] |
| | | |
| 202 | MFC backward signal 12 | [RFC5244] |
| | | |
| 203 | MFC backward signal 13 | [RFC5244] |
| | | |
| 204 | MFC backward signal 14 | [RFC5244] |
| | | |
| 205 | MFC backward signal 15 | [RFC5244] |
| | | |
| 206 | A bit signalling state '0' | [RFC5244] |
| | | |
| 207 | A bit signalling state '1' | [RFC5244] |
| | | |
| 208 | AB bit signalling state '00' | [RFC5244] |
| | | |
| 209 | AB bit signalling state '01' | [RFC5244] |
| | | |
| 210 | AB bit signalling state '10' | [RFC5244] |
| | | |
| 211 | AB bit signalling state '11' | [RFC5244] |
+------------+-----------------------------------------+-----------+
| | | |
| 209 | AB bit signalling state '01' | [RFC5244] |
| | | |
| 210 | AB bit signalling state '10' | [RFC5244] |
| | | |
| 211 | AB bit signalling state '11' | [RFC5244] |
+------------+-----------------------------------------+-----------+
Table 6: Channel-Oriented Signalling Events in the Audio/Telephone-Event Event Code Registry
表6：音频/电话事件代码注册表中的面向信道的信令事件
The complete list of acknowledgements for contribution to the development and revision of RFC 2833 is contained in RFC 4733 [4]. The Editor believes or is aware that the following people contributed specifically to the present document: Flemming Andreasen, Rex Coldren, Bill Foster, Alfred Hoenes, Rajesh Kumar, Aleksandar Lebl, Zarko Markov, Oren Peleg, Moshe Samoha, Adrian Soncodi, and Yaakov Stein. Steve Norreys and Roni Even provided useful review comments.
RFC 4733[4]中包含了对RFC 2833的开发和修订做出贡献的完整致谢清单。编辑相信或意识到以下人员专门为本文件做出了贡献：弗莱明·安德里亚森、雷克斯·科尔德伦、比尔·福斯特、阿尔弗雷德·霍恩斯、拉杰什·库马尔、亚历山大·勒布尔、扎尔科·马尔科夫、奥伦·佩莱格、莫什·萨莫哈、阿德里安·索科迪和雅科夫·斯坦。Steve Norreys和Roni甚至提供了有用的评论。
[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] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[3] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[4] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[4] Schulzrinne，H.和T.Taylor，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 47332006年12月。
[5] International Telecommunication Union, "Specifications for signalling system no. 5", ITU-T Recommendation Q.140-Q.180, November 1988.
[5] 国际电信联盟，“第5号信令系统规范”，ITU-T建议Q.140-Q.180，1988年11月。
[6] International Telecommunication Union, "Specifications of Signalling System R1", ITU-T Recommendation Q.310-Q.332, November 1988.
[6] 国际电信联盟，“信号系统R1规范”，ITU-T建议Q.310-Q.332，1988年11月。
[7] International Telecommunication Union, "Specifications of Signalling System R2", ITU-T Recommendation Q.400-Q.490, November 1988.
[7] 国际电信联盟，“信号系统R2规范”，ITU-T建议Q.400-Q.490，1988年11月。
[8] International Telecommunication Union, "Telephone user part signalling procedures", ITU-T Recommendation Q.724, November 1988.
[8] 国际电信联盟，“电话用户部分信令程序”，ITU-T建议Q.724，1988年11月。
[9] Telcordia Technologies, "LSSGR: signalling for Analog Interfaces", Generic Requirement GR-506, June 1996.
[9] Telcordia Technologies，“LSSGR：模拟接口的信令”，通用要求GR-506，1996年6月。
[10] International Telecommunication Union, "Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels", ITU-T Recommendation G.704, October 1998.
[10] 国际电信联盟，“在1544、6312、2048、8448和44 736 kbit/s等级使用的同步帧结构”，ITU-T建议G.704，1998年10月。
[11] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[11] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[12] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[12] Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[13] 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.
[13] 国际电信联盟，“语音编码器：以5.3和6.3 kbit/s传输的多媒体通信用双速率语音编码器”，ITU-T建议G.723.1，1996年3月。
[14] 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.
[14] 国际电信联盟，“使用共轭结构代数码激励线性预测（CS-ACELP）对8kbit/s语音进行编码”，ITU-T建议G.729，1996年3月。
[15] International Telecommunication Union, "AAL type 2 service specific convergence sublayer for trunking", ITU-T Recommendation I.366.2, February 1999.
[15] 国际电信联盟，“用于中继的AAL 2类特定服务汇聚子层”，ITU-T建议I.366.2，1999年2月。
[16] ANSI/T1, "Network and Customer Installation Interfaces -- DS1 Robbed-Bit signalling State Definitions", American National Standard for Telecommunications T1.403.02-1999, May 1999.
[16] ANSI/T1，“网络和客户安装接口——DS1被抢位信令状态定义”，美国电信国家标准T1.403.02-1999，1999年5月。
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 CA
汤姆泰勒北电1852洛林大道渥太华，安大略K1H 6Z8加利福尼亚州
EMail: tom.taylor@rogers.com
EMail: tom.taylor@rogers.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.