[要約] RFC 5244は、チャネル指向の電話信号のイベントの定義に関するものであり、電話システムの通信プロトコルの標準化を目的としています。
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イベントの一部は、その仕様が曖昧、誤った、またはredundantであるために廃止されました。実際、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
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でまだ使用されているいくつかのチャネル関連シグナル伝達システムの1つ内の信号に対応しています。
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のトランク（または回路）は、電話スイッチ間のメディアパスです。一連のプロトコルは、個々のトランクのトーンと電気条件を使用して、それらを使用して電話を設定するために開発されました。このドキュメントで定義されているイベントは、IPネットワークで信号をかけずに2つのゲートウェイの間にこのようなPSTNシグナル伝達が「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 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.
「RTPトランク」アプリケーションでは、RTPを使用して、2つのノード間で通常の回路スイッチトランクを交換します。これは、ほとんどの場合、ほとんどの回路が切り替えられている電話ネットワークで特に興味深いものです。この場合、RTPトランクの各端は、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.
このドキュメントでは、4つの異なるシグナル伝達システムに関連するイベントを定義します。これらのうち3つは、多周波トーンの交換に基づいています。4番目はデジタルトランクでのみ動作し、エンコードされたメディアから盗まれた低注文ビットを使用します。さらに、このドキュメントでは、メディアパスの連続性テストなどのタスクをサポートするためのトーンイベントを定義しています。
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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
In addition to the abbreviations defined below for specific events, this document uses the following abbreviations:
特定のイベントについて以下に定義されている略語に加えて、このドキュメントは次の略語を使用します。
KP Key Pulse
KPキーパルス
MF Multi-frequency
MF多周波
PSTN Public Switched (circuit) Telephone Network
PSTN Public Switched（Circuit）電話ネットワーク
RTP Real-time Transport Protocol [2]
RTPリアルタイムトランスポートプロトコル[2]
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 2833ではなくRFC 4733によって設定されたことに注意してください。したがって、RFC 2833で最初に作成されたイベントコードの割り当ては、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 |
+---------------------+------------+-------------+--------+---------+
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.
シグナリングシステムNo. 5（SS No. 5）は、ITU-Tの推奨事項Q.140からQ.180 [5]で定義されています。2つの信号システムがあります。トランクを取得および解放するための「ライン」シグナリングと、「登録」シグナリングは、1つのスイッチから次のスイッチに桁を前方に渡す。
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.
No. 5ラインシグナルは、2400 Hzと2600 Hzの2つの周波数でトーンを使用します。トーンはほとんどの信号で単独で使用されますが、クリアフォワードとリリースガードには一緒に使用されます。（これにより、メディアコンテンツが頻度の1つを複製することにより、偶発的なコールリリースの可能性が減ります。）トーンで示される特定の信号は、適用されるコールセットアップの段階に依存します。
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.
No. 5ラインシグナル伝達をサポートするイベントは定義されていません。ただし、実装は、セクション2.4で説明し、表1に示すABビットイベントを使用して、SS No. 5ライン信号を伝播する場合があります。そうすると、次のマッピングを使用する必要があります。これらのマッピングは、A = 0を2400 Hz信号の存在とb = 0の存在に等しい基礎となるマッピングに基づいており、指定された方向に2600 Hz信号の存在です。
o both 2400 and 2600 Hz present: event code 208;
o 2400 Hzと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.
KPは、SS No. 5の「押収」信号が停止してから80 /-20ミリ秒から送信する必要があります。
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.
No. 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 |
+-----------------+---------+---------+---------+---------+---------+
Table 2: SS No. 5 Register Signals
表2：SS No. 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:
SS 5登録信号を携帯するために電話イベントのペイロードを使用した実装は、表1の次のイベントを使用して、表2に示すレジスタ信号を伝える必要があります。
o event code 128 to convey Digit 0;
o 数字0を伝えるイベントコード128。
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 コード11を伝えるためのイベントコード123。
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 STを伝えるためのイベントコード126。
o event code 127 to convey Code 12.
o コード12を伝えるイベントコード127。
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信号の初期イベントレポートを送信する必要があり、これらすべての信号が完了したらすぐにイベントレポートを送信する必要があります。
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 No. 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で説明されているAビットイベントを使用し、表1に示すようにR1ライン信号を伝播する場合があります。そうすると、次のマッピングを使用する必要があります。これらのマッピングは、示された方向にa = 0を2600 Hz信号の存在に等しい基礎となるマッピングに基づいています。
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 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].
R1の信号容量は、フォワード登録信号の15コードの信号容量を持っていますが、後方登録信号はありません。各コードまたは数字は、6周波数のセットからトーンペアで送信されます。R1レジスタ信号は、KP、ST、および「9」から桁「0」で構成されています。信号に割り当てられた周波数を表3に示します。これらの周波数は、KPがSS No. 5のKP1に対応する周波数の組み合わせを使用していることを除いて、同様に指定されたSS No. 5レジスタ信号に割り当てられた周波数と同じであることに注意してください。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 |
+------------+---------+---------+---------+---------+--------------+
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に示すレジスタ信号を伝えるために、表1の次のイベントを使用する必要があります。
o event code 128 to convey Digit 0;
o 数字0を伝えるイベントコード128。
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 STを伝えるためのイベントコード126。
o event code 127 to convey KP' or STP.
o KP 'またはSTPを伝えるイベントコード127。
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.
元のテレフォニー信号と同様に、受信機は、シグナリングシーケンスの位置に基づいてKPXまたはSTX信号としてコード123、125、および127を解釈します。
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（Inter）レジスタ信号は、多周波、強制、帯域、エンドツーエンド、およびチャネルに関連するものです。
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を少し使用して1ビットデジタル、またはAとBビットの両方を使用してデジタルである場合があります。実装は、セクション2.4に記載されているAビットまたはABビットイベントを使用して、これらの信号を伝播するために表1に示す場合があります。そうすると、次のマッピングを使用する必要があります。
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のマッピングとイベントコードの間のマッピングが両方向に同じであり、原則に従うものとする2つのビットで運ばれます。セクション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 (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.
R2シグナル伝達では、シグナリングシーケンスは、「つかむ」信号を送信することにより、発信交換から開始されます。シグナルを「押収」する（およびR2Dでの「承認の表示」信号）の後、シグナリングシーケンスはMFレジスタ信号を使用して継続します。ITU-Tの推奨Q.441は、フォワードMFレジスタ信号（上部周波数）をグループ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レジスタシグナル伝達で使用されるトーンは、6つの周波数のうち2つの組み合わせです。全国バージョンは、10の信号（5つの周波数のうち2つ）または6つの信号（4つの周波数のうち2つ）に削減できます。
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レジスタシグナル伝達は強制されたトーンシグナル伝達プロトコルです。つまり、「次のトーンの承認または指示」が受信されるまで、1つのトーンが再生されることを意味します。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.
トーンには意味があります。ただし、意味は、シグナル伝達でトーンが発生する場所によって異なります。意味は国にも依存する可能性があります。したがって、管理できない数のイベントを回避するために、このドキュメントは、表1に示すように、15の前方および15の後方MF R2トーンを示す手段を提供します（つまり、それぞれイベントコード176-190と191-205を使用）。これらのトーンの周波数ペアを表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 |
+----------------------+-------+-------+-------+--------+--------+
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 |
+-----------------+---------+---------+---------+---------+---------+
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は、A、B、C、およびDが個々のビットの指定であるデジタルトランクで使用される4ビットシグナルシステムです。シグナル伝達は、16状態（4ビットすべて使用）、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フレームの会議では、すべてのシグナル伝達がTimeslot 16で行われ、16状態（ABCD）シグナルの2つのチャネルがフレームごとに送信されます。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シグナル伝達コードの仕様の1つの例は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情報が5 msの間隔で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情報との間でそれらをマッピングする必要があります。
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ビットの使用されたサブセットから派生しており、単一のバイナリ番号として扱います。
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,
最後に、少しだけが使用されている場合、
o A = 0 maps to event code 206;
o a = 0イベントコード206へのマップ。
o A = 1 maps to event code 207;
o a =イベントコード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.
Recに示されているように、個別のイベントコードが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.
連続性トーンは、コールセットアップ中に回路の連続性をテストするために使用されます。2つの基本的な手順が使用されています。国際的な慣行では、ITU-Tの推奨事項Q.724 [8]の第7項は、単一の2000 /-20 Hzチェックトーンが開始電話スイッチから送信される4線型トランク回路に適用される手順について説明しています。リモートスイッチはループバックをセットアップし、送信スイッチがリターンパスのトーンを検出できる場合、連続性チェックが通過します。Q.724の条項8では、2線型トランク回路の手順について説明しています。2ワイヤの手順には、前方向に送信される2000 Hzトーンと、それに応じて1780 /-20 Hzトーンが送信される2つのトーンが含まれます。
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 4線式連続性テストの場合、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 2ワイヤの連続性テストでは、最初の2000 HzチェックトーンHzトーンがイベントコード121にマッピングされます。1780Hzの連続性検証トーンは、イベントコード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 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.
このイベントは、トランクがサービスに利用できないことを示しています。ダウンタイムの長さは、期間フィールドに示されています。持続時間フィールドは、ダウンタイムを説明する際に適切な粒度性を可能にする値に設定されます。1秒の値をお勧めします。トランクが利用できなくなると、このイベントは20 msの間隔で同じタイムスタンプで3回送信されます。指定された期間の終了時にトランクが利用できない状態で持続している場合、イベントは、できれば同じ冗長スキームを使用して再送信されます。
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トランクを介して接続された機器間のトランクの利用不能を同期するために、無国籍方法で使用されます。特定のE1ベースのアプリケーションで必要とされるように、ダウンタイムの期間中、RTPパケットの連続ストリームをダウンタイムで固定ペイロードで送信する際に、帯域幅の不必要な消費を回避します。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.
計量パルスイベントは、請求目的でメーターパルスを送信するために使用できます。背景情報については、1つの参照がhttp://www.seg.co.uk/telecomm/automat3.htmです。計量パルスは個別のイベントであるため、各メーターパルスイベントレポートには「M」ビットと「E」ビットの両方が設定されている必要があります。メーターパルスは、通常、会話が進行中に帯域外の手段によって送信されます。したがって、送信者は、電話イベントとオーディオペイロードタイプの両方を同時に送信する準備をする必要があります。計量パルスイベントは、RFC 4733のセクション2.5.1.4で推奨されるように再送信する必要があります[4]。再送信間隔は、50ミリ秒とパルスレートの低いが、オーディオパケット化レート以上であることをお勧めします。
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.
S.S. No. 5および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 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.
S.S. No. 5およびR1/MFの登録信号は、時間の制約の対象となります。トーン信号とそれらの間のサイレント期間の両方が、5〜10ミリ秒のオーダーの期間と公差を指定しています。個々のトーンの持続時間は、2〜3回のパケット化間隔（55/68ミリ秒、初期KPが100ミリ秒続く）のオーダーです。テレフォニーイベントペイロードの送信のための重要な要件は、受信者が特定の瞬間にどの信号を再生するかを知っていることです。受信者が各トーンの終了をタイムリーに通知することはそれほど重要ではありません。むしろ、報告された実際の期間ではなく、信号基準で指定された期間でシーケンスを再生する必要があります。
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] |
| | | |
| 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] |
| | | |
| 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 2833の開発と改訂への貢献のための謝辞の完全なリストは、RFC 4733に含まれています[4]。編集者は、以下の人々が現在の文書に特に貢献したことを信じている、または認識していることを認識しています：フレミング・アンドレアセン、レックス・コールドレン、ビル・フォスター、アルフレッド・ホーネス、ラジェシュ・クマール、アレクサンダー・レブロフ、ザルコ・マルコフ、オレン・ペレグ、モシュ・サモハ、エイドリアン・ソンコディ、そしてYaakov Stein。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 3550、2003年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 3711、2004年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 4733、2006年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 2833、2000年5月。
[12] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[12] Rescorla、E。and 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] International Telecommunication Union、「スピーチコーダー：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）を使用した8 kbit/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] 国際電気通信ユニオン、「Trunkingのための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 Robbed-Bit Signaling State Definitions」、American National Standard for Telecommunications 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
ヘニングシュルツリンコロンビアU.コンピュータサイエンスコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 CA
トム・テイラー・ノーテル1852ロレイン・アヴェ・オタワ、オンタリオK1H 6Z8 CA
EMail: tom.taylor@rogers.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。