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.

テレフォニーイベントRTPペイロードで運ばれたときにチャネル関連シグナリングのために使用される電話信号のためのイベントコードを追加するには、このメモの更新RFC 4733。それが取って代わるとRFC 4733の付録Aに記載されているようにRFC 2833のセクション3.14で、この目的のためにイベントコードの元割り当てに追加し、その仕様は、あいまいな誤った、または冗長だったので、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
        
1. Introduction
1. はじめに
1.1. Overview
1.1. 概要

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.

この文書では、[4]電話ネットワークにおける回路上に表示することができるシグナル伝達事象を含むようにRFC 4733の枠組みの中で定義された電話イベントのセットを拡張します。これらの事象の大部分は依然として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におけるトランク(または回路)は、電話交換機間のメディア経路です。プロトコルの連続は、それらを使用して通話を設定するために、個々のトランクの上にトーンと電気的条件を使用して開発されています。 「RTPトランク」アプリケーション:この文書で定義されたイベントは、PSTNのシグナリングは、IPネットワークにおいてシグナリングされることなく、2つのゲートウェイの間に実行されるアプリケーションをサポートします。

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つの呼び出しからのロールを交換することができる:それらは、表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つは、マルチ周波数トーンの交換に基づいています。第四は、デジタルトランク上で動作し、エンコードされたメディアから盗まれた下位ビットを利用します。また、この文書は、媒体経路の導通試験などのタスクをサポートするためのトーン・イベントを定義します。

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.

実装者は、下記の信号システムの記述が不完全であることを警告しています。これらは、関連するイベント定義にコンテキストを与えるが、実装に重要な多くの詳細を省略するために設けられています。

1.2. Terminology
1.2. 用語

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.

この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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公衆は(回路)交換電話網

RTP Real-time Transport Protocol [2]

RTPリアルタイム転送プロトコル[2]

ST Start

STスタート

2. Event Definitions
2.イベント定義

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の表8(付録A)に示すように、その仕様は、あいまいな誤った、または冗長であったので、[4]、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.

など、RFC 4733またはRFC 4733にアップデートで再確認した場合にのみ、電話イベントコードのIANAレジストリは、RFC 4733によって設定されたことに注意してください、RFC 2833によって従って、元々RFC 2833で行われたイベントコードの割り当ては、レジストリに表示されませ現在のドキュメント。

   +---------------------+------------+-------------+--------+---------+
   | 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:トランクシグナリングイベント

2.1. Signalling System No. 5
2.1. システム5号シグナリング

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.

システム5号(SS番号5)Q.180介してITU-T勧告Q.140で定義されているシグナリング[5]。取得しトランクを解放し、そして数字は一つのスイッチから次へと転送渡すシグナリング「登録」へのシグナリング「行」:これは、信号を2系統有しています。

2.1.1. Signalling System No. 5 Line Signals
2.1.1. システムの第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.

2400および2600ヘルツ:第5ラインシグナリングは2つの周波数でのトーンを使用します。トーンはなく、一緒にクリアフォワードおよびリリース・ガードのため、ほとんどの信号のために単独で使用されています。 (これは、周波数の一つを複製運ばメディアコンテンツに偶発呼解放の可能性を減少させる。)トーンで示される特定の信号は、それが適用される呼設定の段階に依存します。

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ラインシグナリングのサポートに定義されていません。しかし、実装はABビットイベントセクション2.4で説明したSS番号5ライン信号を伝達するために、表1に示さを使用するかもしれません。彼らがそうするならば、彼らは次のマッピングを使用しなければなりません。これらのマッピングは、指示方向に2600 Hzの信号の存在に2400Hzの信号及びB = 0の存在のためにA = 0等化根本的マッピングに基づいています。

o both 2400 and 2600 Hz present: event code 208;

両方2400と2600 Hzの存在O:イベントコード208。

o 2400 Hz present: event code 210;

2400Hzの存在O:イベントコード210。

o 2600 Hz present: event code 209;

2600 Hzの存在O:イベントコード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番号5は、信号が停止した「焼き付き」の後に80 +/- 20ミリ秒を開始送信しなければなりません。

2.1.2. Signalling System No. 5 Register Signals
2.1.2. システム5号登録シグナリング信号

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番レジスタシグナリングは、それらをフレーミング数字と信号を伝達するためにトーンのペアを使用します。トーンの組み合わせと、対応する信号がKP1とKP2を除くすべての信号は55ミリ秒の持続時間のために送信され、表2に示されています。 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番号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:

表2に示すレジスタ信号を伝達するために、表1から次のイベントを使用しなければならないSS番号5レジスタシグナリングを運ぶために電話イベントペイロードを使用して実装。

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は、それぞれ、9の数字1を搬送します。

o event code 123 to convey Code 11;

Oイベント・コード123は、コード11を伝達します。

o event code 124 to convey KP1;

KP1を伝達する入出力イベントコード124。

o event code 125 to convey KP2;

Oイベント・コード125は、KP2を搬送します。

o event code 126 to convey ST;

STを伝達する入出力イベントコード126。

o event code 127 to convey Code 12.

コード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信号の初期イベントレポートを送るべきである、と彼らは完了したとして、それはすぐにこれらの信号の全てのイベントレポートを送らなければなりません。

2.2. Signalling System R1 and North American MF
2.2. 信号方式R1と北アメリカのMF

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].

単に「MF」として指定されたより一般的な変異体であるとしてシグナリングシステムR1は主に、北米で使用されています。 MFは、[9]で定義されている間R1は、[6] ITU-T勧告Q.310-Q.332で定義されています。

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番号5のように、R1 / MFラインと登録信号の両方を有しています。ライン信号(BUSYと並べ替え数えない)が2600 Hzのトーンのアプリケーションを介して、デジタルトランク上ABCDシグナリングを使用して、アナログトランクに実装されています。ライン信号の解釈は(SS番号5のように)状態依存です。

2.2.1. Signalling System R1 Line Signals
2.2.1. シグナリングシステムR1ライン信号

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によれば、実装は、R1線信号を伝達するために、表1の第2.4節に記載され、示されるビット・イベントを使用するかもしれません。彼らがそうするならば、彼らは次のマッピングを使用しなければなりません。これらのマッピングは、その信号が存在しないことが示さ方向とA = 1 2600 Hzの信号の存在のためにA = 0を等化根底マッピングに基づいています。

o 2600 Hz present: event code 206;

2600 Hzの存在O:イベントコード206。

o no signal present: event code 207.

イベントコード207:信号なし存在O。

2.2.2. Signalling System R1 Register Signals
2.2.2. 信号方式R1レジスタ信号

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レジスタ信号が「9」を介しKP、ST、および数字「0」から成ります。信号に割り当てられる周波数はKPがSS番号5表KP1に対応する周波数の組み合わせを使用することを除いて、これらの周波数は、同様の名前のSS番号5レジスタ信号に割り当てられたものと同じであることを表3注に示します。 KP 'KP2P、KP3P、STPまたはST'、ST2P、およびST3P [9]:3はまた、北米の実施において使用される追加の信号を示しています。

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:

表3に示すレジスタ信号を伝達するために、表1から次のイベントを使用しなければならない北米R1レジスタシグナリングを運ぶために電話イベントペイロードを使用して実装。

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は、それぞれ、9の数字1を搬送します。

o event code 123 to convey KP3P or ST3P;

KP3P又はST3Pを伝達する入出力イベントコード123。

o event code 124 to convey KP;

KPを伝達する入出力イベントコード124。

o event code 125 to convey KP2P or ST2P;

KP2P又はST2Pを伝達する入出力イベントコード125。

o event code 126 to convey ST;

STを伝達する入出力イベントコード126。

o event code 127 to convey KP' or STP.

KP」またはSTPを伝えるためにOイベントコード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.

元の電話信号と同様に、受信機は、符号123、125を解釈し、シグナリングシーケンスにおけるそれらの位置に基づいKPXまたはSTX信号として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番号5とは異なり、R1は開始ダイヤル線信号の認識以下のレジスタシグナリングの開始時間のために大きな公差を可能にします。これは、KPが完了するまで、送信の実装はKPのイベントレポートを送信するのを待つことを意味します。

2.3. Signalling System R2
2.3. 信号システムR2

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(インター)レジスタ信号は、帯域内、強要、エンド・ツー・エンドマルチ周波数であり、また、関連するチャネル。

2.3.1. Signalling System R2 Line Signals
2.3.1. シグナリングシステム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線信号は、AとBの両方のビットを使用して16チャネルのビット、またはデジタルを使用して1ビットデジタル、アナログであってもよいです。実装は、セクション2.4に記載され、これらの信号を伝播するために、表1に示すビットまたは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.

ITU-T勧告Q.411の表1に示すアナログR2線信号1.以下のように、実装は、マップする必要があります。トーンが存在する場合、このマッピングは、= 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.

デジタルR2ライン信号は、ITU-T勧告Q.421によって記載されているように、2ビットで運ばれる2、AおよびB AとBビット値とイベントコードとの間のマッピングは、両方向で同じでなければならないし、従わなければなりませんAとBのビットマッピングの原理は、セクション2.4で指定されました。

2.3.2. Signalling System R2 Register Signals
2.3.2. 信号方式R2レジスタ信号

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は、グループAおよびBこれらのグループにグループIおよびII、後方MFレジスタ信号(低い周波数)にフォワードMFレジスタ信号(上側の周波数)情報のどのようなに対して両方と有意であると分類します彼らが伝え、どこにシグナリングシーケンスで発生する可能性があります。

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レジスタシグナリングに使用されるトーンは、2〜6のうち周波数の組み合わせです。ナショナル・バージョンは、10の信号(2〜5のうち周波数)または6つの信号(2〜4のうち周波数)に還元することができます。

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勧告で指定された例外的な状況です。 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に示されるように、すなわち、それぞれ、イベントコード176-190および191-205を使用して)順方向15及び15個の後方MF R2トーンを示すための手段を提供します。これらのトーンの周波数対は、表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のレジスタ間の信号の以降リレーのナイーブ戦略は許容できないほど長いコールセットアップ時間及びタイムアウトコールは、いくつかの取引所を通過するだけでなく、終了する前に、ゲートウェイをもたらすことができることに留意されたいです。いくつかの戦略は、与えられた中継点間でシグナリング情報の転送を高速化が可能です。最悪の場合には、中継点は、一方の側にシグナリングを終了し、他のコールをreoriginating、交換として作用しなければなりません。

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後方レジスタシグナル

2.4. ABCD Transitional Signalling for Digital Trunks
2.4. デジタルトランクのABCD移行シグナリング

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ビットのシグナリングシステムです。シグナリングは、(4つのすべての使用されるビット)、4状態(A及びBビット使用)、又は2状態(ビットのみ使用)16状態であってもよいです。 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 A 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勧告で指定されたものと同様、以下の三重の冗長機構を使用する必要があります。 I.366.2 [15]、附属書L.遷移時に、同じABCD情報は、5ミリ秒の間隔で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.ステート番号がビットが高位ビットであり、単一の2進数としてそれらを処理することにより、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.状態数が増加する値の順序によってイベントコードにマップする(イベント・コード144、すなわち、状態番号0マップ、...、状態番号イベントコード159から15のまでのマップ)。

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;

イベントコード208にA = 0、B = 0のマップO。

o A=0, B=1 maps to event code 209;

イベントコード209にA = 0、B = 1つのマップO。

o A=1, B=0 maps to event code 210;

イベントコード210にA = 1、B = 0のマップO。

o A=1, B=1 maps to event code 211;

イベントコード211にA = 1、B = 1つのマップO。

Finally, if only the A bit is used,

最後に、ビットのみが使用されている場合、

o A = 0 maps to event code 206;

イベントコード206にO A = 0のマップ。

o A = 1 maps to event code 207;

イベントコード207にO A = 1つのマップ。

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.

撮影に示されるように、ので、別のイベント・コードはビットおよびABビットシグナリングに割り当てられています。 G.704 [10]、B、C、およびDビットは未使用である場合、そのデフォルト値は、伝送システム間で異なります。のみ使用されるビットのためのコードを指定することで、このメモは、受信側ゲートウェイは、ローカルコンフィギュレーションに応じて残りのビットを記入することを可能にします。

2.5. Continuity Tones
2.5. 継続トーン

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の条項7 [8]単2000 +/- 20 Hzのチェックトーンを開始電話スイッチから送信された四線トランク回路、に該当する手順を記載しています。リモートスイッチは、ループバックを設定し、送信スイッチは、復路のトーンを検出できる場合、連続性チェックが渡されます。 Q.724の箇条8は、2線トランク回路のための手順を説明します。順方向に送信される2000Hzのトーンに応答して送信された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ヘルツの望ましくないエイリアシング特性の、例えば2010ヘルツ、実装は、多くの場合、わずかに異なるチェックトーンを送信することに留意されたいです。

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、2000Hzのチェックトーンは、イベントコード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二線導通試験のために、初期2000HzのチェックトーンHzのトーンがイベントコード121にマッピングされる1780 Hzの連続ベリファイトーンは、イベントコード122にマッピングされます。

2.6. Trunk Unavailable Event
2.6. トランク利用不可イベント

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ミリ秒の間隔で同じタイムスタンプを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遷移イベントを介してトランクコンディショニングを代わりに使用することができます。

2.7. Metering Pulse Event
2.7. 計量パルスイベント

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のセクション2.5.1.4に推奨されているように、計量パルスイベントが再送信されなければならない[4]。再送信間隔は50ミリ秒の低い及びパルスレートが、オーディオパケットのレートを下回らないことが推奨されます。

3. Congestion Considerations
3.輻輳の考慮事項

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.番号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.番号5及びR1 / MFのためのシグナリングレジスタは、時間的な制約を受けます。両方のトーン信号と、それらの間の無音期間は、期間5〜10ミリ秒のオーダーの許容誤差を指定しています。個々のトーンの持続時間は2~3パケット化間隔(初期KPが100ms続くと68分の55ミリ秒)のオーダーです。テレフォニーイベントペイロードを伝送するための重要な要件は、受信機が与えられた瞬間に出てプレーする信号かを知っているということです。受信機は、各トーンの終わりのタイムリーな通知を受け取ることがそれほど重要ではありません。むしろ、それは代わりに報告された実際の期間の信号規格で指定された期間でシーケンスを再生する必要があります。

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つの信頼性のためのMSとこれ以上の更新内の更新を提供しなければなりません。

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.

レジスタシグナリングの間に受信機で再生バッファを大きくすると、信頼性が向上します。これは、呼設定時における暗黙の増加を比較考量する必要があります。

4. Security Considerations
4.セキュリティについての考慮事項

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;

メッセージの挿入またはメッセージのman-in-the-middle修飾を介して電話接続の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]。

5. IANA Considerations
5. IANAの考慮事項

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.

この文書では、これらのイベントは、RFC 4733 [4]によって確立された電話イベントのレジストリに追加され、表6に示すイベントコードを定義します。それらのすべての参照が存在文書です。

   +------------+-----------------------------------------+-----------+
   | 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シグナリング状態 '0011' | [RFC5244] | | | | | | 148 | ABCDシグナリング状態 '0100' | [RFC5244] | | | | | | 149 | ABCDシグナリング状態 '0101' | [RFC5244] | | | | | | 150 | ABCDシグナリング状態 '0110' | [RFC5244] | | | | | | 151 | ABCDシグナリング状態 '0111' | [RFC5244] | | | | | | 152 | ABCDシグナリング状態 '1000' | [RFC5244] | | | | | | 153 | ABCDシグナリング状態 '1001' | [RFC5244] | | | | | | 154 | ABCDシグナリング状態 '1010' | [RFC5244] | | | | | | 155 | ABCDシグナリング状態 '1011' | [RFC5244] | | | | | | 156 | ABCDシグナリング状態 '1100' | [RFC5244] | | | | | | 157 | ABCDシグナリング状態 '1101' | [RFC5244] | | | | | | 158 | ABCDシグナリング状態 '1110' | [RFC5244] | | | | | | 159 | ABCDシグナリング状態 '1111' | [RFC5244] | | | | | | 174 |計量パルス| [RFC5244] | | | | | | 175 |トランク利用できません| [RFC5244] | | | | | | 176 | MFCフォワード信号1 | [RFC5244] | | | | | | 177 | MFCフォワード信号2 | [RFC5244] | | | | | | 178 | MFCフォワード信号3 | [RFC5244] | | | | | | 179 | MFCフォワード信号4 | [RFC5244] | | | | | | 180 | MFCフォワード信号5 | [RFC5244] | | | | | | 181 | MFCフォワード信号6 | [RFC5244] | | | | | | 182 | MFCフォワード信号7 | [RFC5244] | | | | | | 183 | MFCフォワード信号8 | [RFC5244] | | | | | | 184 | MFCフォワード信号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フォワード信号10 | [RFC5244] | | | | | | 186 | MFCフォワード信号11 | [RFC5244] | | | | | | 187 | MFCフォワード信号12 | [RFC5244] | | | | | | 188 | MFCフォワード信号13 | [RFC5244] | | | | | | 189 | MFCフォワード信号14 | [RFC5244] | | | | | | 190 | MFCフォワード信号15 | [RFC5244] | | | | | | 191 | MFC逆方向信号1 | [RFC5244] | | | | | | 192 | MFC逆方向信号2 | [RFC5244] | | | | | | 193 | MFC逆方向信号3 | [RFC5244] | | | | | | 194 | MFC逆方向信号4 | [RFC5244] | | | | | | 195 | MFC逆方向信号5 | [RFC5244] | | | | | | 196 | MFC逆方向信号6 | [RFC5244] | | | | | | 197 | MFC逆方向信号7 | [RFC5244] | | | | | | 198 | MFC逆方向信号8 | [RFC5244] | | | | | | 199 | MFC逆方向信号9 | [RFC5244] | | | | | | 200 | MFC逆方向信号10 | [RFC5244] | | | | | | 201 | MFC逆方向信号11 | [RFC5244] | | | | | | 202 | MFC逆方向信号12 | [RFC5244] | | | | | | 203 | MFC逆方向信号13 | [RFC5244] | | | | | | 204 | MFC逆方向信号14 | [RFC5244] | | | | | | 205 | MFC逆方向信号15 | [RFC5244] | | | | | | 206 |状態を知らせるビット「0」| [RFC5244] | | | | | | 207 |ビットのシグナリング状態「1」| [RFC5244] | | | | | | 208 | ABビットのシグナリング状態「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. Acknowledgements
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]。エディタは信じているか、次の人は具体的には、本文書に貢献していることを認識している:フレミングAndreasenの、レックスColdren、ビル・フォスター、アルフレッドHoenes、ラジェッシュクマー、アレクLEBL、Zarkoマルコフ、オレンペレグ、モシェSamoha、エイドリアンSoncodi、およびYaakovのスタイン。スティーブNorreysとロニはさえ有益なレビューコメントを提供しました。

7. References
7.参考
7.1. Normative References
7.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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.、フレデリック、R.、およびV.ヤコブソン、 "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.、マグリュー、D.、Naslund、M.、カララ、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.テイラーを、 "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]国際電気通信連合、ITU-T勧告Q.140-Q.180、1988年11月の "システムがない。5に信号を送るための仕様"。

[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]国際電気通信連合は、ITU-T勧告G.704、1998年10月 "同期フレーム構造は、1544、6312、2048、8448と44 736キロビット/秒の階層レベルで使用されます"。

7.2. Informative References
7.2. 参考文献

[11] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.

[11] Schulzrinneと、H.およびS. 2000 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.

、BCP 72、RFC 3552、2003年7月[12]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"。

[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キロビット/秒で送信するマルチメディア通信のレート音声コーダ」、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]国際電気通信連合、 "8キロビットにおける音声の符号化/使用sの共役構造代数符号励振線形予測(CS-ACELP)"、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アムステルダムAvenueニューヨークのヘニングSchulzrinneとコロンビアU.部長、NY 10027米国

EMail: schulzrinne@cs.columbia.edu

メールアドレス:schulzrinne@cs.columbia.edu

Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 CA

トムテイラーノーテル1852ロレーヌアヴェオタワ、オンタリオK1H 6Z8 CA

EMail: tom.taylor@rogers.com

メールアドレス: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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。