RFC5244 日本語訳
5244 Definition of Events for Channel-Oriented Telephony Signalling.H. Schulzrinne, T. Taylor. June 2008. (Format: TXT=55321 bytes) (Updates RFC4733) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 5244 Columbia U.
Updates: 4733 T. Taylor
Category: Standards Track Nortel
June 2008
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 5244のコロンビアU.アップデート: 4733年のT.テイラーカテゴリ: 標準化過程ノーテル2008年6月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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ペイロードで運ばれるとチャンネルで関連している合図に使用される電話信号のためにイベントコードを加えるためにRFC4733をアップデートします。 それは、このためにRFC2833のセクション3.14のイベントコードのオリジナルの課題と取って代わって、一助となります。 RFC4733のAppendix Aに記録されるように、それらの仕様があいまいであるか、誤る、または余分であったので、2833年のRFC出来事のいくつかが非難されました。 事実上、RFC2833のセクション3.14からの変化の度合いは現在のドキュメントの実現が完全に後方に完全なABCD-ビット合図の場合だけにおけるRFC2833実現と互換性があった状態でなるようにものです。 RFC2833と比べて、このドキュメントは、合図システムのサービスエリアを広げて、改良します。
Schulzrinne & Taylor Standards Track [Page 1] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[1ページ]。
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。 序論…2 1.1. 概観…2 1.2. 用語…3 2. イベント定義…4 2.1. 合図システムNo.5…6 2.1.1. 合図システムNo.5線は合図します…6 2.1.2. 合図システムNo.5は信号を登録します…7 2.2. システムR1と北米のmfに合図します…8 2.2.1. 合図システムR1線は合図します…8 2.2.2. 合図システムR1は信号を登録します…8 2.3. システムR2に合図します…10 2.3.1. 合図システムR2線は合図します…10 2.3.2. 合図システムR2は信号を登録します…10 2.4. デジタルトランクスのためのABCDの過渡的な合図…12 2.5. 連続は調子を変えます…14 2.6. トランクの入手できない出来事…14 2.7. パルス出来事を計量します…15 3. 混雑問題…15 4. セキュリティ問題…16 5. IANA問題…17 6. 承認…20 7. 参照…20 7.1. 標準の参照…20 7.2. 有益な参照…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.
このドキュメントはサーキットの上に電話網に現れることができる出来事に合図するのを含むようにRFC4733[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のトランクス(または、サーキット)は電話スイッチの間のメディア経路です。 それらを使用することで通話をセットアップするのに個々のトランクスに関するトーンと電気状態を使用することでプロトコルの継承を開発してあります。 本書では定義された出来事はそのようなPSTN合図がIPネットワークで合図されないで2門の間まで運ばれるアプリケーションを支持します: 「RTPトランク」アプリケーション。
In the "RTP trunk" application, RTP is used to replace a normal circuit-switched trunk between two nodes. This is particularly of interest in a telephone network that is still mostly circuit-switched. In this case, each end of the RTP trunk encodes
「RTPトランク」アプリケーションでは、RTPは、2つのノードの間で正常なサーキットで切り換えられたトランクを取り替えるのに使用されます。 これは特にサーキットによってまだほとんど切り換えられた電話網におもしろいです。 この場合RTPトランクエンコードの各端
Schulzrinne & Taylor Standards Track [Page 2] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[2ページ]。
audio channels into the appropriate encoding, such as G.723.1 [13] or
G.729 [14]. However, this encoding process destroys in-band
signalling information that is carried using the least-significant
bit ("robbed bit signalling") and may also interfere with in-band
signalling tones, such as the MF (multi-frequency) digit tones.
オーディオはG.723.1[13]やG.729[14]のように適切なコード化に向けられます。 しかしながら、このコード化の過程は、バンドにおける最下位ビット(「噛み付いている合図から、略奪する」)を使用することで運ばれる合図情報を無効にして、また、バンドにおける合図トーンを妨げるかもしれません、MF(多重周波数)ケタトーンなどのように。
In a typical application, the gateways may exchange roles from one call to the next: they must be capable of either sending or receiving each implemented signal in Table 1.
主用途では、ゲートウェイは1つの呼び出しから次まで役割を交換するかもしれません: Table1のそれぞれの実行された信号を送らなければならないか、または彼らは受信できなければなりません。
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.
作成者は以下に与えられた合図システムの記述が不完全であるのに注意されます。 関連するイベント定義に文脈を与えるためにそれらを提供しますが、実現に重要な多くの詳細を省略してください。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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
第始め
Schulzrinne & Taylor Standards Track [Page 3] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[3ページ]。
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は本書では定義された出来事のすべてを記載します。 RFC4733[4]のTable8(付録A)にみられるように、それらの仕様があいまいであるか、誤る、または余分であったので、RFC2833[11]イベントコードのいくつかの使用は非難されました。 事実上、RFC2833のセクション3.14からの変化の度合いは現在のドキュメントの実現が完全に後方に完全なABCD-ビット合図の場合だけにおけるRFC2833実現と互換性があった状態でなるようにものです。 RFC2833と比べて、このドキュメントは、合図システムのサービスエリアを広げて、改良します。
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登録がRFC2833ではなく、RFC4733によってセットアップされたことに注意してください。 したがって、RFC4733かアップデートでRFC4733に再び断言される場合にだけ、元々RFC2833でされたイベントコード課題は登録に現れます、現在のドキュメントなどのように。
Schulzrinne & Taylor Standards Track [Page 4] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[4ページ]。
+---------------------+------------+-------------+--------+---------+ | 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 | +---------------------+------------+-------------+--------+---------+
+---------------------+------------+-------------+--------+---------+ | 出来事| 頻度| イベントコード| 出来事| ボリューム? | | | (Hz) | | タイプ| | +---------------------+------------+-------------+--------+---------+ | mf0…9 | (テーブル2) | 128...137 | トーン| はい| | | | | | | | MF Code11(SS No.| 700+1700|123|トーン| はい| | 5)かKP3P/ST3P| | | | | | (R1) | | | | | | | | | | | | またはmf KP(SS No.5)。| 1100+1700 | 124 | トーン| はい| | KP1(R1)| | | | | | | | | | | | mf KP2(SS No.5)| 1300+1700 | 125 | トーン| はい| | または、KP2P/ST2P(R1)| | | | | | | | | | | | MF ST(| 1500年の+1700|126|トーン| はい| | SS No.5とR1)| | | | | | | | | | | | 'MF Code、12 (SS No.|、900、+1700、| 127|トーン|はい| | 5か)KP'/STP(R1)| | | | | | | | | | | | ABCD合図| なし| 144...159 | 状態| いいえ| | | | | | | | AB合図、(C、D| N/1|208...211| 状態| いいえ|、|、未使用、)| | | | | | | | | | | | 少し合図しています。| なし| 206...207 | 状態| いいえ| | (Cの、そして、D未使用のB) | | | | | | | | | | | | 連続| 2000 | 121 | トーン| はい| | チェックトーン| | | | | | | | | | | | 連続| 1780 | 122 | トーン| はい| | トーンについて確かめます。| | | | | | | | | | | | 計量パルス| なし| 174 | 他| いいえ| | | | | | | | 入手できないトランク| なし| 175 | 他| いいえ| | | | | | | | MFCは1を進めます…15 | (テーブル4) | 176...190 | トーン| はい| | | | | | | | MFCの後方の1…15 | (テーブル5) | 191...205 | トーン| はい| +---------------------+------------+-------------+--------+---------+
Table 1: Trunk Signalling Events
テーブル1: トランク合図出来事
Schulzrinne & Taylor Standards Track [Page 5] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[5ページ]。
2.1. Signalling System No. 5
2.1. 合図システムNo.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.
合図System No.5(SS No.5)はQ.180[5]を通してITU-T Recommendations Q.140で定義されます。 それには、信号の2台のシステムがあります: 1個のスイッチから次までケタを前方へパスするためにトランクを入手して、解放して、合図を「登録する」と合図する「線。」
2.1.1. Signalling System No. 5 Line Signals
2.1.1. 合図システムNo.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.
No.5線合図は2つの頻度でトーンを使用します: 2400と2600Hz。 トーンは、ほとんどの信号に単独で使用されて、Clear-フォワードとRelease-護衛にとって、一緒にいます。 (これは頻度の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線合図を支持して定義されません。 しかしながら、実現はSS No.5線信号を伝播するためにセクション2.4で説明されて、Table1に示されたABの噛み付いている出来事を使用するかもしれません。 彼らがそうするなら、彼らは以下のマッピングを使用しなければなりません。 これらのマッピングは2400Hzの信号の存在とA=0を同一視する基本的なマッピングに基づいています、そして、2600Hzの存在へのB=0は示された方向に合図します。
o both 2400 and 2600 Hz present: event code 208;
o 2400と2600Hzの両方が以下を提示します。 イベントコード208。
o 2400 Hz present: event code 210;
o 現在の2400Hz: イベントコード210。
o 2600 Hz present: event code 209;
o 現在の2600Hz: イベントコード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.
信号が同じくらいすぐ、発生していますが、それぞれの信号SHOULDがそう、およびどのような場合でも、ITU-T Recommendation Q.141、Table1にみられるように認識の時間までに初期のイベントレポート(すなわち、他のすべての信号のための「止まり」と「発信しかけてください」、125msのための40ms)。 初期に続くpacketization間隔は、SHOULDが最優先を与える信頼できるトランスミッションの問題で選ばれていると報告します。 受信機がトーンへのこれらの出来事を変換するのにそれ自身のボリューム値を供給しなければならないことに注意してください。 そのうえ、受信機はKP出来事の最初のレポートを受け取るまで(以下を見てください)「止まり」である再生を広げるかもしれません、差押え信号の結末とKP再生の始まりの間に間隔の、より良いコントロールを持つように。
The KP has to be sent beginning 80 +/- 20 ms after the SS No. 5
"seizing" signal has stopped.
SS No.5「差押え」信号が止まった後に始め80の+/-20msをKPに送らなければなりません。
Schulzrinne & Taylor Standards Track [Page 6] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[6ページ]。
2.1.2. Signalling System No. 5 Register Signals
2.1.2. 合図システムNo.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.
No.5レジスタ合図は、それらを縁どるケタと信号を伝えるのに組のトーンを使用します。 トーン組み合わせと対応する信号はTable2で見せられます。 KP1とKP2以外のすべての信号は55の持続時間のために送って、いつもくぎりが55であるという100原稿Inter-信号原稿の持続時間のために原稿KP1とKP2を送るということです。
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 | +-----------------+---------+---------+---------+---------+---------+
+-----------------+---------+---------+---------+---------+---------+ | 下側の頻度| 900 | 1100 | 1300 | 1500 | 1700 | | (Hz) | | | | | | +-----------------+---------+---------+---------+---------+---------+ | 700 | ケタ1| ケタ2| ケタ4| ケタ7| コード11| | | | | | | | | 900 | | ケタ3| ケタ5| ケタ8| コード12| | | | | | | | | 1100 | | | ケタ6| ケタ9| KP1| | | | | | | | | 1300 | | | | ケタ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信号によって示されます。 国名略号(ことによるともう1ケタ)に続くコード11かCode12が目的地国のオペレータ位置に向けられるという要求を示します。 指示されている呼び出しがことである特定のオペレータを示す他のケタはCode12のあとに続くかもしれません。
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 No.5レジスタ合図を運ぶのに電話イベントペイロードを使用する実現はTable2で見せられたレジスタ信号を伝えるのにTable1からの以下の出来事を使用しなければなりません:
o event code 128 to convey Digit 0;
o 出来事はDigit0を運ぶために128をコード化します。
o event codes 129-137 to convey Digits 1 through 9, respectively;
o 出来事は1〜9に、それぞれDigitsを運ぶために129-137をコード化します。
o event code 123 to convey Code 11;
o 出来事はCode11を運ぶために123をコード化します。
Schulzrinne & Taylor Standards Track [Page 7] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[7ページ]。
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 出来事は、Code12を運ぶために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.
完成されて、それらが認識されて、送るとすぐに、これらの信号のすべてのためのイベントレポートを送らなければならないとすぐに、SHOULDが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].
合図System R1は単に「mf」として指定されたより一般的な異形のように北アメリカで主に使用されます。 R1はITU-T Recommendations 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は両方が信号を裏打ちして、登録するのをさせます。 線信号(BusyとReorderを数えない)は2600Hzのトーンの適用によるアナログのトランクスの上と、そして、ABCD合図を使用するのによるデジタルトランクスの上に実行されます。 線信号の解釈は州の依存しています(SS No.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.
Table1/Q.311によると、実現はR1線信号を伝播するためにセクション2.4で説明されて、Table1に示されたA噛み付いている出来事を使用するかもしれません。 彼らがそうするなら、彼らは以下のマッピングを使用しなければなりません。 これらのマッピングはその信号の欠如への示された指示とA=1での2600Hzの信号の存在とA=0を同一視する基本的なマッピングに基づいています。
o 2600 Hz present: event code 206;
o 現在の2600Hz: イベントコード206。
o no signal present: event code 207.
o 信号プレゼントがありません: イベントコード207。
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
R1には、前進の相互レジスタ信号のための15のコードの信号容量がありますが、後方では、信号は相互登録されません。 各コードかケタがトーン組によって1セットの6頻度から伝えられます。 R1レジスタ信号がKP、ST、およびケタから成る、「「9インチ」を通した0インチ 信号に割り当てられた頻度はTable3に示されます。 注意
Schulzrinne & Taylor Standards Track [Page 8] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[8ページ]。
that these frequencies are the same as those allotted to the similarly named SS No. 5 register signals, except that KP uses the frequency combination corresponding to KP1 in SS No. 5. Table 3 also shows additional signals used in North American practice: KP', KP2P, KP3P, STP or ST', ST2P, and ST3P [9].
同様に命名されたSS No.5に割り当てられたものが信号を登録するそのKPを除いて、これらの頻度が同じであることがSS No.5でKP1に対応する頻度組み合わせを使用します。 また、テーブル3は実際には北米の使用される追加信号を見せています: または、'KP'、KP2P、KP3P、STP、第'、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 | +------------+---------+---------+---------+---------+--------------+
+------------+---------+---------+---------+---------+--------------+ | 下ろしてください。| 900 | 1100 | 1300 | 1500 | 1700 | | 頻度| | | | | | | (Hz) | | | | | | +------------+---------+---------+---------+---------+--------------+ | 700 | ケタ1| ケタ2| ケタ4| ケタ7| KP3PかST3P| | | | | | | | | 900 | | ケタ3| ケタ5| ケタ8| 'KP'かSTP| | | | | | | | | 1100 | | | ケタ6| ケタ9| KP| | | | | | | | | 1300 | | | | ケタ0| KP2Pか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レジスタ合図を運ぶのに電話イベントペイロードを使用する実現はTable3で見せられたレジスタ信号を伝えるのにTable1からの以下の出来事を使用しなければなりません:
o event code 128 to convey Digit 0;
o 出来事はDigit0を運ぶために128をコード化します。
o event codes 129-137 to convey Digits 1 through 9, respectively;
o 出来事は1〜9に、それぞれDigitsを運ぶために129-137をコード化します。
o event code 123 to convey KP3P or ST3P;
o イベントコードのKP3Pを運ぶ123かST3P。
o event code 124 to convey KP;
o 出来事はKPを運ぶために124をコード化します。
o event code 125 to convey KP2P or ST2P;
o イベントコードのKP2Pを運ぶ125かST2P。
o event code 126 to convey ST;
o 出来事はSTを運ぶために126をコード化します。
o event code 127 to convey KP' or STP.
o '出来事はKPを運ぶために127をコード化する'か、STP。
As with the original telephony signals, the receiver interprets
codes 123, 125, and 127 as KPx or STx signals based on their
position in the signalling sequence.
オリジナルの電話信号のように、KPxかSTxが合図系列の彼らの見解に基づいて合図するように受信機はコード123、125、および127を解釈します。
Schulzrinne & Taylor Standards Track [Page 9] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[9ページ]。
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イベントレポートを待つかもしれないその発信を意味します。
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.
国際Signalling System R2はITU-T Recommendations 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はアナログ、第16代チャンネルでAが噛み付いた1ビットのデジタル使用、または使用のデジタル両方がAとBビットであったかもしれないなら信号を裏打ちします。 実現がAビットを使用するかもしれませんか、またはABはセクション2.4で説明されて、これらの信号を伝播するためにTable1に示された出来事に噛み付きました。 彼らがそうするなら、彼らは以下のマッピングを使用しなければなりません。
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 Recommendation Q.411のTable1で見せられたアナログのR2線信号に関しては、実現は以下の通り写像されなければなりません。 トーンが存在しているとき、このマッピングはAビット=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.
* 状態がQ.411で「調子を変えること」を示すのにおいてイベントコード207(テーブル1)は使用されています。
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 Recommendation Q.421によって説明されるデジタルR2線信号はB. 2ビット、A、およびAとBとの間にビットが評価するマッピングで運ばれました、そして、出来事は両方の同じくらいが指示であったならSHALLをコード化します、そして、SHALLは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
R2合図では、合図系列は、仕向為替から線「差押え」信号を送ることによって、開始されます。 線「差押え」信号(そして、R2Dの「差押え承認」信号)の後に、合図系列は、MFレジスタ信号を使用し続けています。 ITU-T Recommendation Q.441は前進のMFレジスタ信号を分類します。
Schulzrinne & Taylor Standards Track [Page 10] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[10ページ]。
(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.
(上側の頻度) Groupsへの私とII、後方のMFは信号(下側の頻度)をGroups Aに登録して、B.Theseグループは敬意によって彼らがどういう情報を伝えるか、そして、どこに合図系列で起こることができるかに重要です。
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の前進のレジスタ信号は後方の信号によって承認されます。 後方の信号は前進の信号の端までに承認されます。 例外的な事情では、Recは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合図では、合図系列は、仕向為替から私が合図するGroupを考慮させるために送ることによって、開始されます。 通常、最初の前進の信号は呼ばれた数の最初のケタです。 後方のGroup A-1が呼ばれた数の次のケタに発信するために仕向為替に示していて、被仕向為替は通常返答します。
The tones have meaning; however, the meaning varies depending on where the tone occurs in the signalling. The meaning may also depend on the country. Thus, to avoid an unmanageable number of events, this document simply provides means to indicate the 15 forward and 15 backward MF R2 tones (i.e., using event codes 176-190 and 191-205, respectively, as shown in Table 1). The frequency pairs for these tones are shown in Table 4 and Table 5.
トーンに、意味があります。 しかしながら、トーンが合図で起こるところによって、意味は異なります。 また、意味は国に頼るかもしれません。 したがって、「非-処理しやす」数の出来事を避けるために、このドキュメントは単に、前方に15を示す手段と15の後方のMF R2トーン(すなわち、Table1に示されるように176-190に191-205にそれぞれイベントコードを使用する)を提供します。 これらのトーンのための頻度組はTable4とTable5で見せられます。
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相互レジスタ信号の前方のリレーのためのナイーブな戦略がロングコールセットアップ回数とタイムアウトを容認できないほどもたらすかもしれないことに注意してください。 与えられたリレーポイントのの向こう側に合図情報の転送を早くするのについて、いくつかの戦略があります。 最悪の場合には、リレーポイントは交換として機能しなければなりません、半面で合図を終えて、もう片方で呼び出しを再由来して。
Schulzrinne & Taylor Standards Track [Page 11] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[11ページ]。
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 |
+----------------------+-------+-------+-------+--------+--------+
+----------------------+-------+-------+-------+--------+--------+ | 下側の頻度(Hz)| 1500 | 1620 | 1740 | 1860 | 1980 | +----------------------+-------+-------+-------+--------+--------+ | 1380 | Fwd1| Fwd2| Fwd4| Fwd7| Fwd11| | | | | | | | | 1500 | | Fwd3| Fwd5| Fwd8| Fwd12| | | | | | | | | 1620 | | | Fwd6| Fwd9| Fwd13| | | | | | | | | 1740 | | | | Fwd10| Fwd14| | | | | | | | | 1860 | | | | | Fwd15| +----------------------+-------+-------+-------+--------+--------+
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 | +-----------------+---------+---------+---------+---------+---------+
+-----------------+---------+---------+---------+---------+---------+ | 下側の頻度| 1140 | 1020 | 900 | 780 | 660 | | (Hz) | | | | | | +-----------------+---------+---------+---------+---------+---------+ | 1020 | Bkwd1| | | | | | | | | | | | | 900 | Bkwd2| Bkwd3| | | | | | | | | | | | 780 | Bkwd4| Bkwd5| Bkwd6| | | | | | | | | | | 660 | Bkwd7| Bkwd8| Bkwd9| Bkwd10| | | | | | | | | | 540 | Bkwd11| Bkwd12| Bkwd13| Bkwd14| Bkwd15| +-----------------+---------+---------+---------+---------+---------+
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ビットの合図システムです。 合図は、16州(4ビットが使用したすべて)、4州(中古さビットのAとB)、または2州であるかもしれません(少し使用されるだけです)。 ABCD合図出来事はすべて互いに唯一の州です。 最新の状態遷移は現状を決定します。
Schulzrinne & Taylor Standards Track [Page 12] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[12ページ]。
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.
Extended Super Frame(ESF)T1縁どりを使用するとき、略奪されたビットとしてフレーム6、12、18、および24で合図情報を送ります。 D4 superframeは、AとBビットで合図しながら、4州しか伝えません。 1ヨーロッパのPostalとTelecommunications(CEPT)Eのフレームのコンファレンスでは、timeslot16ですべての合図を運びます、そして、フレーム単位で16州(ABCD)の合図の2個のチャンネルを送ります。 ITU-T Recommendation 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]です。(その[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情報が変化信号よりむしろ状態であるので、実現SHOULDは以下の三重の冗長メカニズムを使用します、ITU-T Recで指定されたものと同様です。 I.366.2[15]、変遷の時に同じABCD情報が3回別の変遷が今回起こる5原稿Ifの間隔を置いて送られるAnnex L.At、そして、これは続きます。 変化がない期間の後に、5秒毎にABCD情報を送ります。
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:
Table1に示されるように、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. 1つの2進の数としてそれらを扱うのによるABCDビットの中古の部分集合から州の番号を得ます。(そこでは、Aビットが高位のビットです)。
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. 価値を増す注文で数の地図をイベントコードに述べてください(… すなわち、No.0地図をイベントコード144に述べてください、そして、No.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、イベントコード208へのB=0地図。
o A=0, B=1 maps to event code 209;
o A=0、イベントコード209へのB=1地図。
o A=1, B=0 maps to event code 210;
o A=1、イベントコード210へのB=0地図。
o A=1, B=1 maps to event code 211;
o A=1、イベントコード211へのB=1地図。
Schulzrinne & Taylor Standards Track [Page 13] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[13ページ]。
Finally, if only the A bit is used,
最終的に、Aビットが使用されてさえいる場合、よかったでしょう。
o A = 0 maps to event code 206;
o =0はコード206を出来事に写像します。
o A = 1 maps to event code 207;
o =1はコード207を出来事に写像します。
Separate event codes are assigned to A-bit and AB-bit signalling
because, as indicated in Rec. G.704 [10], when the B, C, and D
bits are unused, their default values differ between transmission
systems. By specifying codes for only the used bits, this memo
allows the receiving gateway to fill in the remaining bits
according to local configuration.
別々のイベントコードがA-ビットとAB-ビット合図に割り当てられる、Recにみられるように。 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.
連続トーンはテスト回路の連続性に呼び出しセットアップの間、使用されます。 2つの基本的な手順が使用されています。 実際には、国際的なITU-T Recommendation Q.724[8]の7番目の節は4線式トランクサーキットに適切な手順について説明します。そこでは、2000年の+/- 20Hzのただ一つのチェックトーンが開始している電話スイッチから伝えられます。 リモート・スイッチはループバックをセットアップします、そして、送付スイッチがリターンパスのトーンを検出できるなら、連続チェックは終わります。 Q.724の第8節は2線式のトランクサーキットに手順について説明します。 2線式の手順は2つのトーンを伴います: 2000Hzのトーンは順方向を送りました、そして、+/- 1780年の20Hzのトーンは応答を送りました。
Note that implementations often send a slightly different check-tone, e.g., 2010 Hz, because of undesirable aliasing properties of 2000 Hz.
実現が2000Hzの望ましくないエイリアシングの特性のためにしばしばわずかに異なったチェックトーン、例えば、2010Hz発信することに注意してください。
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線式連続テストにおいて、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 2線式の連続テストにおいて、チェックトーンHzが調子を変えさせる初期の2000Hzはイベントコード121に写像されます。 1780Hzの連続、トーンについて確かめる、イベントコード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
この出来事は、トランクがサービスを入手できないのを示します。 休止時間の長さは持続時間分野で示されます。 持続時間分野は休止時間について説明する際に適切な粒状を許容する値に設定されます。 1秒の値はRECOMMENDEDです。 いつ
Schulzrinne & Taylor Standards Track [Page 14] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[14ページ]。
trunk becomes unavailable, this event is sent with the same timestamp three times at an interval of 20 ms. If the trunk persists in the unavailable state at the end of the indicated duration, then the event is retransmitted, preferably with the same redundancy scheme.
トランクは入手できなくなって、この出来事は同じタイムスタンプと共に20の間隔を置いて3回送って、トランクが固持する原稿Ifは、示された持続時間の終わりに入手できなさに次に、出来事が再送されると述べます、望ましくは同じ冗長計画でことです。
Unavailability of the trunk might result from a failure or an administrative action. This event is used in a stateless manner to synchronize trunk unavailability between equipment connected through provisioned RTP trunks. It avoids the unnecessary consumption of bandwidth in sending a continuous stream of RTP packets with a fixed payload for the duration of the downtime, as would be required in certain E1-based applications. In T1-based applications, trunk conditioning via the ABCD transitional events can be used instead.
トランクの使用不能は失敗か管理動作から生じるかもしれません。 この出来事は、食糧を供給されたRTPトランクスを通して接続された設備の間のトランク使用不能を同期させるのに国がない方法で使用されます。 それは休止時間の持続時間のために固定ペイロードでRTPパケットの連続した流れを送る際に帯域幅の不要な消費を避けます、あるE1ベースのアプリケーションで必要であるように。 T1ベースのアプリケーションでは、代わりにABCDの過渡的な出来事を通したトランク調節を使用できます。
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.
計量パルス出来事は、支払い目的のためのメーターの脈打つことを伝えるのに使用されるかもしれません。 基礎的な情報に関しては、1つの可能な参照箇所が http://www.seg.co.uk/telecomm/automat3.htm です。 計量パルスが離散事象であるので、それぞれの計量パルスイベントレポートで、両方の'M'と'E'ビットを設定しなければなりません。 会話は進行していますが、メーターの脈打つのはバンドの外による通常、伝えられた手段です。 したがって、Sendersは同時に電話出来事とオーディオペイロードタイプの両方を伝える用意ができていなければなりません。 出来事を再送しなければならない計量パルスはセクション2.5.1で.4RFC4733[4]を推薦しました。 msと脈打つレートにもかかわらず、少なくともオーディオpacketizationが評定する50で再送信間隔が、より少ないのは、RECOMMENDEDです。
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.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
S.S.No.5とR1/MFのためのレジスタ合図は時間規制を受けることがあります。 トーン信号とそれらの間の沈黙期の両方が個々のトーンの持続時間が2の注文のものである5〜10原稿の注文の持続時間と寛容を指定しました。
Schulzrinne & Taylor Standards Track [Page 15] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[15ページ]。
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.
3回のpacketization間隔(初期のKPが100msを持続している55/68ms)。 電話イベントペイロードのトランスミッションのための批判的な要件は受信機が、与えられた瞬間にどの信号を展開したらよいかを知っているということです。 受信機がそれぞれのトーンの終わりのタイムリーな通知を受け取るのは、それほど重要ではありません。 むしろ、持続時間がの代わりにする合図規格によって指定されている状態で、それは系列を展開するべきです。
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.
これらの問題は、レジスタ信号が確かに特定されるとすぐに、送付者がそのトーンのレポートを放つべきであると示唆します。 次に、それは5msの中でアップデートを信頼性に提供するべきです、そして、それ以上の報告するまでのアップデートはトーンの終わりを提供しません。
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:
イベントコードが提供される出来事は本書では直接通話のセットアップ、支払い、および分解に関連します。 コミュニケーションとシステムセキュリティの両方への脅威にRFC3552[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.
適切な秘密性、認証、または保全保護の使用でこれらの攻撃を防ぐことができます。 秘密性、認証、または保全保護が必要であるなら、Secureは[3] Transportプロトコル(SRTP)SHOULDをレアルで調節します。自動化されたかぎ管理で、使用されてください。
Additional security considerations are described in RFC 4733 [4].
追加担保問題はRFC4733[4]で説明されます。
Schulzrinne & Taylor Standards Track [Page 16] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[16ページ]。
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.
このドキュメントはTable6に示されたイベントコードを定義します。 これらの出来事はRFC4733[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] |
+------------+-----------------------------------------+-----------+ | イベントコード| イベント名| 参照| +------------+-----------------------------------------+-----------+ | 121 | 連続チェックトーン| [RFC5244]| | | | | | 122 | 連続、トーンについて確かめます。| [RFC5244]| | | | | | 123 | mfコード11(SS No.5)かKP3P/ST3P(R1)| [RFC5244]| | | | | | 124 | mf KP(SS No.5)かKP1(R1)| [RFC5244]| | | | | | 125 | mf KP2(SS No.5)かKP2P/ST2P(R1)| [RFC5244]| | | | | | 126 | mf、第(SS No.5とR1)| [RFC5244]| | | | | | 127 | 'mfコード12(SS No.5)かKP'/STP(R1)| [RFC5244]| | | | | | 128 | SS No.5かR1ケタ「0インチ」| [RFC5244]| | | | | | 129 | SS No.5かR1ケタ「1インチ」| [RFC5244]| | | | | | 130 | SS No.5かR1ケタ「2インチ」| [RFC5244]| | | | | | 131 | SS No.5かR1ケタ「3インチ」| [RFC5244]| | | | | | 132 | SS No.5かR1ケタ「4インチ」| [RFC5244]| | | | | | 133 | SS No.5かR1ケタ「5インチ」| [RFC5244]| | | | | | 134 | SS No.5かR1ケタ「6インチ」| [RFC5244]| | | | | | 135 | SS No.5かR1ケタ「7インチ」| [RFC5244]| | | | | | 136 | SS No.5かR1ケタ「8インチ」| [RFC5244]| | | | | | 137 | SS No.5かR1ケタ「9インチ」| [RFC5244]| | | | | | 144 | ABCD合図状態'0000'| [RFC5244]| | | | | | 145 | ABCD合図状態'0001'| [RFC5244]| | | | | | 146 | 'ABCD合図は0010年を述べます'| [RFC5244]|
Schulzrinne & Taylor Standards Track [Page 17] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[17ページ]。
| | | | | 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]|
Schulzrinne & Taylor Standards Track [Page 18] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[18ページ]。
| | | | | 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]|
Schulzrinne & Taylor Standards Track [Page 19] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[19ページ]。
| | | | | 209 | AB bit signalling state '01' | [RFC5244] | | | | | | 210 | AB bit signalling state '10' | [RFC5244] | | | | | | 211 | AB bit signalling state '11' | [RFC5244] | +------------+-----------------------------------------+-----------+
| | | | | 209 | ABは合図状態'01'に噛み付きました。| [RFC5244]| | | | | | 210 | 'ABの噛み付いている合図は10年を述べます'| [RFC5244]| | | | | | 211 | 'ABの噛み付いている合図は11年を述べます'| [RFC5244]| +------------+-----------------------------------------+-----------+
Table 6: Channel-Oriented Signalling Events in the
Audio/Telephone-Event Event Code Registry
テーブル6: 電話オーディオ/イベントイベントコード登録のチャンネル指向の合図出来事
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.
RFC2833の開発と改正への貢献のための承認に関する全リストはRFC4733[4]に含まれています。 Editorは信じているか、または以下の人々が特に現在のドキュメントに貢献したのを意識しています: フレミングAndreasen、レックスColdren、ビル・フォスター、アルフレッドHoenes、ラジェッシュ・クマー、Aleksandar Lebl、Zarkoマルコフ、オレンPeleg、モシェSamoha、エードリアンSoncodi、およびYaakovシタイン。 スティーブNorreysとロニEvenは役に立つレビューコメントを提供しました。
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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.
2004年の[3]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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有効搭載量」、RFC4733、2006年12月。
[5] International Telecommunication Union, "Specifications for
signalling system no. 5", ITU-T Recommendation Q.140-Q.180,
November 1988.
[5]国際電気通信連合、「1988年11月にシステムNo.5インチ、ITU-T Recommendation Q.140-Q.180に合図するための仕様。」
[6] International Telecommunication Union, "Specifications of
Signalling System R1", ITU-T Recommendation Q.310-Q.332,
November 1988.
[6]国際電気通信連合、「1988年11月にシステムR1"、ITU-T推薦Q.310-Q.332に合図する仕様。」
Schulzrinne & Taylor Standards Track [Page 20] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[20ページ]。
[7] International Telecommunication Union, "Specifications of
Signalling System R2", ITU-T Recommendation Q.400-Q.490,
November 1988.
[7]国際電気通信連合、「1988年11月にシステムR2"、ITU-T推薦Q.400-Q.490に合図する仕様。」
[8] International Telecommunication Union, "Telephone user part
signalling procedures", ITU-T Recommendation Q.724, November
1988.
[8]国際電気通信連合、「手順を示す電話ユーザ部分」、ITU-T Recommendation Q.724、1988年11月。
[9] Telcordia Technologies, "LSSGR: signalling for Analog
Interfaces", Generic Requirement GR-506, June 1996.
[9] Telcordia技術、「LSSGR:」 「Analog Interfacesのために合図する」Generic Requirement 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 Recommendation G.704、1998年10月。
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.Petrack(「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC2833)は2000がそうするかもしれません。
[12] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[12] レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[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.3kbit/sを伝わる二元的なレート音声符号器」、ITU-T Recommendation G.723.1、1996年3月。
[14] International Telecommunication Union, "Coding of speech at 8
kbit/s using conjugate-structure algebraic-code-excited linear-
prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
[14] 国際電気通信連合、「接合の構造の興奮している代数的なコードの直線的な予測(CS-ACELP)を使用する8kbit/sでのスピーチのコード化」、ITU-T Recommendation 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 Recommendation 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、「ネットワークとCustomer Installation Interfaces--州Definitionsに合図しながら、DS1 Robbed噛み付く」、Telecommunications T1.403.02-1999(1999年5月)のための米国標準規格
Schulzrinne & Taylor Standards Track [Page 21] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[21ページ]。
Authors' Addresses
作者のアドレス
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinneコロンビアU.部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 CA
トム・テイラーノーテル1852ロレーヌAveオンタリオK1H 6Z8オタワ(カリフォルニア)
EMail: tom.taylor@rogers.com
メール: tom.taylor@rogers.com
Schulzrinne & Taylor Standards Track [Page 22] RFC 5244 Channel-Oriented Signalling Events June 2008
SchulzrinneとテイラーStandardsはイベント2008年6月にRFC5244のチャンネル指向の合図を追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Schulzrinne & Taylor Standards Track [Page 23]
Schulzrinneとテイラー標準化過程[23ページ]
一覧
スポンサーリンク
