Network Working Group B. Foster
Request for Comments: 3660 F. Andreasen
Updates: 2705 Cisco Systems
Category: Informational December 2003
Basic Media Gateway Control Protocol (MGCP) Packages
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
IESG Note
IESG注意
This document is being published for the information of the community. It describes a non-IETF protocol that is currently being deployed in a number of products. Implementers should be aware of RFC 3525 [37], which was developed in the IETF Megaco Working Group and the ITU-T SG16, and is considered by the IETF and ITU-T to be the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address. The IETF Megaco Working Group and the ITU-T Study Group 16 are developing extensions to RFC 3525 [37] that for functions of the type in addressed in this document.
この文書は、コミュニティの情報については公表されています。これは、現在の製品の数に展開されている非IETFプロトコルを記述しています。実装者は、IETFのMegaco作業部会とITU-T SG16で開発されたRFC 3525 [37]、を知っておく必要があり、かつ標準ベース（見直し、セキュリティ上の考慮事項を含む）な方法であることがIETFとITU-Tによって考えられていますMGCPが対処するように設計されたニーズを満たすために。 IETF Megacoの作業部会とITU-T研究グループ16は、RFC 3525の拡張機能を開発している[37]、そのタイプの機能については、この文書で取り上げインチ
Abstract
抽象
This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.
この文書では、メディアゲートウェイコントロールプロトコル（MGCP）パッケージの基本セットを提供します。一般的な、ライン、トランク、携帯電話、RTP、DTMF（デュアルトーンマルチ）、アナウンスサーバとスクリプトパッケージは、追加の説明や、これらのパッケージのいくつかのケースでは、新しいバージョンのRFC 2705からのパッケージの更新です。これらに加えて、5つの新しいパッケージは、ここで定義されています。これらは、信号リスト、リソース予約、メディアフォーマット、付加サービスとケタマップ拡張パッケージです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. List of Packages . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes to Existing RFC 2705 Packages. . . . . . . . . . 3
1.2.1. Change in Signal Types . . . . . . . . . . . . . 3
1.2.2. Operation Complete and Operation Failure . . . . 3
1.2.3. Package Versions . . . . . . . . . . . . . . . . 4
1.2.4. Event Definitions, Aliases and Interoperability
Issues . . . . . . . . . . . . . . . . . . . . . 4
1.2.5. New Events . . . . . . . . . . . . . . . . . . . 5
1.3. New Packages and Excluded Packages . . . . . . . . . . . 5
2. Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Generic Media Package. . . . . . . . . . . . . . . . . . 7
2.2. DTMF Package . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Trunk Package. . . . . . . . . . . . . . . . . . . . . . 16
2.4. Line Package . . . . . . . . . . . . . . . . . . . . . . 24
2.5. Handset Emulation Package. . . . . . . . . . . . . . . . 33
2.6. Supplementary Services Tone Package. . . . . . . . . . . 36
2.7. Digit Map Extension. . . . . . . . . . . . . . . . . . . 37
2.8. Signal List Package. . . . . . . . . . . . . . . . . . . 38
2.9. Media Format Parameter Package . . . . . . . . . . . . . 39
2.10. RTP Package. . . . . . . . . . . . . . . . . . . . . . . 43
2.11. Resource Reservation Package . . . . . . . . . . . . . . 48
2.11.1. Description. . . . . . . . . . . . . . . . . . . 48
2.11.2. Parameter Encoding . . . . . . . . . . . . . . . 52
2.11.3. Events . . . . . . . . . . . . . . . . . . . . . 53
2.12. Announcement Server Package. . . . . . . . . . . . . . . 55
2.13. Script Package . . . . . . . . . . . . . . . . . . . . . 56
3. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 59
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 59
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1. Normative References . . . . . . . . . . . . . . . . . . 60
6.2. Informative References . . . . . . . . . . . . . . . . . 62
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 64
This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages are updates of packages from RFC 2705 [38] with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.
この文書では、メディアゲートウェイコントロールプロトコル（MGCP）パッケージの基本セットを提供します。一般的な、ライン、トランク、携帯電話、RTP、DTMF、アナウンスサーバとスクリプトパッケージは、追加の説明や、これらのパッケージのいくつかのケースでは、新しいバージョンのRFC 2705 [38]からパッケージの更新です。これらに加えて、5つの新しいパッケージは、ここで定義されています。これらは、信号リスト、リソース予約、メディアフォーマット、付加サービスとケタマップ拡張パッケージです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [31].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [31]に記載されているように解釈されます。
The basic set of packages specified in this document is for use with MGCP 1.0 as defined in [1]. Included are the following packages:
[1]で定義されるように、この文書で指定されたパッケージの基本セットは、MGCP 1.0で使用するためです。以下のパッケージが含まれています。
-------------------------------------------
| Package | Name |
|-------------------------------------------|
| Generic Media Package | G |
| DTMF package | D |
| Trunk Package | T |
| Line Package | L |
| Handset Package | H |
| Supplementary Services Package | SST |
| Digit Map Extension | DM1 |
| Signal List Package | SL |
| Media Format Package | FM |
| RTP Package | R |
| Resource Reservation Package | RES |
| Announcement Server Package | A |
| Script Package | Script |
-------------------------------------------
MGCP 1.0, as defined in RFC 2705 [38] (and now updated in [1]), provided some additional clarification on the meaning of On-Off (OO) signals compared to earlier versions of MGCP. This lead to some inconsistency in some of the signal definitions in the accompanying packages in RFC 2705 [38]. This has been corrected in the packages that are included here by changing some of the signals from type On-Off to type Time-Out (TO).
MGCP 1.0は、RFC 2705 [38]で定義されるように（そして今で更新[1]）、（OO）信号がMGCPの以前のバージョンと比較してオン・オフの意味上のいくつかの追加の説明を提供しました。 RFC 2705 [38]それに伴うパッケージ内の信号の定義の一部では、いくつかの矛盾にこのリード。これは、タイムアウト（TO）を入力するためにオン・オフタイプからの信号の一部を変更することによって、ここに含まれているパッケージで修正されました。
Another change made to improve consistency and interoperability was to add the "operation complete" and "operation failure" events in packages where there are TO signals defined, but where the "operation complete" and "operation failure" events were not previously included as part of the package. By definition, all packages that contain
一貫性と相互運用性を向上させるために作られたもう一つの変化は、信号にそこに定義されているパッケージで、「操作完全な」と「動作不良」イベントを追加することでしたが、「操作完全な」と「動作不良」のイベントは、以前に一部として含まれていなかったところパッケージの。定義では、すべてのパッケージが含まれていること
Time-Out type signals now contain the "operation failure" ("of") and "operation complete" ("oc") events as defined in [1], irrespective of whether they are provided as part of the package description or not.
タイムアウトタイプの信号は、現在「動作不良」（「の」）と「操作完了」（「OC」）で定義されたイベントを含む[1]にかかわらず、それらがパッケージ記述かの一部として提供されているかどうか。
If a package without Time-Out signals contains definitions for the "oc" and "of" events, the event definitions provided in the package may over-ride those indicated here. Such practice is however discouraged and is purely allowed to avoid potential backwards compatibility problems.
タイムアウト信号のないパッケージには、イベント「の」「OC」との定義が含まれている場合は、パッケージに提供されたイベントの定義は、ここで示されたものを過剰に乗ることがあります。このような慣行は、しかし、がっかりして、純粋に潜在的な後方互換性の問題を回避するために許可されています。
It is considered good practice to explicitly mention that the "oc" and "of" events are supported in accordance with their default definitions. If no definition is included in the package, the default syntax and semantics are assumed.
明示的に言及するのは良い習慣と考えられている「OC」と、そのイベントはそのデフォルトの定義に従ってサポートされている「の」。何の定義がパッケージに含まれていない場合、デフォルトの構文と意味が想定されています。
Please refer to [1] for additional details on these events.
これらのイベントの詳細については、[1]を参照してください。
The generic, line, trunk, handset, RTP, DTMF, announcement server and script packages included in this document are new versions of packages that were previously contained in RFC 2705 [38]. The updated base MGCP 1.0 specification [1] provides an optional capability of auditing package versions. Any gateway that implements versioned packages SHOULD also implement this option.
本文書に含まれ、一般的な、ライン、トランク、携帯電話、RTP、DTMF、アナウンスサーバとスクリプトのパッケージは、以前RFC 2705 [38]に含まれたパッケージの新しいバージョンです。更新されたベースMGCP 1.0仕様[1]監査パッケージバージョンのオプションの機能を提供します。バージョン管理パッケージを実装する任意のゲートウェイも、このオプションを実装する必要があります。
Some event definitions or clarifications of previous event definitions have also been added in order to improve interoperability.
いくつかのイベント定義または前のイベントの定義の明確化は、また、相互運用性を向上させるために追加されました。
In some cases, events have aliases either in the same or in other packages and a recommendation has been made for the use of alternates by Call Agents for future implementations. For maximum interoperability, gateways MUST still implement these events (in fact they MUST always implement all of the events, signals, etc. in a package).
いくつかのケースでは、イベントは、同じまたは他のパッケージのいずれかの別名を持っており、勧告は将来の実装のためのコールエージェントによる交互の使用のために作られました。最大の相互運用性のため、ゲートウェイはまだ（実際には、彼らは常に、パッケージ内のイベント、信号などのすべてを実装しなければならない）、これらのイベントを実装しなければなりません。
Some events that were previously defined require specific provisioning in both the gateway and the Call Agent in order to allow for interoperability. In those cases, a warning to that affect has been included.
以前に定義された一部のイベントは、相互運用性を可能にするために、ゲートウェイとコールエージェントの両方で特定のプロビジョニングが必要。そのような場合には、その影響を与えると警告が含まれています。
In some cases, new events have been added to existing packages. Any changes to existing packages of course have resulted in the package version number being updated from unversioned (version 0) to version 1.
いくつかのケースでは、新しいイベントが既存のパッケージに追加されました。もちろん、既存のパッケージへの変更は、バージョン1に（バージョン0）バージョン管理外から更新されたパッケージのバージョン番号をもたらしました。
Two packages from RFC 2705 [38] have not been included. These are the "MF" and the "NAS" packages. These packages are still valid as are all unversioned (version 0) packages defined in RFC 2705 [38]. The reason these packages were not included are:
RFC 2705 [38]からの二つのパッケージが含まれていません。これらは、「MF」と「NAS」パッケージです。 RFC 2705 [38]で定義されたすべての（バージョン0）バージョン管理外のパッケージがあるように、これらのパッケージはまだ有効です。これらのパッケージが含まれていなかった理由は以下のとおりです。
* The original MF package had no defined way to outpulse MF digits so that MF CAS is now provided by other packages (i.e., the "MS", "MO" and "MD" packages) in a separate document.
*元のMFパッケージMF CASは、現在別の文書内の他のパッケージ（すなわち、「MS」、「MO」および「MD」パッケージ）によって提供されるように、MFディジットをoutpulseする全く定義された方法がなかったです。
* The "N" package, as defined in RFC 2705 [38], was incomplete. A new MGCP "NAS" package has been developed and provided in a separate document.
RFC 2705 [38]で定義されるよう* "N" パッケージは、不完全でした。新しいMGCP「NAS」パッケージを開発し、別の文書で提供されています。
New packages have also been included beyond what was included in RFC 2705 [38]. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages. The Resource Reservation ("RES") and Media Format ("FM") packages in particular are different from other packages in this document in that they contain new LocalConnectionOptions. This is allowed by the new extension rules in [1]. Future packages of this type MUST use a packages prefix in front of local connection options ("<package-name>/<Local Connection Option>") so as to avoid name-space problems. However because of the timing of the arrival of these packages relative to updating MGCP 1.0, this was not done for the "RES" and "FM" packages. The resulting new local connection options have been registered with IANA. For future cases where a package prefix is included, only the package name needs to be registered.
新しいパッケージは、RFC 2705 [38]に含まれていたものを超えて含まれています。これらは、信号リスト、リソース予約、メディアフォーマット、付加サービスとケタマップ拡張パッケージです。彼らは新しいLocalConnectionOptionsが含まれているという点で、特にリソース予約（「RES」）およびメディアフォーマット（「FM」）のパッケージは、この文書の他のパッケージとは異なります。これは、[1]の新しい拡張ルールで許可されています。名前空間の問題を回避するために、このタイプの今後のパッケージは、ローカル接続オプション（「<パッケージ名> / <ローカル接続オプション>」）の前に、パッケージの接頭辞を使用しなければなりません。 MGCP 1.0の更新に対するこれらのパッケージの到着のタイミングで、これは「RES」と「FM」のパッケージのために行われていなかったがために。その結果、新たなローカル接続オプションは、IANAに登録されています。パッケージ接頭辞が含まれている将来のケースでは、唯一のパッケージ名を登録する必要があります。
For those packages that involve MGCP events, the terms "signal" and "event" are used to differentiate a request from a Call Agent to a Media Gateway to apply an event ("signal"), from the request for the detection of an "event" that occurs on the Media Gateway and is "Notified" to the Call Agent.
MGCPイベントを伴うこれらのパッケージについては、用語「信号」と「イベント」は、「検出のための要求から、イベント（「シグナル」）を適用するためにメディアゲートウェイへのコールエージェントからの要求を区別するために使用されています」メディアゲートウェイ上で発生するとされる 『コールエージェントへの』通知されたイベント。
For packages that involve events and signals, the tables contain five columns:
イベントや信号を必要とするパッケージの場合、テーブルは5つの列が含まれています。
Symbol: the (package) unique symbol used to identify the event.
記号：（パッケージ）イベントを識別するために使用される固有のシンボル。
Definition: a short description of the event.
定義：イベントの短い説明。
R: an x appears in this column if the event can be requested by the Call Agent. Alternatively, one or more of the following symbols may appear. An "S" is included if the event-state may be audited. A "C" indicates that the event can be detected on a connection, and a "P" indicates the event is persistent.
R：イベントは、コールエージェントによって要求されることができれば、xは、この列に表示されます。また、以下のシンボルの1つまたは複数が表示されることがあります。イベント状態が監査される可能性がある場合、「S」は含まれています。 「C」は、イベントが接続上で検出することができることを示し、「P」は、イベントが永続的であることを示します。
S: if nothing appears in this column for an event, then the event cannot be signaled by the Call Agent. Otherwise, the following symbols identify the type of event:
S：何もイベントのために、この列に表示されない場合、そのイベントは、コールエージェントによって通知することができません。そうでない場合は、次の記号は、イベントの種類を識別します。
* OO On/Off signal
* OOオン/オフ信号
* TO Time-Out signal.
*タイムアウト信号TO。
* BR Brief signal.
* BR簡単な信号。
In addition, a "C" will be included if the signal can be generated on a connection.
信号接続上で生成することができればまた、「C」が含まれます。
Duration: specifies the default duration of TO signals. If a duration is left unspecified, then the default timeout will be assumed to be infinite, unless explicitly noted in the description of the signal. A duration may also be declared as being variable in a case where signals involve complex sequencing (e.g., scripts or digit out-pulsing) where the amount of time may vary with either processing time or the signaling environment.
所要時間は：TO信号のデフォルトの継続時間を指定します。期間が未指定のままにすると、明示的に信号の説明に記載のない限り、デフォルトのタイムアウトは、無限であると想定されます。期間はまた、信号が時間の量は、処理時間や信号環境のいずれかで変化し得る複合配列決定（例えば、スクリプトまたはアウトパルス桁）を含む場合には変数として宣言してもよいです。
Default time-out values may be over-ridden by the Call Agent for any Time-Out event defined in this document (with the exception of those that have a default value of "variable") by a "to" signal parameter which specifies the timeout value in milliseconds (see [1]). The following example indicates a timeout value of 20 seconds:
デフォルトのタイムアウト値を指定する「を」信号パラメータによって（「変数」のデフォルト値を持っているものを除いて）この文書で定義された任意のタイムアウトイベントのコールエージェントによって乗ら上であってもよく、ミリ秒単位のタイムアウト値（[1]参照）。次の例では、20秒のタイムアウト値を示します。
S: sst/cw(to=20000)
S：SST / CW（= 20000）
As indicated in [1]: by default, a supplied time-out value MAY be rounded to the nearest non-zero value divisible by 1000, i.e., whole second. However, individual signal definitions within a package may define other rounding rules.
示されているように[1]：デフォルトでは、供給されたタイムアウト値1000で割り切れる最も近いゼロ以外の値、即ち、全体秒に丸みを帯びていてもよいです。しかし、パッケージ内の個々の信号の定義は、他の丸め規則を定義することができます。
Note that Time-Out signals that involve other parameters still allow the use of the "to" signal parameter e.g.:
それでも例えば「へ」信号パラメータの使用を可能にする他のパラメータを含んでいるタイムアウト信号を注意してください：
S: T/sit(1,to=3000)
S：T / SIT（1、3000 =まで）
The order of the "to" parameter relative to the other parameters is not important.
他のパラメータに比べて「へ」のパラメータの順序は重要ではありません。
Note: as per [1], On-Off (OO) signals are parameterized with "+" (meaning turn on) or "-" (meaning turn off). If the parameter is missing, the default is to turn on the signal. Unlike Time-Out signals, On-Off signals do not stop when an event occurs.
注：[1]、オン・オフ（OO）信号に従って（ターンオンを意味する）、「+」のパラメータ化されているか、または「 - 」（オフを意味します）。パラメータが欠落している場合、デフォルトでは、信号をオンにすることです。イベントが発生したときにタイムアウト信号とは異なり、オン・オフ信号が停止しません。
Other than the "to" parameter for Time-out (TO) signals and the "+" and "-" for On-Off (OO) signals, signals and events in the packages in this document do not have parameters unless explicitly indicated in the description of the event for that package.
「を」タイムアウトのためのパラメータ（TO）信号と「+」以外の「 - 」に明示的に示さない限りオン・オフ（OO）は、このドキュメントではパッケージの信号、信号およびイベントはパラメータはありませんそのパッケージのイベントの説明。
In some of the signal definitions below, specific tone definitions are provided even though actual frequencies may vary from country to country.
以下の信号の定義の一部では、特定のトーンの定義は、実際の周波数は国によって異なり得るとしても提供されます。
Package Name: G Version: 1
パッケージ名：Gバージョン：1
The generic media package groups the events and signals that can be observed on several types of endpoints, such as trunk gateway endpoints, access gateway endpoints or residential gateway endpoints.
一般的なメディアのパッケージグループなどのトランクゲートウェイエンドポイントとしてエンドポイントのいくつかの種類、アクセスゲートウェイエンドポイントや住宅用ゲートウェイエンドポイント上で観察することができるイベントと信号。
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| cf | Confirm Tone | | BR |
| cg | Congestion Tone | | TO infinite |
| ft | Fax Tone | x | |
| it | Intercept Tone | | TO infinite |
| ld | Long Duration Connection | C | |
| mt | Modem Tone | x | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| pat(###) | Pattern Detected | x | OO |
| pt | Preemption Tone | | TO infinite |
| rbk(...) | Ringback | | TO,C 180 seconds|
| rt | Ringback Tone | | TO,C 180 seconds|
---------------------------------------------------------------
New events added to this package from the previously unversioned package: "oc"
「OC」：新しいイベントが以前にバージョン管理外のパッケージからこのパッケージに追加しました
Changes: "it" and "pt" signals changed from OO to TO.
変更点は：「それは」と「PT」の信号がOO TOから変更しました。
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトのタイムアウト値「が」信号パラメータによって、このパッケージで定義された任意のタイム・アウト信号のためのコールエージェントによって上だらけであってもよいことに注意してください。詳細については、この文書のセクション2を参照して、ならびに[1]。
The events and signals are defined as follows:
次のようにイベントと信号が定義されます。
Confirmation Tone (cf): This is also referred to as "positive indication tone" in ITU-T E.182. In North America, Confirmation Tone uses the same frequencies and levels as dial tone (350 and 440 Hertz) but with a cadence of 0.1 second on, 0.1 second off, repeated three times. See GR-506-CORE [7] Section 17.2.4. It is considered an error to try and play confirmation tone on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
確認音（CF）：これは、ITU-T E.182に「ポジティブ指示トーン」と呼ばれます。北米では、確認音は、ダイヤルトーン（350及び440ヘルツ）と同じ周波数およびレベルを使用するが、0.1秒でのリズムで、0.1秒オフ、3回繰り返します。 GR-506-CORE [7]のセクション17.2.4を参照。これは試してみて、オンフックであり、そのような試みが行われたときにエラーが結果的に（ - 電話オンフックエラーコード402）返されなければならない電話で確認音を再生するには、エラーと考えられています。
Congestion Tone (cg): Refer to ITU-T E.180 [8] and E.182 [10]. This maps to re-order tone in North America (refer to GR-506-CORE [7] Section 17.2.7).
輻輳トーン（CG）：[8] ITU-T E.180を参照し、E.182 [10]。これは、北米での再注文トーン（GR-506-CORE [7]のセクション17.2.7を参照してください）にマッピングします。
Fax Tone (ft): The fax tone event is generated whenever a fax call is detected by the presence of V.21 fax preamble. The fax tone event SHOULD also be generated when the T.30 CNG tone is detected. See ITU-T Recommendations T.30 [21] and V.21 [22].
ファックストーン（FT）：ファックストーン事象がファックス呼がV.21ファックスプリアンブルの存在によって検出されるたびに生成されます。 T.30 CNGトーンが検出されたときにファックストーンイベントも生成する必要があります。 ITU-T勧告T.30 [21]とV.21 [22]を参照。
Intercept Tone(it): This is a country specific tone as defined in ITU-T E.180 Supplement 2 [9].
インターセプトトーン（IT）：これは、ITU-T E.180補足2で定義されている国特定のトーンである[9]。
Long Duration Connection (ld): The "long duration connection" is detected when a connection has been established for more than a provisioned amount of time. The default value is 1 hour.
長時間接続（LD）：接続は時間のプロビジョニング量以上のために設立されたとき、「長時間の接続は、」検出されました。デフォルト値は1時間です。
This event is detected on a connection. When no connection is specified as part of the request, the event applies to all connections for the endpoint, regardless of when the connections are created. The "all connections" wildcard (see [1]) may also be used for this case, and is in fact preferred for consistency. In either case, the name of the connection on which the event was detected will be included when the event is observed, e.g.:
このイベントは、接続上で検出されました。何も接続が要求の一部として指定されていない場合は、イベントに関係なく接続が作成されたときの、エンドポイントのすべての接続に適用されます。 「すべての接続」ワイルドカード（[1]参照）も、この場合に使用することができ、実際には一貫性のために好ましいです。いずれの場合も、イベントが検出された接続の名前は、イベントは例えば、観察されたときに含まれます：
G/ld@0A3F58
0A3F58 @ G / LD
Modem Tone (mt): Indicates V.25 Answer tone (ANS) with or without phase reversals or V.8 Modified Answer Tone (ANSam) tone with or without phase reversals. Note that this implies the presence of a data call. Also note that despite the name of the event, devices other than modems may generate such tones, e.g., a fax machine.
モデムトーン（MT）は：位相の反転の有無にかかわらずV.25アンサートーン位相反転やV.8の有無にかかわらず（ANS）変形応答トーン（ANSamの）トーンを示します。これはデータ呼の存在を暗示していることに注意してください。また、イベントの名前にもかかわらず、モデム以外の装置は、例えば、ファクシミリ装置を、このようなトーンを生成してもよいことに留意されたいです。
Operation Complete (oc): The standard definition of operation complete [1].
操作コンプリート（OC）：[1]完全な操作の標準的な定義。
Operation Failure (of): The standard definition of operation failure [1].
動作不良（の）：動作不良の標準的な定義[1]。
Pattern Detected (pat(###)): This event requires special provisioning that needs to be agreed on between the Call Agent and media gateway in order to ensure interoperability. It is retained in order to maintain backwards compatibility with version 0 of the "G" package. This event MUST be parameterized with a decimal numeric value from 0 to 999 specifying the pattern to detect. When reported, the pattern is also included as a parameter.
検出されたパターン（PAT（###））：このイベントは、相互運用性を確保するためにコール・エージェントとメディアゲートウェイとの間で合意する必要があり、特別なプロビジョニングが必要です。それは、「G」パッケージのバージョン0との下位互換性を維持するために保持されています。このイベントは、0から検出するパターンを指定999 10進数値でパラメータ化されなければなりません。報告された場合には、パターンは、パラメータとして含まれています。
Preemption Tone (pt): This is a country specific tone and is defined in ITU-T E.180 Supplement 2 [9].
プリエンプショントーン（PT）：これは、国固有のトーンであり、ITU-T E.180補足2で定義されている[9]。
Ringback (rbk(connectionID)): This is an alias for "rt@connectionID" and is included here for backwards compatibility only. It is recommended that Call Agents use "rt@connectionID" instead of "rbk(connectionID)" for ring-back over a connection for new implementations. Although the ringback signal is applied on a connection, the "rbk" signal does not support the "@connection" syntax. When the signal is requested, it MUST be parameterized with a connection-ID or a connection-ID wildcard as specified in [1].
リングバック（RBK（connectionID））：これは、「RTする@ connectionID」の別名であり、唯一の後方互換性のためにここに含まれています。コールエージェントは新しい実装のための接続を介して、リングバックのための代わりに「RBK（connectionID）」の「connectionID @ RT」を使用することをお勧めします。リングバック信号は、接続に適用されているが、「RBK」信号「@connection」構文をサポートしていません。信号が要求されると、それは、接続IDまたは[1]で指定されるように、接続IDワイルドカードでパラメータ化されなければなりません。
Ringback Tone (rt): Refer to ITU-T E.180 [8] and ITU-T E.182 [10]. Also referred to as ringing tone - a tone advising the caller that a connection has been made and that a calling signal is being applied to the called party or service point. In North America, this tone is a combination of two AC tones with frequencies of 440 and 480 Hertz and levels of -19 dBm each, to give a combined level of -16 dBm.
リングバックトーン（RT）：ITU-T E.180を参照してください[8]とITU-T E.182 [10]。また、音を鳴らすと呼ばれる - トーンが接続が確立されたと呼び出し信号が被呼者またはサービスポイントに適用されていることを、発信者に助言。北米では、このトーンは-16 dBmでの合成レベルを与えるために、440と480ヘルツの周波数および-19 dBmのレベルのそれぞれに2つの交流トーンの組み合わせです。
The cadence for Audible Ring Tone is 2 seconds on, followed by 4 seconds off. See GR-506-CORE [7] - LSSGR: SIGNALING, Section 17.2.5.
可聴着信音のためのケイデンスはオフ4秒、続いて2秒です。 SIGNALING、セクション17.2.5：LSSGR - GR-506-CORE [7]を参照。
This signal can be applied directly to an endpoint or alternatively on a connection using the syntax "rt@connectionID". When the ringback signal is applied to an endpoint, it is considered an error to try and play ringback tone if the endpoint is considered on-hook, and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook). When the ringback signal is applied to a connection, no such check is to be made.
この信号は、エンドポイントにまたは代替的に「@ connectionID RT」構文を使用して、接続に直接適用することができます。リングバック信号は、エンドポイントに適用される場合には、エンドポイントがオンフックとみなされ、そのような試みがなされている時にエラーが結果として返される必要がある場合はリングバックトーンを試してみて、再生するエラー（エラー・コード402考えられる - 電話オンフック）。リングバック信号は、接続に適用される場合、そのようなチェックが行われるべきではありません。
Note that as specified in [1], signals requested on a connection MUST be played regardless of the connection mode. For example, in a call-waiting situation, ringback tone may be played on a connection in "inactive" mode.
で指定されるように[1]、接続に要求された信号に関係なく、接続モードの再生されなければならないことに留意されたいです。例えば、コールウェイティング状況で、リングバックトーンは、「非アクティブ」モードでの接続で再生することができます。
Package name: D Version: 1
パッケージ名：Dバージョン：1
--------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|--------------------------------------------------------------|
| 0 | DTMF 0 | x | BR |
| 1 | DTMF 1 | x | BR |
| 2 | DTMF 2 | x | BR |
| 3 | DTMF 3 | x | BR |
| 4 | DTMF 4 | x | BR |
| 5 | DTMF 5 | x | BR |
| 6 | DTMF 6 | x | BR |
| 7 | DTMF 7 | x | BR |
| 8 | DTMF 8 | x | BR |
| 9 | DTMF 9 | x | BR |
| # | DTMF # | x | BR |
| * | DTMF * | x | BR |
| A | DTMF A | x | BR |
| B | DTMF B | x | BR |
| C | DTMF C | x | BR |
| D | DTMF D | x | BR |
| DD(..) | DTMF Tone Duration | x | TO 3 seconds |
| DO(..) | DTMF OO Signal | | OO |
| L | Long Duration Indicator | x | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| T | Interdigit Timer | x | TO 16 seconds |
| X | DTMF Tones Wildcard, | x | |
| | match any digit 0-9 | | |
--------------------------------------------------------------
Changes from the previous version of the package: events "dd", "do", "oc" were added.
パッケージの以前のバージョンからの変更点：イベント「DD」、「やる」は、「OC」が追加されました。
Note that DTMF tones including the DTMF tones wildcard can use the eventRange notation defined in [1] when requesting events, e.g., "D/[0-9](N)".
DTMFを含むDTMFトーンがワイルドカード[1]イベントを要求するとき、例えば、「D / [0-9]（N）」で定義eventRange表記法を使用することができるトーンことに留意されたいです。
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトのタイムアウト値「が」信号パラメータによって、このパッケージで定義された任意のタイム・アウト信号のためのコールエージェントによって上だらけであってもよいことに注意してください。詳細については、この文書のセクション2を参照して、ならびに[1]。
The events are defined as follows:
次のようなイベントが定義されています。
DTMF tones (0-9,#,*,A,B,C,D): Detection and generation of DTMF tones is described in GR-506-CORE [7] - LSSGR: SIGNALING, Section 15. Note that it is considered an error to try and play DTMF tones on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook). The event codes can be specified in a digit map. When requested as a signal, as per GR-506-CORE [7], section 15, a minimum tone duration of 50 ms will be followed by a minimum interdigit silence period of 45 ms, i.e., if requested in a signal list such as "S: sl/s(d/5,d/6,d/7)", then interdigit timing requirements will be satisfied.
DTMFトーン（0-9、＃、*、A、B、C、D）：DTMFトーンの検出および発生はGR-506-COREに記載されている[7] - LSSGR：それは考えられていることを知らせる、第15項注オンフックであり、そのような試みは、（ - オンフック電話エラーコード402）が行われている時にエラーが結果として返されなければならない電話でDTMFトーンを試してみて、再生するエラー。イベントコードは、数字マップで指定することができます。セクション15、[7] GR-506-COREに従って、信号として要求されたときのような信号リストに要求された場合、50ミリ秒の最小トーン持続時間は、45ミリ秒、すなわち最小桁間沈黙期間が続きます"S：SL /秒（D / 5、D / 6、D / 7）"、次いで、桁間タイミング要件が満たされます。
Note that some types of endpoints, such as announcement endpoints, MAY allow detection and/or generation of a DTMF tone over a connection. However, this requires consistent provisioning between the Call Agent and announcement server (it is not required in order to be compliant with the DTMF package).
そのようなアナウンスエンドポイントとしてエンドポイント、いくつかの種類は、接続を介してDTMFトーンの検出および/または生成を可能にするかもしれないことに注意してください。しかし、これは、コールエージェントとのアナウンスサーバ（それはDTMFパッケージに準拠するために必要とされていない）との間で一貫性のプロビジョニングが必要です。
DTMF Tone Duration (dd(dg=<tone>,to=<time>,su=<TrueOrFalse>)): This event can be used to indicate if/when the specified <tone> has a duration greater than the <time> value indicated (and is reported once the duration is exceeded). The parameters can be supplied in any order. The value of <tone> can be any of the DTMF tone symbols (without including the package name) specified in the DTMF package (including X in the case of events, but not signals). If this parameter is absent, any DTMF tone that occurs will be reported. The parameter <time> is in milli-seconds and may be rounded to the nearest 10 ms by the gateway. The minimum value of <time> that can be requested when requesting an event is 40 ms. When requesting a signal, the minimum value of <time> that can be requested is 50 ms. The maximum value of <time> that can be requested for either an event or a signal is 60000 ms. If the "to=<time>" parameter is absent when requested as an event, the event will report the full duration (up to 60000 ms) of the tone when the tone is completed. When reported as an ObservedEvent, both parameters are always supplied. In this case, <tone> is the actual tone detected and <time> is either:
DTMFトーン時間（= <時間>にDD（DG = <トーン>、SU = <TrueOrFalse>））：指定されたときに<トーン> <時間>を超える持続時間を有する/場合、このイベントを示すために使用することができます値が示され（および持続時間が超過されると報告されています）。パラメータは任意の順序で供給することができます。 <トーン>の値は、（パッケージ名を含むなし）DTMFトーンシンボルのいずれか（イベントの場合にはXはなく、信号を含む）DTMFパッケージに指定することができます。このパラメータが存在しない場合は、発生した任意のDTMFトーンが報告されます。パラメータ<時間>ミリ秒であり、ゲートウェイによって、最も近い10ミリ秒に丸めてもよいです。イベントを要求するときに要求することができ、<時間>の最小値は40ミリ秒です。信号を要求するとき、要求することができ、<時間>の最小値は50ミリ秒です。イベントまたは信号のいずれかを要求することができる<時間>の最大値は60000ミリ秒です。 「= <時間>する」パラメータが存在しないイベントとして要求されたとき場合はトーンが完了すると、イベントはトーンの（60000ミリ秒まで）全期間を報告します。 ObservedEventとして報告すると、両方のパラメータが常に供給されています。この場合、<トーン>実際のトーン検出され、<時間>のいずれか。
* The <time> specified in the request (possibly rounded), or
* <時間>要求（おそらく四捨五入）で指定され、又は
* If the request did not contain a "to=<time>" parameter, the full duration of the tone.
*リクエストは「へ= <時間>」パラメータ、トーンの全期間が含まれていなかった場合。
The parameter "su" MAY be included when this is requested as an event (but is not reported). This parameter is used to indicate whether or not the DTMF digits requested should be suppressed in-band when it is requested. Possible values are "true", indicating that in-band DTMF should be suppressed and "false" indicating that DTMF should continue to be passed in-band. The default value of the parameter, if missing, is "false". The "su" parameter MUST NOT be included when requesting "D/dd" as a signal.
これはイベントとして要求されている（しかし、報告されていない）とき、パラメータ「suが」含まれるかもしれません。このパラメータは、それが要求されたとき、要求DTMFディジットはインバンド抑制すべきか否かを示すために使用されます。可能な値は、インバンドDTMFが抑制され、DTMFインバンド渡されることを継続すべきであることを示す「偽」しなければならないことを示し、「真」です。パラメータのデフォルト値は、不足している場合は、「偽」です。信号として「D / DD」を要求するとき、「SU」パラメータが含まれてはいけません。
When used as a signal, "dd" provides the ability to generate a DTMF tone as a TO signal. When applied as a signal, an additional 50 ms of silence will be tacked onto the end before the operation complete occurs, i.e., "S: dd(dg=5,to=2500)" will play the DTMF tone for the number "5" for 2.5 seconds, followed by 50 ms of silence period. The operation complete (if requested) will be notified after the silence interval occurs. Any value from 50 ms to 60000 ms can be requested. Gateways generating or detecting the tone may round off the requested time to the nearest 10 ms.
信号として使用する場合、「DD」は、信号TOとしてDTMFトーンを生成する機能を提供します。 「：DD（DG = 5、= 2500）S」番号「5ためのDTMFトーンを再生する信号として適用した場合の動作完了が発生する前に、沈黙の追加の50ミリ秒、すなわち、端部に仮止めされます「2.5秒間、無音期間の50ミリ秒続きます。無音区間が発生した後、完全な操作は、（要求された場合）に通知されます。 50ミリ秒から60000ミリ秒までの任意の値を要求することができます。ゲートウェイ生成またはトーンを検出することは、最も近い10ミリ秒に要求された時間を丸めることができます。
The "dd" event can be used in place of the "long duration" event in order to detect a digit pressed for longer than 2 seconds. For example, in order to detect if a user presses the long "#" for longer than 2 seconds, a request could be made with the RequestedEvents line "R: d/dd(N)(dg=#,to=2000)". The resulting ObservedEvents line would be "O: d/dd(dg=#,to=2000)".
「DD」のイベントが2秒以上押した数字を検出するために、「長い期間」イベントの代わりに使用することができます。例えば、ユーザは、2秒以上の長い「＃」を押下するかどうかを検出するために、要求はRequestedEvents線で作ることができ、「R：D / DD（N）（DG =＃= 2000）」 。得ObservedEventsラインは "O：D / DD（DG =＃= 2000）" であろう。
Suppose instead, that the RequestedEvents line contains
RequestedEventsラインが含まれていること、その代わりとし
R: d/[0-9*#],d/dd
R：D / [0-9 *＃]、D / DD
Suppose the user then pushes the "#" for 2.5 seconds. In this case, two events will be notified:
次に、ユーザは、2.5秒のための「＃」をプッシュしたとします。この場合、2つのイベントが通知されます。
O: d/#
O：D /＃
when the "#" key is first pressed, and
「＃」キーが最初に押されたとき、および
O: d/dd(dg=#,to=2500)
O：D / DD（DG =＃= 2500）
when the "#" key is finally released.
「＃」キーがついにリリースされたとき。
DTMF OO Signal (do(dg=<tone>,<on-or-off>)): This signal is used to generate a DTMF tone as an on-off signal. The <tone> parameter is any of the symbols for a specific tone in the DTMF package (i.e., "0" to "9", "A", "B", "C", "D", "*", or "#"). The <on-or-off> indicator is "+" for on and "-" for off as per [1]. The <tone> parameter MUST be supplied, otherwise a return code of 538 - "Event/signal parameter error" will be provided in the response. If the <on-or-off> parameter is missing, the default is to turn the signal on as usual (i.e., "+" is the default). The order of the parameters is not significant since "+" and "-" are reserved characters and are easily distinguished from the <tone> parameter.
DTMF OO信号（DO（DG = <トーン>、<オンまたはオフ>））：この信号はオン・オフ信号としてDTMFトーンを生成するために使用されます。 <トーン>パラメータは、DTMFパッケージ内の特定のトーン（すなわち、 "0" 〜 "9"、 "A"、 "B"、 "C"、 "D"、 "*"、またはのシンボルのいずれかであります"＃"）。 <オンまたはオフが>インジケータが「+」オンとするためのものである「 - 」としてあたりオフ[1]。 「イベント/信号パラメータエラー」応答で提供される - <トーン>パラメータは、そうでなければ538の戻りコードは、供給されなければなりません。 <オンまたはオフ>パラメータが欠落している、デフォルトは通常通りに信号をオンにすることである場合（すなわち、「+」がデフォルトです）。パラメータの順序は、「+」以来の大幅なものではなく、「 - 」予約文字であり、<音>パラメータから容易に区別されています。
Long Duration Indicator (l): The "long duration indicator" is observed when a DTMF signal is produced for a duration larger than two seconds. In this case, the gateway will detect two successive events: first, when the signal has been recognized, the DTMF signal, and then, 2 seconds later, the long duration signal.
長時間インジケータ（L）：DTMF信号が2秒よりも大きい持続時間のために製造されている場合、「長時間インジケータが」観察されます。まず、信号は、その後、2秒後に長時間の信号を、DTMF信号を認識し、されている。この場合、ゲートウェイは、2つの連続イベントを検出します。
Operation Complete (oc): This is the standard definition of operation complete [1].
動作完了（OC）：これは完全な操作の標準的な定義である[1]。
Operation Failure (of): This is the standard definition of operation failure [1].
動作不良（の）：これは、動作不良、[1]の標準的な定義です。
Timer (t): Timer T can be used as an event or as a time-out (TO) signal. As a signal, its only behavior is the normal characteristics of a "TO" signal as defined in [1] (i.e., if no event occurs before the time-out, an operation complete event will be generated).
タイマ（T）：タイマーTは、イベントとして、またはタイムアウト（TO）信号として使用することができます。信号として、その唯一の動作は、[1]で定義されるように「TO」信号（無イベントがタイムアウトする前に発生しなければ、すなわち、動作完了イベントが生成される）の正常な特性です。
As an event, Timer T is a digit input timer that can be used in two ways:
イベントとして、タイマTは、2つの方法で使用することができる数字入力タイマです。
* When timer T is used with the accumulate according to digit map action, the timer is not started until the first DTMF tone is entered, and the timer is restarted after each new DTMF tone is entered until either a digit map match or mismatch occurs. In this case, timer T functions as an inter-digit timer as illustrated by:
タイマーTがケタマップのアクションに応じて蓄積して使用する場合は最初のDTMFトーンが入力され、ディジットマップの一致または不一致のいずれかが発生するまで、それぞれの新しいDTMFトーンが入力された後、タイマーが再起動されるまで*、タイマーが開始されません。この場合には、インターディジット・タイマなどのタイマTの関数はによって示されているように。
R: D/[0-9T](D)
R：D / [0-9T]（D）
* When timer T is used without the "accumulate according to digit map" action, the timer is started immediately and simply cancelled (but not restarted) as soon as a DTMF tone is entered. In this case, timer T can be used as an inter-digit timer when overlap sending is used, as in:
*タイマーTがアクション「ケタマップに従って蓄積する」、タイマは、すぐにDTMFトーンが入力されるとすぐに開始し、単にキャンセル（ただし、再起動されません）されずに使用されています。重複送信を使用する場合のように、この場合には、タイマTは、インターディジット・タイマとして使用することができます。
R: D/[0-9](N), D/T(N)
R：D / [0-9]（N）、D / T（N）
When used with the "accumulate according to digit map" action, timer T takes on one of two values, T-partial or T-critical. When at least one more symbol is required for the "current dial string" to match any one of the patterns in the digit map, timer T takes on the value T-partial, corresponding to partial dial timing. If a timer is all that is required to produce a match, timer T takes on the value T-critical corresponding to critical dial timing. When timer T is used without the "accumulate according to digit map" action, timer T takes on the value T-critical. The default value for T-partial is 16 seconds and the default value for T-critical is 4 seconds. The provisioning process may alter both of these. If timer T is not used, then inter-digit timing will not be performed.
「ケタマップに従って蓄積」アクションで使用した場合、タイマーTは、2つの値の1、T-部分的またはT-重要になります。少なくとももう1つのシンボルがケタ地図のパターンのいずれかと一致するように、「現在のダイヤル文字列」のために必要とされる場合、タイマTは、部分ダイヤルタイミングに対応し、T-部分的な値をとります。タイマーが試合を生産するために必要とされるすべての場合は、タイマーTは、値Tクリティカルクリティカルなダイヤルタイミングに対応を取ります。タイマTが「ケタマップに応じて蓄積し、」アクションなしで使用される場合、タイマーTはT-臨界値になります。 T-部分のデフォルト値は16秒で、T-重要なのデフォルト値は4秒です。プロビジョニング・プロセスは、これらの両方を変更することができます。タイマーTが使用されていない場合は、桁間タイミングは実行されません。
The following examples illustrate this. Consider the digit map:
次の例では、これを説明します。ディジットマップを考えてみましょう：
(xxxxxxx|x11T)
（XXXXXXX | x11T）
and assume that DTMF and the timer T is accumulated according to digit map. At the first DTMF input, say "4", timer T is started with a value of T-partial since at least one more symbol is required. If "1" is then input, it leads to a restart of timer T with a value of T-partial again. If "1" is now input again, we have a current dial string of "411" and a timer is now all that is required to produce a match. Hence timer T is now restarted with value T-critical.
そして、DTMFとタイマTがケタマップに応じて蓄積されていることを前提としています。最初のDTMF入力では、「4」と言う少なくとももう1つのシンボルが必要とされているので、タイマーTがT-部分の値で開始されます。 「1」は、その後、入力された場合、それは再びT-部分の値でタイマーTの再起動につながります。 「1」が再び今入力された場合、我々は「411」の現在のダイヤルストリングを持っていると、タイマーは今試合を生産するために必要とされるすべてです。したがって、タイマーTは現在、T-臨界値で再開されます。
Finally, consider the following subtle examples (all assuming DTMF and timer T being accumulated according to digit map):
最後に、以下の微妙な例（数字マップに従って蓄積されるすべての仮定DTMFとタイマーT）を考慮してください。
The digit map
ディジットマップ
(1[2-3T].)
（12 ZTSHT）。
will match immediately on the input "1" since zero or more matches of the range are specified.
範囲のゼロまたはそれ以上のマッチが指定されているので、入力「1」にすぐに一致します。
The digit map
ディジットマップ
(1[2-3].T)
（1 [2-3] .T）
and an input of "1" will lead to timer T being set to T-critical.
そして「1」の入力は、タイマTがT-criticalに設定されることにつながります。
A digit map of
のディジットマップ
(1[2-3]T.)
（1 [2-3] T。）
and an input of "1" will lead to timer T being set to T-partial. Furthermore, upon subsequent input of "2" or "3" a perfect match will be triggered immediately since timer T is completely irrelevant.
そして「1」の入力は、タイマTがT-部分的に設定されることにつながります。タイマTは完全に無関係であるので、「2」または「3」の次の入力の際に完全な一致が直ちにトリガされます。
DTMF Tones Wildcard (X): The DTMF tones wildcard matches any DTMF digit between 0 and 9. The actual event code generated will however be the event code for the digit detected. The DTMF tones wildcard is often used to detect DTMF input to be matched against a digit map.
DTMFトーンワイルドカード（X）は：DTMFトーンのワイルドカードは、0から9が検出された桁のイベントコードになり生成される実際のイベントコードとの間の任意のDTMFディジットに一致します。 DTMFトーンのワイルドカードは、多くの場合、桁マップと照合するDTMF入力を検出するために使用されます。
Package Name: T Version: 1
パッケージ名：Tバージョン：1
----------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
| as | Answer Supervision | x | BR |
| bl | Blocking | | BR |
| bz | Busy | | TO 30 sec. |
| co1 | Continuity Tone (go tone, | x | TO 3 sec. |
| | or return tone) | | |
| co2 | Continuity Test (go tone, | x | TO 3 sec. |
| | or return tone in dual tone | | |
| | procedures) | | |
| ct(...) | Continuity Transponder | | OO |
| lb | Loopback | | OO |
| nm | New Milliwatt Tone | x | TO 3 sec |
| mm | Newest Milliwatt Tone | x | TO 3 sec |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| om | Old Milliwatt Tone | x | TO 3 sec |
| pst | Permanent Signal Tone | | TO infinite |
| qt | Quiet Termination | | TO infinite |
| ro | Reorder Tone | x | TO 30 sec. |
| sit(#) | Special Information Tone | x | TO 2 sec. |
| | | | (see notes) |
| tl | Test Line | x | TO infinite |
| tp(###) | Test Pattern | x | TO 3 sec |
| zz | No Circuit | x | TO 2 sec |
----------------------------------------------------------------
New events added to this package from the previously unversioned package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp".
"BZ"、 "CT"、 "ミリメートル"、 "OC"、 "PST"、 "QT"、 "座る"、および "TP"：新しいイベントが以前にバージョン管理外のパッケージからこのパッケージに追加しました。
Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals changed from OO to TO; "as" and "bl" changed from OO to BR.
イベントタイプの変更： "CO1"、 "CO2"、 "NM"、 "OM"、 "TL"、 "ZZ" の信号がTOにOOから変更しました。 「よう」とOOからBRに変更し、「BL」。
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトのタイムアウト値「が」信号パラメータによって、このパッケージで定義された任意のタイム・アウト信号のためのコールエージェントによって上だらけであってもよいことに注意してください。詳細については、この文書のセクション2を参照して、ならびに[1]。
The definition of the trunk package events are as follows:
次のようにトランクパッケージイベントの定義は以下のとおりです。
Answer Supervision (as): This event is used to indicate the occurrence answer supervision. In most cases, it is a result of a steady off-hook in response to a call request. This event is included for backwards compatibility with the previous version of the package. The preferred alternative is to use the "answer" event in the appropriate CAS packages [34] (Note: check the details on the use of "answer" in the particular CAS package; in most cases "answer" as an event is an indication of a steady off-hook regardless of whether or not it is an indication of answer supervision). For details on when answer supervision is appropriate refer to [5].
このイベントは、発生の応答監視を示すために使用されています（と）監督に回答します。ほとんどの場合、それは、呼び出し要求に応じて、着実にオフフックの結果です。このイベントは、パッケージの以前のバージョンとの下位互換性のために含まれています。好ましい代替は、適切なCASパッケージで「回答」イベントを使用することである[34]（注：特定のCASパッケージの「答え」の使用の詳細を確認し、ほとんどの場合「アンサ」イベントが表示されたように定常オフフックのかかわらず、それが応答監視の指示であるか否か）。応答監視が適切な場合の詳細については、[5]を参照してください。
Blocking (bl): This event is used to indicate an incoming off-hook for the purposes of blocking a one-way trunk in CAS trunks. This event is included for backwards compatibility with the previous version of the package. The preferred alternative is the "block" event in the appropriate CAS packages [34].
（BL）ブロッキング：このイベントは、CASトランクに一方向トランクを遮断する目的のために入ってくるオフフックを示すために使用されます。このイベントは、パッケージの以前のバージョンとの下位互換性のために含まれています。好ましい代替は、適切なCASパッケージ[34]の「ブロック」イベントです。
Busy Tone (bz): Refer to ITU-T E.180 [8]. In North America, station Busy is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.5 seconds on, followed by 0.5 seconds off, then repeating. See GR-506-CORE [7]- LSSGR: SIGNALING, Section 17.2.6.
ビジートーン（BZ）：[8] ITU-T E.180を参照してください。北米では、ビジー局は-21 dBmでの合成レベルを与えるために480と620ヘルツの周波数および-24 dBmのそれぞれのレベルを有する2つのACトーンの組み合わせです。ステーションビジートーン用ケイデンスは、その後繰り返し、オフ0.5秒、続いて、0.5秒です。 SIGNALING、セクション17.2.6：LSSGR - GR-506-CORE [7]を参照。
Continuity Tone (co1): A tone at 2010 Hz (see section 3.1.1.3 of [2]). When generated as a signal, the frequency of the tone must be within + or - 8 Hz, while the frequency of the tone corresponding to the event must be within + or - 30 Hz.
連続トーン（CO1）：2010 Hzのトーン（[2]のセクション3.1.1.3を参照）。 30ヘルツ - イベントに対応するトーンの周波数が+または以内でなければならないが、8ヘルツ - 信号として生成するとき、トーンの周波数は+または内になければなりません。
Continuity Test (co2): A tone at 1780 Hz (see section 3.1.1.3 of [2]). When generated as a signal, the frequency of the tone must be within + or - 20 Hz, while the frequency of the tone corresponding to the event must be within + or - 30 Hz.
連続テスト（CO2）：1780 Hzのトーン（[2]のセクション3.1.1.3を参照）。 30ヘルツ - イベントに対応するトーンの周波数が+または以内でなければならないが、20ヘルツ - 信号として生成するとき、トーンの周波数は+または内になければなりません。
In continuity testing the tone corresponding to the signal at the originating gateway is referred to as the "go" tone, and the tone corresponding to the event at that same gateway is referred to as the "return" or "check" tone.
発信ゲートウェイの信号に対応するトーンをテスト連続で「GO」トーンと呼ばれ、その同じゲートウェイでのイベントに対応するトーンは、「戻る」または「チェック」トーンと呼ばれます。
Note that generation and notification of continuity tones are done as per continuity test requirements as defined in ITU-T Q.724 [3], as well as by Bellcore GR-317-CORE [2] specifications, i.e., the semantics of notification of the return tone is more than that the tone was received, but is an indication that the test has passed. Details are provided in the following paragraphs.
ITU-T Q.724で定義されるように連続トーンの発生と通知を導通試験の必要条件に従って行われる注意[3]、並びにの通知のベルコアGR-317-CORE [2]仕様、すなわち、意味論によってリターントーンはトーンを受信したことよりもですが、テストに合格していることの指標です。詳細は以下の段落で提供されています。
The continuity tones represented by co1 and co2 are used when the Call Agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone; In the case of the dual tone, either tone can be sent and the opposite received depending on the trunk interconnections (4-wire or 2-wire) as indicated below:
CO1とCO2に代表される連続トーンは、コールエージェントが導通試験を開始したいときに使用されています。テスト、シングルトーンとデュアルトーンの2種類があります。デュアルトーンの場合に、トーンを送信することができ、以下に示すように反対の（4線式または2線式）トランク相互接続に応じて受信された次のいずれか
Originating Terminating
============ ===========
4w -------------- 1780 Hz -----------> 2w
<------------- 2010 Hz ------------ (transponder)
2w -------------- 2010 Hz -----------> 2w/4w
<------------- 1780 Hz ------------ (transponder)
4w -------------- 2010 Hz -----------> 4w
<------------- 2010 Hz ------------ (loopback)
The Call agent is expected to know, through provisioning information, which test should be applied to a given endpoint. As an example, for a 4-wire to 2-wire connection, the Call Agent might send a request like the following to an originating gateway:
コールエージェントは、特定のエンドポイントに適用されなければならないテストプロビジョニング情報を通じて、知っていることが予想されます。一例として、4線式2線に接続するために、Callエージェントは、発信ゲートウェイに次のようなリクエストを送信するかもしれません。
RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: t/co1 R: t/co2,t/oc,t/of
RQNT 1234 ds/ds1-1/17@tgw2.example.net X：AB123FE0 S：T / CO1のR：T / CO 2、T / OC、T /の
On a terminating side of a trunk, the call agent may request a continuity test connection (connection mode "conttest") to the terminating gateway as follows:
次のようにトランクの終端側に、コールエージェントは、終端ゲートウェイに導通試験接続（接続モード「conttest」）を要求することができます。
CRCX 3001 ds/ds1-2/4@tgw34.example.net C: 3748ABC364 M: conttest
CRCX 3001 ds/ds1-2/4@tgw34.example.netのC：3748ABC364 M：conttest
Alternatively, rather than using a connection mode, the "T/ct" signal can be used (see description of this signal further below):
あるいは、むしろ接続モードを使用するよりも、「T / CT」信号を使用することができる（以下でさらに、この信号の説明を参照）。
RQNT 3001 ds/ds1-2/4@tgw34.example.net X: 1233472 S: t/ct(in=co1,out=co2,+)
RQNT 3001 ds/ds1-2/4@tgw34.example.netのX：1233472のS：T / CT（= CO1 IN、OUT = CO 2、+）
The originating gateway would send the requested "go" tone, and would look for the appropriate "return tone". Once the return tone is received, the originating gateway removes the go tone and checks to see that the return tone has been removed within the specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B [23]). When it detects that the test is successful, the gateway will send a notification of the return tone event (Note that notification of the return tone event therefore must not be sent prior to detection of the removal of the return tone).
発信ゲートウェイは、要求された「行く」トーンを送信し、適切な「リターン・トーン」を探します。リターントーンが受信されると、発信側ゲートウェイはリターントーンは、指定された性能限界内で除去されたことを見に行く音とチェックを除去する（すなわち、GR-246-CORE、T1.113.4、附属書B [23]）。それはテストが成功したことを検出すると、ゲートウェイはリターントーンイベントの通知を送信する（前リターントーンの除去の検出に送信してはならない、したがってリターントーンイベントの通知に注意してください）。
The "T/co1" and "T/co2" signals are TO signals so that an operation complete event will occur when the signal times out. If a timeout value other than the default is desired, the "to" parameter may be used (e.g., "S: T/co1(to=2000)").
動作完了イベントが出たときに、信号の時間を生じるように、「T / CO1」と「T / CO2」の信号が信号にあります。 （例えば、「T / CO1（= 2000）S」）をデフォルト以外のタイムアウト値が所望される場合、パラメータが使用されてもよい「から」。
If the gateway detects the failure of the continuity test prior to the timeout, an operation failure event will be generated. Otherwise, the failure of the continuity test is determined by the failure to receive the return tone event before the timeout occurs (operation complete event). As with TO signals in general, operation complete and operation fail events are parameterized with the name of the signal.
ゲートウェイがタイムアウトする前に導通試験の失敗を検出した場合、動作不良イベントが生成されます。それ以外の場合は、導通試験の失敗はタイムアウトが（動作完了イベント）を発生する前にリターントーンイベントを受信するための障害によって決定されます。一般的な、操作完了し、操作が失敗の信号TOと同じようなイベントは、信号の名前でパラメータ化されています。
In the example above where the go tone is "co1" and the return tone is "co2":
ゴー音が「CO1」であるとリターントーンが「CO2」です上記の例では：
* A notification of the "co2" event indicates success (i.e., "O: t/co2").
* "CO2" イベントの通知が成功を示す（すなわち、 "O：T / CO 2"）。
* A notification of the operation failure event indicates failure prior to timeout (i.e., "O: t/of(t/co1)").
*動作不良イベントの通知が失敗タイムアウトの前に（すなわち、「Oを：T /（T / CO1）の」）を示しています。
* A notification of the operation complete event indicates that the return tone was not received properly prior to the occurrence of the timeout (i.e., "O: t/oc(t/co2)").
（「T / OC（T / CO）O」、すなわち、）*動作完了イベントの通知がリターントーンが前タイムアウトの発生に正しく受信されなかったことを示しています。
On a terminating end of a trunk, either a "loopback" connection (single tone test) or "conttest" connection (dual tone test) is made (or alternatively the "T/lb" or "T/ct" signals are requested). It is up to the termination end to make sure that the return tone is removed as soon as the go tone disappears. The
トランク、いずれかの「ループバック」接続（シングルトーンテスト）または「conttest」接続（デュアルトーンテスト）の終端部に形成されている（あるいは「T / LB」または「T / CT」信号が要求されます） 。これは、リターントーンが、すぐに行く音が消えるように除去されていることを確認するために終端までです。ザ・
Call Agent requests the removal of "contest" or "loopback" connections (or "T/lb" or "T/ct" signals) at a termination end when the results of the continuity test are obtained.
呼び出し導通試験の結果が得られたときにエージェントが終了端で「コンテスト」または「ループバック」接続（または「T / LB」または「T / CT」信号）を除去することを要求します。
When "conttest" is used, the endpoint is provisioned as to which transponder test is being performed (2010 Hz received and 1780 Hz sent or vice versa). In the case of the corresponding "T/ct" signal, the Call Agent can specify which tone is received and sent as parameters.
「conttest」が使用されるときにトランスポンダ試験が行われているように、エンドポイントをプロビジョニングする（2010ヘルツを受信し1780ヘルツ送信されるか、またはその逆）。対応する「T / CT」信号の場合には、コールエージェントは、受信したパラメータとして送信されたトーンを指定することができます。
Note that continuity tones in the trunk package are only ever sent to the telephony endpoint. For network-based continuity, there are continuity tones available in the RTP ("R") package. Although a transponder (dual tone) test can be done, a single tone test is generally sufficient in the case of continuity testing across an IP network.
トランクパッケージの連続トーンがしかテレフォニーエンドポイントに送信されることに注意してください。ネットワークベースの連続性のために、RTP（「R」）パッケージで利用可能な連続トーンがあります。トランスポンダ（デュアルトーン）テストを行うことができるが、シングルトーンテストは、IPネットワークを介して導通試験の場合には一般に十分です。
Continuity Transponder(ct(in=<tone-in>,out=<tone-out>, <+ or ->)): This signal is used to provide transponder functionality independent of the connection mode, i.e., this is an alternative way to provide the same functionality as the "conttest" connection mode. The parameters can be provided in any order. The <tone-in> and <tone-out> parameters can have values "co1" or "co2", corresponding to the 2010 Hz and 1780 Hz tones associated with those symbols. If one of the tones is "co1", then the other must be "co2" and vice versa (i.e., <tone-in> and <tone-out> must have different values; if loopback is required, then the "lb" signal in this package or "loopback" connection mode should be used).
連続トランスポンダ（CTが（= <トーンで> IN、OUT = <トーンアウト>、<+または - >））：この信号は、接続モードのトランスポンダ機能の独立、すなわちを提供するために使用され、これは別の方法であります「conttest」接続モードと同じ機能を提供します。パラメータは任意の順序で提供することができます。 <トーンで>および<トーンアウト>パラメータ2010ヘルツおよびそれらのシンボルに関連付けられた1780 Hzのトーンに対応し、値「CO1」または「CO 2」を有することができます。トーンの一つが「CO1」である場合、他方は「CO2」、またはその逆でなければならない（すなわち、<トーンで>および<トーンアウト>異なる値を有していなければならない、ループバックが必要な場合は、「LB」このパッケージまたは「ループバック」接続モードでの信号を使用する必要があります）。
On detecting <tone-in>, <tone-out> will be generated in return. The tone corresponding to <tone-out> will continue to be generated until either:
<トーンで>を検出すると、<トーンアウトは>リターンで生成されます。 <トーン・アウト>に対応する音がするまで、生成され続けます。
* The signal is explicitly turned off (e.g., "S: t/ct(-)") or
*信号は、明示的にオフ（例えば、 "S：T / CT（ - ）"）されるか、または
* Removal of the <tone-in> tone is detected.
* <トーンで>トーンの除去が検出されました。
Note that while the signal is active (regardless of whether a tone is active or not), media from the endpoint will not be forwarded to or from the packet network (i.e., the continuity transponder signal must be explicitly turned off by the Call Agent in order to resume passing media between the packet network and the endpoint).
信号が（関係なく、トーンがアクティブであるかどうかの）アクティブである間に、エンドポイントからのメディアがまたはパケットネットワークから転送されないことに注意してください（すなわち、継続トランスポンダ信号は、明示的にコールエージェントでオフにする必要がありますパケットネットワークとエンドポイントの間を通過するメディアを再開するため）。
Loopback (lb): This signal is used to provide loopback functionality independent of the connection mode, i.e., this is an alternative way to provide the same functionality as "loopback" connection mode.
ループバック（LB）：この信号は、すなわち、これは「ループバック」接続モードと同じ機能を提供する別の方法で、接続モードのループバック機能の独立を提供するために使用されます。
Note that while the loop-back signal is active (regardless of whether a tone is active or not), media from the endpoint will not be forwarded to or from the packet network (i.e., the loopback signal must be explicitly turned off by the Call Agent in order to resume passing media between the packet network and the endpoint).
ループバック信号が（関係なく、トーンがアクティブであるかどうかの）アクティブである間に、エンドポイントからのメディアがまたはパケットネットワークから転送されないことに注意してください（すなわち、ループバック信号は、明示的にコールすることによってオフにする必要がありますパケット・ネットワークとエンドポイントの間を通過するメディアを再開するために、エージェント）。
New Milliwatt Tone (nm): 1004 Hz tone - refer to [4] and section 8.2.5 of [5].
新しいミリワットトーン（NM）：1004 Hzのトーン - を参照し[4]、[5]のセクション8.2.5。
Newest Milliwatt Tone (mm): 1013.8 Hz - refer to [4].
最新ミリワットトーン（MM）：1013.8ヘルツ - [4]を参照。
Operation Complete (oc): This is the standard definition of operation complete [1].
動作完了（OC）：これは完全な操作の標準的な定義である[1]。
Operation Failure (of): This is the standard definition of operation failure [1].
動作不良（の）：これは、動作不良、[1]の標準的な定義です。
Old Milliwatt Tone (om): 1000 Hz tone - refer to [4] and section 8.2.5 of [5].
古いミリワットトーン（OM）：1000Hzのトーン - [4]及び[5]のセクション8.2.5を参照。
Permanent Signal Tone (pst): In North America, this tone is applied to a busy line verify/operator interrupt under specific circumstances as described in [17].
永久的な信号音（PST）：北米では、このトーンは、[17]に記載されているように確認/オペレータは、特定の状況下で割り込みビジーラインに印加されます。
Quiet Termination (qt): Quiet Termination is used in a 102 trunk test. Reference section 6.20.5 [5] as well as [4].
静かな終端（QT）：静かな終端102トランク試験に使用されます。基準セクション6.20.5 [5]と同様に[4]。
Reorder Tone(ro): This maps to congestion tone in the ITU-T E.182 specification. In North America, reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for reorder tone is 0.25 seconds on, followed by 0.25 seconds off, repeating continuously (until time-out). See GR-506-CORE [7], Section 17.2.7.
リオーダートーン（RO）：これはITU-T E.182仕様の混雑トーンにマッピングされます。北米では、-21 dBmでの合成レベルを与えるために、トーン480及び620ヘルツの周波数および-24 dBmの各々のレベルを有する2つの交流トーンの組み合わせで並べ替えます。リオーダートーンのためのリズムが継続的に繰り返し、オフ0.25秒に続いて、0.25秒である（タイムアウトまで）。セクション17.2.7、[7] GR-506-COREを参照。
Special Information Tone(sit(#)): As described in ITU-T E.180 [8], the special information tone consists of a tone period in which 3 tones are produced followed by a silent period of 1 second (total TO period of approximately 2 seconds). When used as a signal, it MUST be parameterized with a parameter value from 1 to 7, with the following meaning as defined in SR-2275, section 6.21.2 of [5].
特別な情報トーン（SIT（＃））：ITU-T E.180に記載されているように[8]、特別な情報トーンが期間1秒（トータルのサイレント期間が続く3つのトーンが生成されたトーンの期間で構成され約2秒）。信号として使用する場合、それは[5]のセクション6.21.2、SR-2275で定義されるように、以下の意味で、1から7までのパラメータ値を用いてパラメータ化されなければなりません。
-------------------------------------------
| sit(1) | RO' | reorder SIT, intra-LATA |
| sit(2) | RO" | reorder SIT, inter-LATA |
| sit(3) | NC' | no circuit SIT, intra-LATA |
| sit(4) | NC" | no circuit SIT, inter-LATA |
| sit(5) | IC | intercept SIT |
| sit(6) | VC | vacant code SIT |
| sit(7) | IO | ineffective other SIT |
-------------------------------------------
When requested as an event, the event MUST be parameterized with a decimal number from 1 to 7 to indicate which tone the gateway is required to detect. The resulting notification also includes the parameter. Other countries may have one or more special information tones with country specific definitions (refer to ITU-T E.180 supp. 2 [9]). In this case, special information tone 1 as defined in [9] is sit(1), special information tone 2 is sit(2) etc.
イベントとして要求された場合、イベントは、ゲートウェイを検出するために必要なトーンを示すために、1から7まで進数でパラメータ化されなければなりません。得られた通知は、パラメータを含みます。他の国は、（ITU-T E.180サップを指す。2 [9]）国特定の定義を有する1つ以上の特別な情報トーンを有していてもよいです。この場合、特別な情報トーン1は、[9]で座る（1）、特別情報トーン2が座る（2）等で定義されています
As an example, the Call Agent might make a request such as:
例として、コールエージェントは、要求をようになるかもしれません。
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
R: t/sit(N)(2)
If the tone is detected, the resulting notification might appear as follows:
トーンが検出された場合は、次のように、結果の通知が表示されることがあります。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: AB123FE0
O: t/sit(2)
Test Line (tl): 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0). Refer to section 8.2.5 of [5].
テストライン（TL）：105テスト回線テスト進行トーン（2225ヘルツ+又は - -10 dBm0では25ヘルツ）。 [5]のセクション8.2.5を参照。
Test Pattern (tp(###)): The tp(###) signal inserts the pattern ### continuously into the channel until the timeout period expires. The parameter is provided as a decimal number from 0 to 255. If the parameter is omitted, the default value is decimal 95.
テストパターン（TP（###））：TPタイムアウト期間が満了するまで（###）、信号は###連続チャネル内にパターンを挿入します。パラメータが省略された場合、パラメータは、0から255までの10進数として提供され、デフォルト値は95進です。
In RequestedEvents, the parameter MAY be supplied to indicate what pattern the Call Agent wishes the gateway to detect. If the parameter is omitted, the value 95 is assumed. The pattern MUST be returned in the ObservedEvent (even if the parameter was not requested).
RequestedEventsでは、パラメータは、コールエージェントが検出するゲートウェイを望んで何パターンを示すに供給することができます。パラメータを省略すると、値95を想定しています。パターンは（パラメータが要求されなかった場合でも）ObservedEventで返さなければなりません。
A typical use for the test pattern signal is for the test line 108 (digital loopback) test (refer to section 8.2.5 of [5]). At the termination side of a trunk, the Call Agent would request a connection in "loopback" mode, which would do a digital loopback. On the origination side of the trunk, the Call Agent would request that the test pattern be injected into the digital channel, and would check to see that the pattern was returned within the timeout period. As an example, the Call Agent would make the following request on the origination side:
テストパターン信号のための典型的な用途は、テストライン108（デジタルループバック）テスト（[5]のセクション8.2.5を参照）のためのものです。トランクの終端側では、コールエージェントは、デジタルループバックを行うだろう「ループバック」モードでの接続を要求します。トランクの発信側では、コールエージェントは、テストパターンがデジタルチャンネルに注入されることを要求すると、パターンがタイムアウト期間内に返されたことを確認します。例として、コールエージェントは、発信側で、次に掲げる請求をすることになります。
RQNT 1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: t/tp R: t/tp, t/oc, t/of
RQNT 1234 ds/ds1-1/17@tgw2.example.netのX：AB123FE0 S：T / TP R：T / TP、T / OC、T /の
In this case the Call Agent will either receive:
この場合、コールエージェントは、受信しますか：
* An ObservedEvent indicating that the test has passed (i.e., "O:t/op(95)") or
*テストに合格したことを示すObservedEvent（すなわち、 "O：T / OP（95）"）または
* An ObservedEvent indicating that the timeout occurred before the pattern was received (i.e., "O:t/oc(t/tp)"), indicating that the test failed. Of course an operation failure would indicate failure as well.
テストが失敗したことを示す、：パターンが受信される前にタイムアウトが発生したことを示す* ObservedEvent（すなわち、「T / OC（T / TP）O」）。もちろん、動作不良にも失敗したことを示すことになります。
No Circuit (zz): This is an alias for Special Information Tone 2, i.e., "sit(2)".
いいえサーキット（ZZ）：これはすなわち、「（2）座る」、特別な情報トーン2の別名ではありません。
Package Name: L Version: 1
パッケージ名：Lバージョン：1
----------------------------------------------------------------
|Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
|adsi(string) | ADSI Display | | BR |
|aw | Answer Tone | x | OO |
|bz | Busy Tone | | TO 30 sec. |
|ci(ti,nu,na) | Caller-id | | BR |
|dl | Dial Tone | | TO 16 sec. |
|e | Error Tone | x | TO 2 sec. |
|hd | Off-hook Transition | S | |
|hf | Flash-hook | x | |
|ht | On Hold Tone | | OO |
|hu | On-hook Transition | S | |
|lsa | Line Side Answer Sup. | | OO |
|mwi | Message Waiting ind. | | TO 16 sec. |
|nbz | Network busy | x | TO infinite |
|oc | Operation Complete | x | |
|of | Operation Failure | x | |
|osi | Network Disconnect | | TO 900 ms |
|ot | Off-hook Warning Tone | | TO infinite |
|p | Prompt Tone | x | BR |
|rg | Ringing | | TO 180 sec. |
|r0, r1, r2, | Distinctive Ringing | | TO 180 sec. |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|ro | Reorder Tone | | TO 30 sec. |
|rs | Ringsplash | | BR |
|s(###) | Distinctive Tone Pattern | x | BR |
|sit(#) | Special Information Tone | | TO 2 sec. |
| | | | (see notes) |
|sl | Stutter Dial Tone | | TO 16 sec. |
|v | Alerting Tone | | OO |
|vmwi | Visual Message | | OO |
| | Waiting Indicator | | |
|wt | Call Waiting Tone | | TO 12 sec |
|wt1, wt2, | Alternative Call | | TO 12 sec |
|wt3, wt4 | Waiting Tones | | (see notes) |
|y | Recorder Warning Tone | | TO infinite |
|z | Calling Card Service Tone| | BR |
----------------------------------------------------------------
New events added to this package from the previously unversioned package: "ht", "osi", and "lsa".
「HT」、「OSI」、および「LSA」：新しいイベントが以前にバージョン管理外のパッケージからこのパッケージに追加しました。
Changes in event types: signals "y", "z", changed from OO to TO and BR respectively. Ringing tones were extended to allow for a ring repetition signal parameter.
イベントタイプの変化：信号「Y」、「Z」は、それぞれ及びBRするOOから変更しました。着信音は、リング繰り返し信号パラメータを可能にするように拡張されました。
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトのタイムアウト値「が」信号パラメータによって、このパッケージで定義された任意のタイム・アウト信号のためのコールエージェントによって上だらけであってもよいことに注意してください。詳細については、この文書のセクション2を参照して、ならびに[1]。
The description of events and signals in the line package are as follows:
次のように行パッケージのイベントと信号の説明は次のとおりです。
ADSI Display (adsi): This signal is included here to maintain compatibility with the previous version of this package. The signal is not well-defined and its use is discouraged.
ADSIディスプレイ（ADSI）：この信号は、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。信号は、明確に定義され、その使用が推奨されていません。
Answer Tone (aw): This event is included here to maintain compatibility with the previous version of this package. The event is not well-defined and its use is discouraged.
トーン回答（AW）：このイベントは、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。イベントは、明確に定義され、その使用が推奨されていません。
Busy Tone (bz): Refer to ITU-T E.180 [8]. In North America, station Busy is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.5 seconds on followed by 0.5 seconds off, repeating. See GR-506-CORE [7], Section 17.2.6. It is considered an error to try and play busy tone on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
ビジートーン（BZ）：[8] ITU-T E.180を参照してください。北米では、ビジー局は-21 dBmでの合成レベルを与えるために480と620ヘルツの周波数および-24 dBmのそれぞれのレベルを有する2つのACトーンの組み合わせです。ステーションビジートーン用ケイデンスは繰り返し、オフ0.5秒、続いて上に0.5秒です。セクション17.2.6、[7] GR-506-COREを参照。これは試してみて、オンフックであり、そのような試みが行われたときにエラーが結果的に（ - 電話オンフックエラーコード402）返されなければならない電話で話中音を再生するには、エラーと考えられています。
Caller-id (ci(time, number, name)): See GR-1188 [24], GR-30-CORE [14], and GR-31 [25]. For backwards compatibility, each of the three fields are optional, but each of the commas will always be included. In accordance with the general MGCP grammar, it is RECOMMENDED to always include all three fields - an empty quoted string can then be used in lieu of omitting a parameter:
発信者ID（CI（時間、番号、名前））、GR-30-CORE [14]、およびGR-31 [25] GR-1188 [24]を参照してください。後方互換性のために、三つのフィールドのそれぞれはオプションですが、コンマのそれぞれが常に含まれます。一般的なMGCP文法に従い、それは常にすべての3つのフィールドを含めることを推奨する - 空の引用符で囲まれた文字列は、パラメータを省略の代わりに使用することができます。
The time parameter is coded as "MM/DD/HH/MM", where MM is a two-digit decimal value for a Month between 01 and 12, DD is a two-digit value for a Day between 01 and 31, and Hour and Minute are two-digit values coded according to military local time, e.g., 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m. (Note: two digits MUST always be provided for each of the values of month, day, hour, minutes e.g., the month of January is indicated by the two digits "01" rather than just "1").
MMは、01と12の間の月のための2桁の10進値であるパラメータは、「MM / DD / HH / MM」として符号化される時間は、DDは2桁の01と31の間の日の値、及び時間でありますそしてミニッツの01は午前1時で、13は午後1時で、00は真夜中で、例えば、軍事現地時間に応じてコード化された2桁の値であり、 （注：2桁は常に月の値のそれぞれに設けられなければならない、日、時、分は、例えば、1月は2桁で示されている「01」だけでなく「1」）。
The number parameter is coded as an ASCII character string of decimal digits that identify the calling line number. White spaces are permitted if the string is quoted, but they will be ignored. If a quoted-string is provided, the string itself is UTF-8 encoded (RFC 2279) as usual for signal parameters.
数パラメータは、呼び出し元の行番号を識別する桁のASCII文字列として符号化されます。ホワイトスペースは、文字列が引用されている場合は許可されていますが、それらは無視されます。引用符で囲まれた文字列が提供されている場合、文字列自体は、UTF-8でエンコードされ（RFC 2279）の信号パラメータのための通常の通りです。
The name parameter is coded as a string of ASCII characters that identify the calling line name. White spaces are permitted if the string is quoted. If a quoted-string is provided, the string itself is UTF-8 encoded (RFC 2279).
nameパラメータは、呼び出し元のライン名を識別するASCII文字の文字列として符号化されます。文字列が引用されている場合、ホワイトスペースが許可されています。引用符で囲まれた文字列が提供されている場合、文字列自体は、UTF-8でエンコードされ（RFC 2279）です。
A "P" in the number or name field is used to indicate a private number or name, and an "O" is used to indicate an unavailable number or name. Other letters MAY be used to provide additional clarification as per provider or vendor specifications.
番号または名前フィールドに「P」は、プライベート番号または名前を示すために使用され、そして「O」が利用できない番号または名前を示すために使用されます。その他の文字は、プロバイダまたはベンダーの仕様に従って、追加の説明を提供するために使用され得ます。
The following example illustrates the use of the caller-id signal:
次の例では、発信者ID信号の使用を示します。
S: l/ci(09/14/17/26, "555 1212", "John Doe")
S：L / CI（09/14/17/26、 "555 1212"、 "ジョン・ドウ"）
An example indicating that the name and number are private:
名前と番号がプライベートであることを示す例：
S: l/ci(09/14/17/26,P,P)
S：L / C（09/14/17/26、P、P）
Dial Tone (dl): Refer to the ITU-T E.180 [8] specification. In North America, dial tone is a combination of two continuous AC tones with frequencies of 350 and 440 Hertz and levels of -13dBm each, to give a combined level of -10 dBm. See GR-506-CORE [7] - LSSGR: SIGNALING, Section 17.2.1. It is considered an error to try and play dial-tone on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
トーン（DL）をダイヤル：ITU-T E.180 [8]仕様を参照してください。北米では、-10 dBmでの合成レベルを与えるために、トーン350及び440ヘルツの周波数および-13dBmそれぞれのレベルを有する2つの連続したACトーンの組み合わせであるダイアル。 SIGNALING、セクション17.2.1：LSSGR - GR-506-CORE [7]を参照。これは試してみて、オンフックであり、そのような試みが行われたときにエラーが結果的に（ - 電話オンフックエラーコード402）返されなければならない携帯電話にダイヤルトーンを再生するには、エラーと考えられています。
Error Tone (e): This tone is maintained for backwards compatibility. The tone is not well defined and its use is discouraged.
エラートーン（E）：このトーンは、後方互換性のために維持されています。トーンは十分に定義されていない、その使用は推奨されません。
Off-hook Transition (hd): See GR-506-CORE [7], Section 12. It is considered an error to try and request off-hook on a phone that is off-hook and an error MUST consequently be returned when such attempts are made (error code 401 - phone off-hook).
オフフック遷移（HD）：試してみて、オフフックである電話でオフフック要求するエラーであると考えられるとき、このようなエラーが結果として返さなければなりません、[7] GR-506-COREを参照セクション12試みが（ - オフフック電話エラーコード401）が行われます。
Flash Hook (hf): See GR-506-CORE [7], Section 12. It is considered an error to try and request flash hook on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
フラッシュフック（HF）：GR-506-CORE [7]に、セクション12は、それを試して、エラーとみなされ、そのような試みが行われたときにフックである電話やエラーに要求フラッシュフックが結果として返さなければなりません見ます（エラーコード402 - オンフック電話）。
Tone On Hold (ht): A tone used to reassure a calling subscriber who has been placed on "hold". Refer to ITU-T E.182 [10].
保留音（HT）：「ホールド」に置かれた発呼加入者を安心させるために使用されるトーン。 ITU-T E.182 [10]を参照。
On-hook Transition (hu): See GR-506-CORE [7], Section 12. The timing for the on-hook signal is for flash response enabled, unless provisioned otherwise. It is considered an error to try and request flash hook on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
オンフック遷移（HU）：GR-506-COREを参照してください[7]、オンフック信号については、セクション12のタイミングは、他にプロビジョニングしない限り、有効フラッシュ応答のためのものです。これは、オンフックであり、そのような試みがなされている時にエラーが結果として（ - 電話機のオンフックエラーコード402）が返されなければならない電話にしようとするエラーと要求フラッシュフックであると考えられます。
Line Side Answer Supervision (lsa): This provides Reverse Loop Current Feed (RLCF) on the line (refer to GR-506-CORE [7]) and is a way of indicating that the called party has answered for some line-side equipment.
回線側の応答監視（LSA）：これはライン上にリバースループ電流給電（RLCF）を提供（参照GR-506-CORE [7]）と呼ばれるパーティーは、いくつかのライン側の機器のために応答したことを示すの方法です。 。
Message Waiting Indicator (mwi): Message Waiting indicator tone uses the same frequencies and levels as dial tone (350 and 440 Hertz at -13dBm each), but with a cadence of 0.1 second on, 0.1 second off, repeated 10 times, followed by steady application of dial tone. See GR-506-CORE [7], Section 17.2.3. It is considered an error to try and play message-waiting indicator on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
メッセージ待機インジケータ（MWI）：メッセージ待機インジケータトーンがダイヤルトーン（350とで-13dBmそれぞれ440ヘルツ）と同じ周波数およびレベルを使用するが、0.1秒でのリズムで、0.1秒オフは、続いて、10回繰り返しダイヤルトーンの着実なアプリケーション。 GR-506-COREを参照し[7]、セクション17.2.3。これは試してみて、オンフックであり、そのような試みがなされている時にエラーが結果として（ - 電話機のオンフックエラーコード402）が返されなければならない携帯電話にメッセージ待機インジケータを再生するエラーであると考えられます。
Network Busy (nbz): This is included here to maintain compatibility with the previous version of this package. The "nbz" signal is an alias for re-order tone signal("ro"). Future Call Agent implementations that require a network busy signal should use the "ro" signal. It is also recommended that future Call Agents not request to be notified of the "nbz" event (a network busy event is generally not required in a line package; hence, "ro" is only a signal, not an event).
ネットワークビジー（NBZは）：これは、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。 「NBZ」信号は、再オーダートーン信号（「RO」）の別名です。ネットワークビジー信号を必要とし、将来のコールエージェントの実装は、「RO」信号を使用する必要があります。また、将来のコールエージェントは「NBZ」イベントが通知されるように要求しないことをお勧めします（ネットワーク忙しいイベントは、一般的にラインパッケージで必要とされていない。それゆえ、「RO」は信号だけではなく、イベントです）。
Operation Complete (oc): This is the standard definition of operation complete [1].
動作完了（OC）：これは完全な操作の標準的な定義である[1]。
Operation Failure (of): This is the standard definition of operation failure [1].
動作不良（の）：これは、動作不良、[1]の標準的な定義です。
Network Disconnect (osi): Network Disconnect indicates that the far-end party has disconnected. The signal that is sent on the line is provisioned in the media gateway since it may vary from country to country. In North America, this signal is an open switch interval which results in a Loop Current Feed Open Signal (LCFO) being applied to the line (refer to GR-506-CORE [7], see also See GR-505-CORE [6], Section 4.5.2.1). The default time-out value for this signal is 900 ms.
ネットワークの切断（OSI）：ネットワークの切断は、遠端のパーティが切断されたことを示しています。それは国によって異なることがあるのでライン上で送信された信号は、メディアゲートウェイでプロビジョニングされます。北米では、この信号はライン（[GR-506-CORE [7]、また見るGR-505-CORE 6参照に適用される開信号（LCFO）をフィードループ電流をもたらすオープンスイッチの間隔であります]、セクション4.5.2.1）。この信号のデフォルトのタイムアウト値は900ミリ秒です。
Off-hook Warning Tone (ot): Off-hook warning tone, also known as receiver Off-Hook Tone (ROH Tone). This is the irritating noise a telephone makes when it is not hung up correctly. In North America, ROH Tone is generated by combining four tones at frequencies of 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600 Hertz, at a cadence of 0.1 second on, 0.1 second off, then repeating. GR-506-CORE [7], Section 17.2.8 contains details about required power levels. It is considered an error to try and play off-hook warning tone on a phone that is on-hook, and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
また、受信機オフフックトーン（ROHトーン）として知られているオフフック警告音、：オフフック警告音（OT）。これは、それが正しくハングアップされていない場合に電話が作る刺激性のノイズです。北米においては、ROHトーンは、次いで、0.1秒オン、0.1秒オフのリズムで1400ヘルツ、2060ヘルツ、2450ヘルツ2600ヘルツの周波数で4つのトーンを組み合わせる繰り返すことによって生成されます。 GR-506-CORE [7]、セクション17.2.8は、必要とされる電力レベルの詳細を含んでいます。 （ - オンフック電話をエラーコード402）試してみて、オンフック電話でオフフック警告音を再生するには、エラーとみなされ、そして、そのような試みが行われたときにエラーが結果的に返さなければなりません。
Prompt Tone (p): The definition of the prompt tone and its use may be found in requirement GR-220 [20]. The tone in GR-220 (requirement "R3-170" or GR-220) is a 300 ms burst of a 400 Hz tone.
プロンプトトーン（P）：プロンプトトーンの定義およびその使用は要件GR-220に見出すことができる[20]。 GR-220におけるトーン（要件 "R3-170" 又はGR-220）は、400 Hzのトーンバースト300ミリ秒です。
Ringing (rg): See GR-506-CORE [7], Section 14. The provisioning process may define the ringing cadence. The ringing signal may be parameterized with the signal parameter "rep" which specifies the maximum number of ringing cycles (repetitions) to apply. The value for "rep" is specified in decimal and can have any value from 1 to 255. The following will apply the ringing signal for up to 6 ringing cycles:
（RG）のリンギング：セクション14プロビジョニング・プロセスは、リンギングリズムを定義することができる[7] GR-506-COREを参照してください。リンギング信号を適用するために、リンギングサイクル（反復）の最大数を指定する信号パラメータ「担当者」でパラメータ化することができます。 「担当者」の値が小数で指定されており、1から255までの任意の値を持つことができ、最大6つのリンギング・サイクルのためのリンギング信号を印加すれば、以下の通り：
S: l/rg(rep=6)
S：L / RG（REP = 6）
If the "rep" parameter is specified, the signal times-out when the number of repetitions are completed (i.e., an operation complete event can be requested and will occur at the end of the timeout/number of rings).
「担当者」パラメータが指定されている場合は反復回数が完了すると、信号がタイムアウト（即ち、動作完了イベントを要求することができ、リングのタイムアウト/数の終了時に発生します）。
If the "rep" parameter is supplied, then any timeout ("to") value that is included will be ignored, i.e.:
「担当者」パラメータが指定されている場合、含まれている任意のタイムアウト（「へ」）値は、すなわち、無視されます：
S: l/rg(rep=6,to=12000)
S：L / RG（REP = 6、= 12000）
will be treated the same as the previous example where the parameter "to=12000" was not included. Of course, if the "to" parameter is included without the "rep", it will be acted upon i.e.:
「= 12000」パラメータが含まれていなかった前の例と同じように扱われます。 「へ」パラメータが「担当者」せずに含まれている場合はもちろん、それはすなわち作用されます：
S: l/rg(to=12000)
S：L / RG（= 12000）
will ring for 12 seconds.
12秒間鳴ります。
It is considered an error to try and ring a phone that is off-hook and an error MUST consequently be returned when such attempts are made (error code 401 - phone off-hook).
これは試してみて、オフフックであり、そのような試みがなされている時にエラーが結果として（ - 電話のオフフック、エラーコード401）が返されなければならない電話をリングにエラーであると考えられます。
Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): See GR-506-CORE [7], Section 14. Default values for r1 to r5 are as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE [7]. The default values for r0, r6 and r7 are normal ringing (i.e., the same cadence "rg"). The provisioning process may define the ringing cadence for each of these signals. The distinctive ringing signals may be parameterized with the signal parameter "rep" which specifies the maximum number of ringing cycles (repetitions) to apply. The value for "rep" is specified in decimal and can have any value from 1 to 255.
独特リンギング（R0、R1、R2、R3、R4、R5、R6またはR7）：参照GR-506-CORE [7]、R5へR1はセクション14デフォルト値は5に特有の呼び出し音パターン1について定義した通りでありますGR-506-CORE [7]。 R0、R6及びR7のデフォルト値はリンギング正常である（すなわち、同一のリズム「RG」）。プロビジョニング・プロセスは、これらの信号のそれぞれについてリンギングリズムを定義することができます。特徴的なリンギング信号が適用するリンギングサイクル（反復）の最大数を指定する信号パラメータ「担当者」でパラメータ化することができます。 「担当者」の値は、小数で指定されており、1から255までの任意の値を持つことができます。
The following will apply the ringing signal for up to 6 ringing cycles:
以下は、最大6つのリンギング・サイクルのためのリンギング信号を適用します。
S: l/r1(rep=6)
S：L / R1（REP = 6）
If the "rep" parameter is specified, the signal times-out when the number of repetitions are completed (i.e., an operation complete event can be requested and will occur at the end of the timeout/number of rings)
「担当者」パラメータが指定されている場合、信号タイムアウトが繰り返し回数が終了したとき（すなわち、動作完了イベントを要求することができ、リングのタイムアウト/数の終了時に発生します）
If the "rep" parameter is supplied, then any timeout ("to") value that is included will be ignored, i.e.:
「担当者」パラメータが指定されている場合、含まれている任意のタイムアウト（「へ」）値は、すなわち、無視されます：
S: l/r1(rep=6,to=12000)
S：L / R1（REP = 6、= 12000）
will be treated the same as the previous example where the parameter "to=12000" was not included. Of course, if the "to" parameter is included without the "rep", it will be acted upon i.e.:
「= 12000」パラメータが含まれていなかった前の例と同じように扱われます。 「へ」パラメータが「担当者」せずに含まれている場合はもちろん、それはすなわち作用されます：
S: l/r1(to=12000)
S：L / R1（= 12000）
will ring for 12 seconds.
12秒間鳴ります。
It is considered an error to try and ring a phone that is off-hook and an error MUST consequently be returned when such attempts are made (error code 401 - phone off-hook).
これは試してみて、オフフックであり、そのような試みがなされている時にエラーが結果として（ - 電話のオフフック、エラーコード401）が返されなければならない電話をリングにエラーであると考えられます。
Reorder Tone (ro): This maps to congestion tone in the ITU-T E.182 [10] specification. In North America, reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz, and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for reorder tone is 0.25 seconds on, followed by 0.25 seconds off, repeating continuously.
リオーダートーン（RO）：これはITU-T E.182 [10]指定の輻輳トーンにマッピングします。北米では、-21 dBmでの合成レベルを与えるために、トーン480及び620ヘルツの周波数、および-24 dBmの各々のレベルを有する2つの交流トーンの組み合わせで並べ替えます。リオーダートーンのためのリズムは継続的に繰り返し、オフ0.25秒に続いて、0.25秒です。
Ringsplash (rs): Also known as "Reminder ring", this tone is a burst of ringing that may be applied to the physical forwarding line (when idle) to indicate that a call has been forwarded and to remind the user that a Call Forward sub-feature is active. In the US, it is defined to be a 0.5(-0,+0.1) second burst of power ringing (see [11]).
Ringsplash（RS）：また、「リマインダリング」として知られ、このトーンは、物理的な転送ライン（アイドル）呼が転送されたことを示すために、ユーザに思い出させるために適用され得るリンギングのバーストは、そのコール転送サブ機能がアクティブです。米国では、（[11]参照）、リンギング電力の0.5（-0、+ 0.1）第2のバーストであると定義されます。
Distinctive Tone Pattern (s(###)): This is used to signal or detect a tone pattern defined by the parameter where the parameter may have a value from 0 to 999. When specified as an event, the parameter MUST be included. The parameter will also be included when the event is reported. This event (the definition of tones associated with each parameter value) requires special provisioning in the Call Agent and gateway to insure interoperability. This signal is included here to maintain compatibility with the previous version of this package.
独特のトーンパターン（S（###））：これは、パラメータは、イベントとして指定すると、パラメータが含まれなければならない0から999までの値を有することができるパラメータで定義されたトーン・パターンを信号又は検出するために使用されます。イベントが報告されている場合、パラメータも含まれます。このイベント（各パラメータ値に関連付けられたトーンの定義）相互運用性を保証するために、コールエージェントとゲートウェイに特殊なプロビジョニングを必要とします。この信号は、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。
Special Information Tone(sit(#)): As described in ITU-T E.180 [8], the special information tone consists of a tone period in which 3 tones are produced, followed by a silent period of 1 second (total TO period of approximately 2 seconds). It MAY be parameterized with a parameter value from 1 to 7, with the following meaning as defined in SR-2275, section 6.21.2 [5]:
特別な情報トーン（（＃）をSIT）：ITU-T E.180に記載されているように[8]、特別な情報トーンが1秒間（合計のサイレント期間が続く3つのトーンが生成されたトーンの期間、から成ります約2秒の期間）。 SR-2275で定義され、それは以下の意味で、1から7までのパラメータ値を用いてパラメータ化されてもよく、セクション6.21.2 [5]：
-------------------------------------------
| sit(1) | RO' | reorder SIT, intra-LATA |
| sit(2) | RO" | reorder SIT, inter-LATA |
| sit(3) | NC' | no circuit SIT, intra-LATA |
| sit(4) | NC" | no circuit SIT, inter-LATA |
| sit(5) | IC | intercept SIT |
| sit(6) | VC | vacant code SIT |
| sit(7) | IO | ineffective other SIT |
-------------------------------------------
If the parameter is left out, the NC' SIT tone that corresponds to the signal "L/sit(3)" is assumed.
パラメータが省略されている場合は、信号 『L / SIT（3）』に対応するNC」SITトーンが想定されます。
Other countries may have one or more special information tones with country specific definitions (refer to ITU-T E.180 supp. 2 [9]). In this case, special information tone 1 as defined in [9] is sit(1), special information tone 2 is sit(2) etc.
他の国は、（ITU-T E.180サップを指す。2 [9]）国特定の定義を有する1つ以上の特別な情報トーンを有していてもよいです。この場合、特別な情報トーン1は、[9]で座る（1）、特別情報トーン2が座る（2）等で定義されています
Stutter Dial Tone (sl): Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE [7] and "special dial tone" in ITU-T E.182 [10]) is used to confirm some action and request additional input from the user. An example application is to cancel call-waiting, prior to entering a destination address.
スタッターダイヤルトーン何らかのアクションを確認するために使用され、要求（GR-506-CORE [7]とITU-Tの「特別なダイヤルトーン」E.182 [10]においても呼ばリコールダイヤルトーン）：トーン（SL）をダイヤル吃音ユーザーからの追加入力。サンプルアプリケーションは、前の宛先アドレスを入力するには、コールウェイティングをキャンセルすることです。
The stutter dial tone signal may be parameterized with the signal parameter "del", which will specify a delay in milliseconds to apply between the confirmation tone and the dial tone. The parameter can have any value from 0 to 10000 ms, rounded to the nearest non-zero value divisible by 100 (i.e., tenth of a second). The following will apply stutter dial tone with a delay of 1.5 seconds between the confirmation tone and the dial tone:
スタッターダイヤルトーン信号は、確認トーン、ダイヤルトーンとの間に適用するミリ秒の遅延を指定します信号パラメータ「デル」でパラメータ化することができます。パラメータは0〜10000ミリ秒から任意の値を有することができ、100（第2の即ち第10）で割り切れる最も近いゼロ以外の値に丸め。以下は、確認トーン、ダイヤルトーンの間に1.5秒の遅延でスタッターダイヤルトーンを適用します。
S: l/sl(del=1500)
S：L / SL（= 1500〜）
It is considered an error to try and play stutter dial tone on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
これは試してみて、オンフックであり、そのような試みが行われたときにエラーが結果的に（ - 電話オンフックエラーコード402）返されなければならない電話でスタッターダイヤルトーンを再生するには、エラーと考えられています。
Alerting Tone (v): A 440 Hz Tone of a 2 second duration, followed by a 1/2 second of tone every 10 seconds. This event is included for backwards compatibility with the previous version of the package.
アラートトーン（V）：10秒ごとにトーンの1/2秒続く2秒の持続時間の440 Hzのトーン、。このイベントは、パッケージの以前のバージョンとの下位互換性のために含まれています。
Visual Message Waiting Indicator (vmwi): The transmission of the VMWI messages will conform to the requirements in [13] and the CPE guidelines in [12]. Refer also to section 6.6 of GR-30-CORE [14]. VMWI messages will only be sent from the gateway to the attached equipment when the line is idle. If new messages arrive while the line is busy, the VMWI indicator message will be delayed until the line goes back to the idle state. After the gateway restarts, the state of the signal will be "off", and hence the Call Agent MUST refresh the CPE's visual indicator if it is supposed to be "on".
ビジュアルメッセージ待機インジケータ（VMWI）：VMWIメッセージの送信は、[13]での要件と[12]でのCPEのガイドラインに準拠します。 GR-30-CORE [14]のセクション6.6も参照。ラインがアイドル状態のときVMWIメッセージは、接続機器へのゲートウェイから送信されます。回線がビジーである間に新しいメッセージが到着した場合のラインが戻ってアイドル状態になるまで、VMWIインジケータメッセージが遅延されます。ゲートウェイの再起動後、信号の状態が「オフ」になり、「オン」ことになっている場合ので、コール・エージェントは、CPEの視覚的なインジケータを更新する必要があります。
Alternative Call Waiting Tones (wt, wt1, .., wt4): Refer to ITU-T E.180 [8]. For North American tone definitions, refer to GR-506-CORE [7], Section 14.2. "wt" and "wt1" are both aliases for the default Call Waiting tone, which in North America, is a 440-Hz tone applied for 300 plus or minus 50 ms. The tone is then repeated once after 10 seconds.
代替キャッチホントーン（重量、WT1、..、WT4）：[8] ITU-T E.180を参照してください。北米のトーン定義については、GR-506-CORE [7]、セクション14.2を参照してください。 「重量」と「WT1は、」北米で、440 Hzのトーンが300のプラスマイナス50ミリに適用されるトーンを待っているデフォルトのコールのための両方の別名です。トーンはその後、10秒後にもう一度繰り返しています。
These signals are timeout signals with a default timeout value of 12 seconds, which allows the tone to be played twice with a single request (refer to GR-571-CORE [16]). However, there are cases (Requirement R3-73 of GR-575-CORE [18]), in which only a single tone is required. In that case, the Call Agent may make the request with a shorter timeout period to eliminate the second tone (e.g., "S: wt(to=2000)" - which stops the signal after 2 seconds so that the second tone will not occur).
これらの信号は、トーンが単一の要求（GR-571-CORE [16]を参照）で2回再生することを可能にする12秒のデフォルトのタイムアウト値とタイムアウト信号です。しかし、単一のトーンが要求される場合（GR-575-COREの要件R3-73 [18]）があります。第二のトーンが発生しないように、2秒後に信号を停止 - ：その場合は、コールエージェントは、第二のトーン（例えば、「= 2000重量（）S」を排除するために短いタイムアウト時間を要求するようにしてもよいです）。
Signals wt2, wt3 and wt4 are alternates that are used for distinctive call-waiting tone patterns (refer to GR-506-CORE, Section 14.2 [7]. It is considered an error to try and apply call-waiting tone on a phone that is on-hook and an error MUST consequently be returned when such attempts are made (error code 402 - phone on-hook).
信号WT2、WT3とWT4は独特のコールウェイティングトーンパターン（GR-506-CORE、セクション14.2 [7]。それは試してみて、電話でコールウェイティングトーンを適用するには、エラーと考えられている参照のために使用されている交互であることオンフックであり、そのような試みは、（エラーコード402 - オンフック電話）形成されているときにエラーが結果として返されなければなりません。
Recorder Warning Tone(y): Refer to ITU-T E.180 [8] - also Bellcore document SR-2275 [5] section 6.20. When recording equipment is used, this tone is connected to the line to inform the distant party that the conversation is being recorded - typical value used is a 1400 Hz Tone of a 0.5 second duration every 15 seconds.
レコーダ警告音（Y）：[8] ITU-T E.180を参照してください - また、ベルコア文書SR-2275 [5]のセクション6.20。記録装置が使用される場合、このトーンは、会話が記録されている通話相手に通知するためにラインに接続されている - 使用される典型的な値は、15秒ごとに0.5秒の持続時間1400 Hzのトーンです。
Calling Card Service Tone(z): This tone is used to inform the customer that credit card information must be keyed in. Typically, it consists of 60 ms of 941 + 1477 Hz (the DTMF #digit) and 940 ms of 350 + 440 Hz (dial tone), decaying exponentially with a time constant of 200 ms. Refer to Bellcore document SR-2275 [5], section 6.20.
カードサービストーンを呼び出すと、（Z）。このトーンは、クレジットカード情報をキー入力しなければならないことを顧客に通知するために使用される典型的には、941 + 1477ヘルツ（DTMFの#digit）の60ミリ秒と350 + 440の940ミリ秒から成りヘルツ（ダイヤルトーン）、200ミリ秒の時定数で指数関数的に減衰します。 BellcoreのドキュメントSR-2275 [5]、セクション6.20を参照してください。
Package Name: H Version: 1
パッケージ名：Hバージョン：1
----------------------------------------------------------------
|Symbol | Definition | R | S Duration |
|----------------------------------------------------------------|
|adsi(string) | ADSI Display | x | BR |
|aw | Answer Tone | x | OO |
|bz | Busy Tone | x | TO 30 sec. |
|ci(ti,nu,na) | Caller-id | x | BR |
|dl | Dial Tone | x | TO 16 sec. |
|e | Error Tone | x | TO 2 sec. |
|hd | Off-hook Transition | S | BR |
|hu | On-hook Transition | S | BR |
|hf | Flash Hook | x | BR |
|ht | Tone On Hold | x | OO |
|lsa | Line Side Answer Sup. | x | OO |
|mwi | Message Waiting Ind. | x | TO 16 sec. |
|nbz | Network Busy | x | TO infinite |
|oc | Operation Complete | x | |
|ot | Off-hook Warning Tone | x | TO infinite |
|of | Operation Failure | x | |
|osi | Network Disconnect | x | TO 900 ms |
|p | Prompt Tone | x | BR |
|rg | Ringing | x | TO 180 sec. |
|r0, r1, r2, | Distinctive Ringing | x | TO 180 sec. |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|ro | Reorder Tone | x | TO 30 sec. |
|rs | Ringsplash | x | BR |
|s(###) | Distinctive Tone Pattern | x | BR |
|sit(#) | Sit Tone | x | TO 2 sec. |
|sl | Stutter Dial Tone | x | TO 16 sec. |
|v | Alerting Tone | x | OO |
|vmwi | Vis. Message Waiting Ind.| x | OO |
|wt | Call Waiting tone | x | TO 12 sec. |
|wt1, wt2, | Alternative Call | x | TO 12 sec |
|wt3, wt4 | Waiting Tones | | (see notes) |
|y | Recorder Warning Tone | x | TO infinite |
|z | Calling Card Serv. Tone | x | BR |
----------------------------------------------------------------
The handset emulation package is similar to the line package except that events such as "off-hook" can be signaled as well as detected.
ハンドセット・エミュレーション・パッケージは、「オフフック」などのイベントが通知並びに検出することができることを除いて、ライン・パッケージと同様です。
Changes from the original package - are the same changes as were made for the line package, plus "hu" and "hd" signal types were changed from OO to BR.
元のパッケージから変更 - ライン・パッケージのために作られたのと同じ変化である、プラス「HU」および「HD」信号タイプのBRにOOから変更しました。
Event definitions are the same as for the line package with the following exceptions:
イベントの定義は、以下の例外を除いて、ラインパッケージと同じです。
ASDI: When requested as an event by the Call Agent, the event is not parameterized. However, the parameter is included when the event is reported.
ASDI：コールエージェントによってイベントとして要求された場合は、イベントはパラメータ化されていません。イベントが報告されている場合しかし、パラメータが含まれています。
Caller-id: When requested as an event by the Call Agent, the event MUST not be parameterized. However, parameters are included when the event is reported i.e.:
発信者ID：コールエージェントによるイベントとして要求された場合は、イベントはパラメータ化されてはなりません。しかし、イベントはすなわちを報告したときのパラメータが含まれています：
O: l/ci(09/14/17/26,"555 1212","John Doe")
O：L / CI（09/14/17/26、 "555 1212"、 "ジョン・ドウ"）
Line Side Answer Supervision: When requested as an event by the Call Agent, it indicates when the reverse loop current feed (RLCF) was turned on and off. The event is not parameterized when it is requested. However, a parameter is included when it is reported i.e.:
回線側の応答監視：コールエージェントによってイベントとして要求された場合には、逆ループ電流給電（RLCF）がオン・オフされたとき、それは示しています。それが要求されたときにイベントはパラメータ化されていません。それはすなわち報告されている場合しかし、パラメータが含まれています：
O: l/lsa(+) to indicate RLCF was turned on
O: l/lsa(-) to indicate RLCF was turned off
Ringing (rg): When requested as an event, the Call Agent may optionally include the rep parameter indicating a request to report after some number of rings e.g.:
（RG）のリンギング：イベントとして要求された場合、コールエージェントは、必要に応じて環例えばいくつかの数の後に報告するための要求を示す担当者パラメータを含むことができます：
RQNT 1234 aaln/1@rgw2.example.net
X: AB123FE0
R: h/rg(N)(rep=3)
The resulting notification after the number of rings is detected includes the parameter again:
環の数が検出された後、得られた通知が再度パラメータを含みます。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: AB123FE0 O: h/rg(rep=3)
AB123FE0 O：H / RG（REP = 3）MGCP 1.0 X ds/ds1-3/6@gw-o.whatever.net NTFY 3002
If the parameter is not included in the request, it is also not included in the report. In that case, the event is reported as soon as ringing is detected.
パラメータが要求に含まれていない場合、それはまた、レポートに含まれていません。その場合、イベントは、すぐにリンギングが検出されたと報告されています。
Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7): As with the "rg" event, if the "rep" parameter is included when one of these is requested as an event, it is also reported. If it is not requested with the parameter, then the parameter is also not included in the report. In that case, the event is reported as soon as ringing with the requested cadence is detected.
独特（R0、R1、R2、R3、R4、R5、R6またはR7）リンギング：これらのいずれかがイベントとして要求されたときに「担当者」パラメータが含まれている場合、「RG」イベントと同様に、これもまた報告されています。それはパラメータで要求されていない場合は、パラメータもレポートに含まれていません。その場合、イベントは、すぐに要求されたリズムで鳴っが検出されたと報告されています。
Stutter Dial Tone (sl): Stutter Dial Tone MUST not be parameterized when requested as an event. However, the "del" parameter is reported.
トーン（SL）をダイヤルしスタッター：イベントとして要求されたとき、スタッターダイヤルトーンは、パラメータ化されてはなりません。しかし、「デル」パラメータが報告されています。
RQNT 1234 aaln/1@rgw2.example.net
X: AB123FE0
R: h/sl
The resulting notification indicates the delay between the confirmation tone and the dial tone:
得られた通知は、確認トーン、ダイヤルトーンとの間の遅延を示しています。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: AB123FE0 O: h/sl(del=1500)
AB123FE0 O：H / SL（デル= 1500）MGCP 1.0 X ds/ds1-3/6@gw-o.whatever.net NTFY 3002
As with the signal, the report indicates the delay rounded to the nearest 100 ms.
信号と同様に、レポートは、最も近い100ミリ秒に丸め遅延を示しています。
Visual Message Waiting: When requested as an event by the Call Agent, it indicates when the visual message waiting indicator was turned on and off. The event is not parameterized when it is requested. However, a parameter is included when it is reported i.e.:
ビジュアルメッセージウェイティング：コールエージェントによってイベントとして要求された場合には、視覚的メッセージウェイティングインジケータがオン・オフされたとき、それは示しています。それが要求されたときにイベントはパラメータ化されていません。それはすなわち報告されている場合しかし、パラメータが含まれています：
O: l/vmwi(+) to indicate message waiting turned on
O: l/vmwi(-) to indicate message waiting turned off
Note that:
ご了承ください：
* All TO signals in the handset package can include a "to" parameter when requested as a signal.
*信号として要求されたときに携帯電話のパッケージの信号TOすべてが「へ」のパラメータを含めることができます。
* However, requests to be notified about these events MUST NOT include the "to" parameter, i.e., the "to" parameter is not valid in RequestedEvents.
*ただし、要求はすなわち「へ」のパラメータを、含んではいけません、これらのイベントについて通知されるように、「に」パラメータはRequestedEventsでは有効ではありません。
Package Name: SST Version: 0
パッケージ名：SSTバージョン：0
---------------------------------------------------------------
|Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
|cd | Conference Depart | | BR |
|cj | Conference Join | | BR |
|cm | Comfort Tone | | TO infinite |
|cw | Caller Waiting Tone | | TO 30 sec. |
|ht | On Hold Tone | | OO |
|ni | Negative Indication | | TO infinite |
|nu | Number Unobtainable | | TO infinite |
|oc | Operation Complete | x | |
|of | Operation Failure | x | |
|pr | Pay Phone Recognition | | BR |
|pt | Pay Tone | | BR |
----------------------------------------------------------------
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトのタイムアウト値「が」信号パラメータによって、このパッケージで定義された任意のタイム・アウト信号のためのコールエージェントによって上だらけであってもよいことに注意してください。詳細については、この文書のセクション2を参照して、ならびに[1]。
The events in this package are defined as follows:
次のようにこのパッケージ内のイベントが定義されています。
Conference Depart(cd): Tone used to indicate that a participant has left a conference call. The tone characteristics are left to the specific gateway implementation.
会議出発（CD）：参加者が電話会議を残していることを示すために使用トーン。階調特性は、特定のゲートウェイの実装に任されています。
Conference Join (cj): Tone used to indicate that a party has joined a conference call. The tone characteristics are left to the specific gateway implementation.
会議は、（CJ）参加：トーンは、当事者が、会議通話に参加したことを示すために使用されます。階調特性は、特定のゲートウェイの実装に任されています。
Comfort Tone (cm): Comfort Tone is used to indicate that the call is being processed and that the caller should wait. Refer to ITU-T E.182 [10].
コンフォートトーン（センチ）：コンフォートトーンは、コールが処理されていることを、呼び出し元が待機しなければならないことを示すために使用されます。 ITU-T E.182 [10]を参照。
Caller Waiting Tone (cw): Not to be confused with a call-waiting tone, this is a tone advising a caller that a called station, though busy, has a call waiting service active. Refer to ITU-T E.182 [10].
発信者ウェイティングトーン（CW）：コールウェイティングトーンと混同してはならないが、これはと呼ばれるステーションは、忙しくても、アクティブなコールウェイティングサービスがあり、発信者に助言をトーンです。 ITU-T E.182 [10]を参照。
Tone on-hold (ht): A tone used to reassure a calling subscriber who has been placed on "hold". Refer to ITU-T E.182 [10].
保留トーン（HT）：「ホールド」に置かれた発呼加入者を安心させるために使用されるトーン。 ITU-T E.182 [10]を参照。
Negative Indication (ni): A tone advising a subscriber that the request for service cannot be accepted. Refer to ITU-T E.182 [10]. For North America, this maps to the re-order tone (see GR-506-CORE [7], Section 17.2.7).
マイナス表示（NI）：サービスの要求を受け入れることができない加入者に助言トーン。 ITU-T E.182 [10]を参照。北米の場合、これは再オーダートーンにマップ（GR-506-CORE [7]、セクション17.2.7を参照してください）。
Number Unobtainable Tone (nu): Refer to ITU-T E.180, supplement 2 [9]. This is also referred to as "vacant tone" and maps to a "re-order tone" in North America (see GR-506-CORE [7], Section 17.2.7).
数手に入らないトーン（NU）：[9] ITU-T E.180、補足2を参照してください。これは、北米では「再注文トーン」を「空きトーン」およびマップ（GR-506-CORE [7]、セクション17.2.7を参照）と呼ばれます。
Operation Complete (oc): The standard definition of operation complete [1].
操作コンプリート（OC）：[1]完全な操作の標準的な定義。
Operation Failure (of): The standard definition of operation failure [1].
動作不良（の）：動作不良の標準的な定義[1]。
Pay Phone Recognition (pr): A tone advising an operator that the endpoint is identified as a payphone. Refer to ITU-T E.182 [10].
有料電話番号認識（PR）：エンドポイントは公衆電話として識別されるオペレータに忠告トーン。 ITU-T E.182 [10]を参照。
Pay Tone (pt): A tone indicating that payment is required. Refer to ITU-T E.182 [10].
有料トーン（PT）：支払いが必要であることを示すトーン。 ITU-T E.182 [10]を参照。
Package Name: dm1 ("dm" followed by the number "1") Version: 0 Extension Digit Map Letters: P
パッケージ名：DM1（番号「1」に続いて「DM」）バージョン：0エクステンション桁地図手紙：P
This package defines an Extension Digit Map Letter that is used to override the shortest possible match behavior for a given entry in a digit map (see [1]). The letter "P" (for partial match override), at the end of a digit map entry, instructs the gateway to only consider that entry a match if the current dial string does not partially match another entry. For example, given the digit map
このパッケージはケタ地図で指定されたエントリの最短一致の動作をオーバーライドするために使用される拡張ディジットマップ文字を定義する（参照[1]）。現在のダイヤル文字列が部分的に別のエントリと一致しない場合にのみ、そのエントリに一致を考慮することが文字「P」（部分一致オーバーライドのためには）、ディジットマップエントリの終わりに、ゲートウェイに指示します。たとえば、電話番号マップを与えられました
([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP)
（[3-7] 11 | 123xxxxxxx | [1-7] xxxxxxP | 8xxxP）
and a current dial string of "1234567", we would not consider this a match (as the rules in [1] would otherwise imply); however a current dial string of "411" would be considered a match as usual. A current dial string of "8234" would be considered a match since there is no other partial match.
そして「1234567」の現在のダイヤルストリング、我々はこの試合（[1]の規則がそう示唆するように）考えていません。しかし、いつものように試合「411」の現在のダイヤルストリングと考えられます。他の部分一致がないので、「8234」の現在のダイヤル文字列が一致すると考えられます。
Note that the digit map letter "P" is not an event, but simply a syntactic and semantic digit map extension. Thus, the "P" is not included in the list of requested or observed events.
ケタ地図手紙「P」がイベントではないことに注意してください、単に構文とセマンティック桁のマップの拡張機能。このように、「P」が要求されたかを観察するイベントのリストに含まれていません。
Support for this package is strongly RECOMMENDED.
このパッケージのサポートを強くお勧めします。
Package Name: SL Version: 0
パッケージ名：SLバージョン：0
---------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------|
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| s(list) | Signal List | | TO variable |
---------------------------------------------------------
Operation Complete (oc): This is the standard definition of operation complete from [1].
動作完了（OC）：これは、[1]からの完全な操作の標準的な定義です。
Operation Failure (of): This is the standard definition of operation failure from [1].
（の）動作不良：これは、[1]から動作不良の標準的な定義です。
Signal List(s(<list>)): The <list> contains a comma-separated list of signals to be played out. Each of the signals in <list> MUST be either of type BR or type TO. Semantically, the signal list is still treated as a single parameterized signal of type Time-Out though. The signals in the list are played to completion one after the other in the left to right order specified. The package for each signal in the list must be specified. For example, to play out the DTMF digits 123456:
信号一覧（S（<リスト>））：<リスト>が出て再生する信号のカンマ区切りのリストが含まれています。 <リスト>の信号の各々は、タイプBRまたはタイプのいずれかでなければなりません。意味的に、信号のリストはまだいえ型タイムアウトの単一パラメータ化信号として処理されます。リスト内の信号は、指定された右の順に左の他の後に完了1に再生されます。リスト内の各信号用のパッケージを指定する必要があります。例えば、DTMF番号123456を再生します：
S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6)
S：SL /秒（D / 1、D / 2、D / 3、D / 4、D / 5、D / 6）
This will result in the DTMF digits 1, 2, 3, 4, 5 and 6 being played out in order.
これは1、2、3、4、5及び6が順に再生されているDTMFディジットをもたらすであろう。
It is illegal to include an OO signal as one of the signals in the list or to request recursive definitions (signal lists within signal lists). If this or any other unsupported signal is included, error code 538 (event/signal parameter error) MUST be returned by the gateway.
リスト内の信号の一つとしてOO信号を含むように、または再帰的定義（信号リスト内の信号リスト）を要求することは違法です。このまたは他の任意のサポートされていない信号が含まれている場合、エラーコード538（イベント/信号パラメータ誤差）ゲートウェイによって返さなければなりません。
Note that as the gateway plays the ordered list of signals, if it encounters a TO signal with an infinite timeout, it will continue to play that signal until the Signal List signal is stopped (i.e., other signals later in the list will never be played).
それは無限のタイムアウトで信号TO遭遇した場合、ゲートウェイは、信号の順序付きリストを果たしているとして信号一覧信号が再生されません後のリストにある（すなわち、他の信号を停止するまで、それはその信号を再生し続けることに注意してください）。
If the operation complete ("oc") event is requested, it will be detected once, when the last signal in the list has been played out (regardless of whether there are any TO signals in the list). The operation complete event will only report the signal list name itself, i.e., without the parameters supplied as in:
動作完了（「OC」）イベントが要求された場合は、リスト内の最後の信号は（関係なく、信号TOいずれかがリストにあるかどうかの）うち再生されたとき、それは、一度検出されます。操作completeイベントが唯一のように、指定されたパラメータなしで、すなわち、信号リスト名自体を報告します。
O: sl/oc(sl/s)
O：SL / OC（SL /秒）
Should any of the signals in the signal list result in an error, an operation failure event for the Signal List signal MUST be generated. Only the signal list name will be included, thus it is not possible to determine which of the signals in the signal list actually failed.
信号リスト結果の信号のいずれかのエラーで、信号一覧信号の動作不良イベントが生成されなければならない必要があります。信号のみのリスト名は、このように、実際に失敗した信号リストの信号のかを決定することは不可能である、含まれます。
Note that if an event occurs while the "SL/S" signal is playing, the "SL/S" signal is stopped in the following manner:
「SL / S」信号の再生中にイベントが発生した場合、「SL / S」信号は次のように停止していることに注意してください。
* If the signal in the list that was playing at the time the event occurred is of type BR, then the BR signal will be played to completion and no other signals in the list will be played.
イベントが発生した時に演奏していたリスト内の信号がタイプBRである場合*は、BR信号が完了するまで再生されると、リストには他の信号が再生されません。
* If the signal in the list that was playing at the time the event occurred is of type TO, then the TO signal will stop immediately and no other signals in the list will be played.
*イベントが発生した時に演奏していた、リスト内の信号は、その後、信号に直ちに停止しますし、リスト内に他の信号が再生されません型の場合。
Package Name: FM Version: 0
パッケージ名：FMバージョン：0
This package provides support for the media format parameter Local Connection Option (LCO). The media format parameter LCO is similar to the "fmtp" attribute in SDP [15] and is applicable to all of the same media formats that the corresponding SDP fmtp attribute could be used with (i.e., media format parameters for any media format MIME type). The media format parameter is encoded as the keyword "fmtp" or "o-fmtp", followed by a colon and a quoted string beginning with the media format name (MIME subtype only) followed by a space, followed by the media format parameters associated with that media format. For simplicity, we will use the terms "codec" and "media format" interchangeably in the following. Multiple formats may be indicated by either repeating the "fmtp" local connection option multiple times, such as:
このパッケージには、メディアのフォーマットパラメータローカル接続オプション（LCO）のサポートを提供します。メディアフォーマットパラメータLCOは、SDPの「のfmtp」属性[15]と同様であり、対応するSDPのfmtp属性は、任意のメディアフォーマットのMIMEタイプの（すなわち、メディア・フォーマット・パラメータを用いて使用することができる同一のメディア形式のすべてに適用可能です）。メディアフォーマットパラメータは、関連付けられたメディアフォーマットパラメータ、続いてコロンとスペースが続くメディアフォーマット名（MIMEサブタイプのみ）で始まる引用符で囲まれた文字列に続いて、キーワード「のfmtp」または「O-のfmtp」として符号化されますそのメディアフォーマットと。簡単にするために、我々は、用語「コーデック」と同義的に以下の「メディア形式」を使用します。複数のフォーマットは、「のfmtp」のようなローカル接続オプションを複数回、繰り返すことのいずれかによって示すことができます。
L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY"
L：CODEC1; CODEC2、のfmtp： "CODEC1 formatX"、のfmtp： "CODEC2 formatY"
or alternatively by having a single "fmtp" keyword followed by a colon, and a semi-colon separated list of quoted strings for each media format parameter, as in:
または代わりのように、コロン単一「のfmtp」キーワード、および各メディアフォーマットパラメータの引用符で囲まれた文字列のセミコロンで区切られたリストを有することにより：
L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY"
L：CODEC1; CODEC2、のfmtp： "CODEC1 formatX"; "CODEC2 formatY"
The two formats may be mixed.
二つのフォーマットが混在していてもよいです。
If it is possible for the same codec to be requested with and without the special "fmtp" format, the following could result:
同じコーデックがして、特別な「のfmtp」フォーマットなしで要求することは可能である場合には、以下が生じる可能性が：
L:a:codec1;codec1, fmtp:"codec1 formatX"
L：コード1、コード1、SMTP： "コード1つのフォーマット"
However, it would not be clear if the fmtp parameter was to be applied to the first or the second occurrence of the codec. The problem with that is, that codec ordering is important (i.e., codecs are listed in preferred order), and the above syntax does not provide a way to indicate if "formatX" is preferred (i.e., associated with the first "codec1") or not (i.e., associated with the second "codec1"). In order to resolve this dilemma, when the same codec is requested with multiple formats, the codec name in the "fmtp" format string is followed by a colon and an <order>, where <order> is a number from one to N for N occurrences of the same codec in the codec list i.e.:
fmtpパラメータが第一又は第二のコーデックの発生に適用されることになっていた場合は、それは明らかではないであろう。 （すなわち、最初の「CODEC1」に関連した）ことの問題点は、そのコーデックの順序は（すなわち、コーデックは、好ましい順にリストされています）重要である、上記の構文は、「formatX」が好まれるかどうかを示すための方法を提供していません。かではない（すなわち、第二の「CODEC1」に関連付けられています）。同じコーデックが複数の形式で要求されたときに、このジレンマを解決するために、「のfmtp」フォーマットストリング内のコーデック名がNに1から数のためのものである結腸および<順序>、<順番>続いてコーデックリストIEで同じコーデックのNの発生：
L:a:codec1;codec1, fmtp:"codec1:2 formatX"
L：CODEC1; CODEC1、のfmtp： "CODEC1：2 formatX"
indicates that "formatX" is associated with the second instance of "codec1" in the "a:codec1;codec1" list. If an invalid instance number is supplied (e.g., instance 3 where there are only two instances), then error code 524 - inconsistency in local connection options will be returned.
「; CODEC1 CODEC1」リスト「formatXが」中「CODEC1」の2番目のインスタンスに関連付けられていることを示しています。無効なインスタンス番号が供給されている場合（例えば、2つだけのインスタンスが存在するインスタンス3）は、エラーコード524 - ローカル接続オプションで矛盾が返されます。
Pre-pending "fmtp" with the string "o-" (i.e., "o-fmtp") indicates that the format is optional. In that case, the gateway may decide not to use the fmtp parameter specified, or only use it in part.
文字列をプリペンディング「のfmtp」「-O-」（すなわち、「O-のfmtp」）はフォーマットがオプションであることを示しています。その場合、ゲートウェイは、指定のfmtpパラメータを使用するか、または一部だけでそれを使用しないことを決定することができます。
If the "fmtp" in an LCO is not optional (i.e., does not have "o-" in front of it), and the LCO value is either not recognized or not supported, then the associated codec is considered "not supported".
LCOの「のfmtp」オプションはない（すなわち、その前に「-O-」ていない）、およびLCOの値が認識されない、またはサポートされていないいずれかの場合には、関連したコーデックは、「サポートされていない」と考えられます。
When auditing capabilities, the "fmtp" local connection option MUST be returned with a semi-colon separated list of supported formats and/or multiple independent "fmtp" parameters as in:
機能を監査する場合、「のfmtp」ローカル接続オプションがサポートされるフォーマットおよび/または同様に、複数の独立した「のfmtp」パラメータのセミコロンで区切られたリストで返さなければなりません。
A: a:telephone-event, fmtp:"telephone-event 0-15,32-35",...
：電話-イベント、のfmtp： "電話-イベント0-15,32-35"、...
A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",...
：：PCMU; G729、のfmtp： "PCMU fooの"; "PCMUバー"、のfmtp： "G729のfoobarに"、...
One example uses the media format parameter LCO in conjunction with the media format "telephone-event", as defined in RFC 2833 [33]. If the media format "telephone-event" is used without the "fmtp" media format parameter, the DTMF digits (telephone events 0-15 from RFC 2833 [33]) are assumed - such practice is however discouraged. On the other hand, the media format parameter LCO MAY be used to specify the exact set of events that are being requested via RFC 2833 [33]. Example:
RFC 2833 [33]で定義されるような1つの例は、メディアフォーマット「電話イベント」と併せてメディアフォーマットパラメータLCOを使用します。メディア形式「電話イベントは」「のfmtp」メディアフォーマットパラメータなしで使用されている場合、DTMFディジット（RFC 2833からの電話イベント0-15 [33]）を想定している - そのような実施はしかし推奨されます。一方、メディアフォーマットパラメータLCOは、RFC 2833 [33]を介して要求されているイベントの正確なセットを指定するために使用されるかもしれません。例：
L: a:PCMU;telephone-event,fmtp:"telephone-event 16"
L：PCMU;電話-イベント、のfmtp： "電話-イベント16"
indicates that if telephone events are supported at all, then this request is specifically for event 16.
電話イベントがすべてでサポートされている場合、この要求はイベント16のために特別であることを示しています。
In another case, the Call Agent may indicate that some format parameters are "required", while others are optional. In the example below, telephone events 0-15 are a "must", while telephone events 16, 70 and 71 are optional.
別のケースでは、コールエージェントは、他の人がオプションである一方で、いくつかの形式のパラメータは、「必須」であることを示していることがあります。電話イベント16、70及び71は任意であるが、以下の例では、電話イベント0-15は、「必須」です。
L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71", fmtp:"telephone-event 0-15"
L：PCMU;電話-イベント、O-のfmtp： "電話-イベント16,70,71"、のfmtp： "電話-イベント0-15"
If the gateway cannot support telephone events 0-15, it MUST NOT include the "telephone-event" media format in the SDP in its response. On the other hand, if it can support those telephone events, it SHOULD indicate support for those events, as well as any of the events 16, 70 and 71 that it supports.
ゲートウェイは、電話イベント0-15をサポートできない場合、それはその応答にSDPで「電話-イベント」メディアフォーマットを含んではいけません。それはそれらの電話のイベントをサポートできる一方、それはこれらのイベントのサポートを示すべきであるだけでなく、それがサポートするイベント16、70および71のいずれか。
If a request is made to audit the capabilities of an endpoint, and the endpoint supports the "telephone event" media format with events "0-16", then the audit would include the following:
要求がエンドポイントの機能を監査するために作られた、およびエンドポイントは、「0-16」イベントと「電話イベント」メディアフォーマットをサポートしている場合、監査には、次のものがあります：
A: a:telephone-event, fmtp: "telephone-event 0-16"
：電話-イベント、のfmtp： "電話-イベント0-16"
Another example is the use of redundancy with RFC 2198 [32]. Again, the format of the fmtp string is similar to that used in the SDP except that the literal string ("red" in this case) is used rather than the payload type:
別の例では、RFC 2198 [32]と冗長性の使用です。再び、のfmtp文字列の形式は、（この場合は「赤」）リテラル文字列はペイロードタイプではなく、使用されていることを除いてSDPで使用されるものと同様です。
L: a:G729;pcmu;red,fmtp:"red pcmu/g729"
L：G729; PCMU、赤、のfmtp： "赤PCMU / G729"
The corresponding media description in the SDP as part of the connection request acknowledgment might look like:
以下のように見えるかもしれない接続要求の確認応答の一部として、SDPにおける対応するメディアの説明：
m=audio 12345 RTP/AVP 98 18 0 a=rtpmap:98 red/8000/1 a=fmtp:98 0/18
M =オーディオ12345 RTP / AVP 98 18 0、A = rtpmap：98赤/ 1分の8000 A =のfmtp：98 0/18
If we combine both telephone events and redundancy, an example local connection option might look as follows (carriage return added for formatting reasons here):
我々は両方の電話イベントや冗長性を組み合わせた場合は、次のように、例えば、ローカル接続オプションは、（キャリッジリターンはここの理由をフォーマットするための追加）になります。
L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729", fmtp: "telephone-event 16"
L：G729; PCMU;赤色;電話イベントのfmtp： "赤PCMU / G729" のfmtp： "電話イベント16"
Note that we again specify the literal string for the encoding method rather than its payload type. This is a general principle that should be used with this LocalConnectionOption.
我々は再び符号化方式ではなく、そのペイロードタイプのリテラル文字列を指定することに注意してください。これは、このLocalConnectionOptionして使用する必要があり、一般的な原則です。
The corresponding SDP might appear as follows:
次のように対応するSDPが表示されることがあります。
m=audio 12345 RTP/AVP 97 98 18 0 a=rtpmap:97 red/8000/1 a=fmtp:97 0/18 a=rtpmap:98 telephone event a=fmtp:98 16
M =オーディオ12345 RTP / AVP 97 98 18 0、A = rtpmap：97 1分の8000 /赤A =のfmtp：97 0/18 = rtpmap：98電話イベントA =のfmtp：98 16
Note that the fmtp LCO may be used in any situation where the corresponding SDP attribute may be used. An example of a local connection option that involves a media type other than audio and a "foobar" fmtp parameter:
fmtpのLCOは、対応するSDP属性を使用することができる任意の状況で使用することができることに留意されたいです。オーディオと「foobarの」のfmtpパラメータ以外のメディアタイプを必要とするローカル接続オプションの例：
L: a:image/tiff, fmtp:"tiff foobar"
L：画像/ TIFF、のfmtp： "TIFFのfoobarに"
Note that normally local connection options that are associated with a package should have the package prefix included as per the package extension rules in [1]. The "fmtp" and "o-fmtp" LCO in the "FM" package are an exception. The package prefix is not included in the case of the "fmtp" and "o-fmtp" local connection options because they were created before the extension rules in [1] were defined.
パッケージに関連付けられている通常、ローカル接続オプションは、パッケージ接頭辞[1]パッケージの拡張ルールごとに含まれているべきであることに留意されたいです。 「FM」のパッケージに「のfmtp」と「O-のfmtp」LCOは例外です。 [1]における拡張ルールが定義される前に、それらが作成されたため、パッケージの接頭辞が「のfmtp」と「O-のfmtp」ローカル接続オプションの場合には含まれません。
These two LocalConnectionOptions have been registered with IANA.
これら二つのLocalConnectionOptionsは、IANAに登録されています。
Package Name: R Version: 1
パッケージ名：Rバージョン：1
-------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|-------------------------------------------------------------|
| co1 | Continuity Tone (single | C | TO,C 3 sec. |
| | or return tone) | | |
| co2 | Continuity Test (go tone, | C | TO,C 3 sec. |
| | in dual tone procedures) | | |
| iu(..) | ICMP Unreachable | C | |
| | Received | | |
| ji(..) | Jitter Buffer Size Changed | C | |
| ma | Media Start | C | |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
| pl(..) | Packet Loss Exceeded | C | |
| qa | Quality Alert | C | |
| rto(..) | RTP/RTCP Timeout | C | |
| sr | Sampling Rate Changed | C | |
| uc | Used Codec Changed | C | |
-------------------------------------------------------------
Changes in event types: "co1" and "co2" signals changed from OO to TO.
イベントタイプの変更：「CO1」と「CO2」の信号がOO TOから変更します。
New events added to this package from the previously unversioned package: "iu", "rto", "ma".
「IU」、「RTO」、「MA」：新しいイベントが以前にバージョン管理外のパッケージからこのパッケージに追加しました。
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトのタイムアウト値「が」信号パラメータによって、このパッケージで定義された任意のタイム・アウト信号のためのコールエージェントによって上だらけであってもよいことに注意してください。詳細については、この文書のセクション2を参照して、ならびに[1]。
The events in this package all refer to media streams (connections), i.e., they cannot be detected on an endpoint. Furthermore, with the exception of the "iu" event, which is defined for any type of media, all other events in this package are defined for RTP media streams only (i.e., if they are used on connections that do not use RTP, the behavior is not defined).
このパッケージのイベントはすべて、すなわち、それらはエンドポイントで検出することができない、メディアストリーム（接続）を参照します。さらに、メディアの任意のタイプのために定義された「IU」イベントを除いて、このパッケージ内の他のすべてのイベントは、RTPメディアストリームのために定義されているだけで（すなわち、それらは、RTPを使用していない接続で使用されている場合行動）が定義されていません。
Signals requested (e.g., "co1" and "co2") must indicate the connection ID (e.g., "S: r/co1@connectionID"). An event may be requested for all existing connections using the "*" wildcard for the connectionID as described in [1].
要求された信号（例えば、 "CO1" および "CO 2"）接続IDを指定する必要があり（例えば、 "S：R / CO1する@ connectionID"）。イベント[1]に記載のようにconnectionIDための「*」はワイルドカードを使用して、すべての既存の接続を要求することができます。
Example:
例：
R: r/uc@* (request to detect uc on all connections) or
R：R / UC @ *（すべての接続にUCを検出するための要求）又は
R: r/uc@connectionID (request to detect uc only on a specific connection)
R：R / UC @ connectionID（リクエストのみ特定の接続にUCを検出します）
An event detected on a connection will include the connectionID, e.g.:
接続上で検出されたイベントは、例えばconnectionIDが含まれます：
O: r/uc@connectionID(15)
O：R / UC @ connectionID（15）
Continuity tones (co1 and co2): These are the same as the events defined in the Trunk package, except in this case, they are only played over a network connection and the connectionID MUST be supplied (e.g., "s: r/co1@connectionID"). They can be used in conjunction with the Network LoopBack (netwloop) or Network Continuity Test (netwtest) modes to test the continuity of an RTP circuit. However, in the case of testing IP continuity, a one-tone test is sufficient i.e., generating and detecting "co1" at one end, with connection mode in network loopback mode at the other end. Note that the test can also be done using telephone events rather than tones, i.e., event 167 in RFC 2833 [33] corresponds to "co1". In this case, connection requests are made with local connection options such as:
継続トーン（CO1およびCO2）：この場合を除き、トランクパッケージで定義されたイベントは、彼らが唯一のネットワーク接続を介して再生されますとconnectionIDが（供給されなければならないように、これらが同じであるなど、「S：R / CO1 @ connectionID "）。彼らは、RTP回路の連続性をテストするために、ネットワークループバック（netwloop）またはネットワーク連続性テスト（netwtest）モードと組み合わせて使用することができます。しかし、テストIPの連続の場合、ワントーンテストは十分即ち、発生及び他端にネットワークループバックモードの接続モードと、一方の端部に「CO1」を検出しています。試験はまた、RFC 2833 [33]で、すなわち電話イベントではなくトーン、イベント167を用いて行うことができることに注意してください「がCO1」に相当します。この場合、接続要求は、次のようなローカル接続オプションで作られています：
L: a:PCMU;telephone-event,fmtp:"telephone-event 167"
L：PCMU;電話-イベント、のfmtp： "電話-イベント167"
in order to request support for telephone event 167. If both ends support the event, then the network loopback proceeds as usual, except that telephone events corresponding to the co1 tone are sent, as opposed to the co1 tone itself.
CO1トーンそのものとは対照的に、両端がイベントをサポートしている場合、通常のように、ネットワークループバック進む電話イベント167のためのサポートを要求するために、その電話以外CO1トーンに対応するイベントが、送信されます。
ICMP Unreachable Received (iu): This event indicates that some number of ICMP unreachable packets [19] was received for this connection since an RQNT was received requesting this event. This notification indicates that packets that were sent by the gateway on this connection either did not arrive at their destination or were not accepted (e.g., the port was closed). When this event is requested, a single parameter with a decimal number from 1 to 255 may be included to indicate the number of ICMP un-reachable packets that must occur before the event is notified. If no parameter is supplied, with the request then a default value of 3 is assumed. This is a one-shot event in that once the event occurs, a further request is required in order to re-initiate counting.
ICMP到達不能は、（IU）を受信：このイベントは、RQNTがこのイベントを要求して受信してからICMP到達不能パケット[19]の一部の数はこの接続で受信されたことを示しています。この通知は、この接続にゲートウェイによって送信されたいずれかの目的地に到着しなかったか、受け入れられなかったパケットは（例えば、ポートが閉じられた）ことを示しています。このイベントが要求されたとき、1から255までの十進数を有する単一のパラメータは、イベントが通知される前に発生しなければならないICMP未到達可能なパケットの数を示すために含まれてもよいです。いかなるパラメータが供給されない場合は、要求に次いで3のデフォルト値が仮定されます。イベントが発生すると、これは、さらに、要求はカウントを再び開始するために必要とされる、という点で、ワンショットイベントです。
The observed event is parameterized with two parameters:
観測されたイベントは、2つのパラメータでパラメータ化されています。
* The first parameter is the number of ICMP unreachable packets received (i.e., the same value that was included in the request - or the value 3, if the requested event was not parameterized)
*最初のパラメータは、（ - または値3、要求されたイベントは、パラメータ化されなかった場合、すなわち、要求に含まれていた同じ値）ICMP到達不能パケットの数が受信されます
* The second parameter is the error code indicated in the ICMP unreachable packet, e.g.:
*第2のパラメータは、例えばICMP到達不能パケットに示されたエラーコードであります：
0 = net unreachable;
0 =ネット到達不能。
1 = host unreachable;
1 =ホスト到達不能。
2 = protocol unreachable;
2 =プロトコル到達不能。
3 = port unreachable;
3 =ポート到達不能。
4 = fragmentation needed and DF set;
4 =必要なフラグメンテーションおよびDFセット。
5 = source route failed.
5 =ソースルートが失敗しました。
etc.
等
An example of a request might be as follows:
次のように要求の例は次のようになります。
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 R: r/iu@364823(N)(5)
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X：0123456789B0 R：R / IU（5）364823（N）@
In this case, a notify will occur if 5 ICMP port unreachable packets are received as a result of RTP and/or RTCP packets being sent from this gateway on the connection with connection ID 364823.
5 ICMPポート到達不能パケットは、接続ID 364823との接続に、このゲートウェイから送信されるRTP及び/又はRTCPパケットの結果として受信された場合この場合は、通知が発生します。
The resulting NTFY with observed events might be as follows:
次のように観察されたイベントでの結果NTFYは次のようになります。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 O: r/iu@364823(5,3)
んＴＦＹ ３００２ ｄｓ／ｄｓ１ー３／６＠ｇｗーお。うぁてゔぇｒ。ねｔ ＭＧＣＰ １。０ Ｘ： ０１２３４５６７８９Ｂ０ お： ｒ／いう＠３６４８２３（５、３）
The first parameter indicates 5 ICMP unreachable packets were received since the RQNT with this request was sent. The second parameter ("3") specifies the reason, which in this case, is "port unreachable".
最初のパラメータには、この要求にRQNTが送信されてから5つのICMP到達不能パケットが受信された示します。二番目のパラメータ（「3」）は、この場合には、「ポート到達不能」である理由を特定します。
Jitter Buffer Size Changed (ji): This event is only included here to maintain compatibility with the previous version of this package. This event is used to indicate that the gateway has made an adjustment to the depth of the jitter buffer. The syntax for requesting notification is "ji", which tells the media gateway that the controller wants notification of any jitter buffer size changes. The syntax for notification from the media gateway to the controller is "JI(####)", where the #### is a decimal number from 1 to 65536, indicating the new size of the jitter buffer in milliseconds.
ジッタバッファサイズ変更（JI）：このイベントは、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。このイベントは、ゲートウェイは、ジッタバッファの深さの調整を行ったことを示すために使用されます。通知を要求するための構文は、コントローラは、任意のジッタバッファサイズの変更の通知を望むメディアゲートウェイに指示する「JI」です。コントローラへのメディアゲートウェイからの通知のための構文は、####ミリ秒のジッタバッファの新しいサイズを示す、1から65536の10進数です「JI（####）」、です。
Media Start (ma): The media start event occurs on a connection when the first valid RTP media packet is received on the connection. This event can be used to synchronize a local signal, e.g., ringback, with the arrival of media from the other party.
メディアの開始（ミリアンペア）：メディアの開始イベントは、最初の有効なRTPメディアパケットを接続上で受信された接続で発生します。このイベントは、他の当事者からのメディアの到着と、ローカル信号、例えば、リングバックを同期させるために使用することができます。
The event is detected on a connection. If no connection is specified, the event applies to all connections for the endpoint, regardless of when the connections are created (i.e., if a connection is not specified, the event will occur when the first valid RTP packet arrives on any one of the connections on that endpoint).
イベントは、接続上で検出されました。何も接続が指定されていない場合、イベントはエンドポイントのすべての接続に適用され、接続が指定されていない場合、最初の有効なRTPパケットは、接続のいずれかに到達したときに、関係なく、接続が作成されたときの（すなわち、イベントが発生しますそのエンドポイント上）。
Operation complete (oc): This is the standard definition of operation complete [1].
動作完了（OC）：これは完全な操作の標準的な定義である[1]。
Operation failure (of): This is the standard definition of operation failure [1].
動作不良（の）：これは、動作不良、[1]の標準的な定義です。
Packet Loss Exceeded (pl): Packet loss rate exceeds the threshold of the specified decimal number (with a range of 1 to 100,000) of packets per 100,000 packets, where the packet loss number is indicated in parenthesis. For example, PL(10) is a drop rate of 10 in 100,000 packets. This event is requested with a parameter indicating at what packet loss rate the Call Agent wishes to be reported. If the packet loss exceeds that value, the event is reported with that same parameter. The event is only reported once when the packet loss threshold is exceeded. Once reported, a following request will re-initiate packet loss measurements and report when the threshold is exceeded again.
パケット損失超過（PL）：パケット損失率、パケットロス数を括弧内に示されている10万パケットあたりのパケットの（1〜100,000の範囲で）指定された進数の閾値を超えました。例えば、PL（10）10 100,000パケットのドロップ率です。このイベントは、コールエージェントが報告されることを希望するものを、パケット損失率で示すパラメータで要求されています。パケットロスがその値を超えた場合、イベントはその同じパラメータで報告されます。パケットロスしきい値を超えたときにイベントは一度だけ報告されます。一度、次の要求は、パケット損失の測定を再度開始し、しきい値を再び超えた場合に報告し、報告しました。
Quality alert (qa): The packet loss rate or the combination of delay and jitter exceeding a quality threshold. The quality thresholds for delay, jitter and packet loss rate are provisioned values.
品質警告（QA）：パケット損失率や品質閾値を超える遅延およびジッタの組み合わせ。遅延、ジッタ、およびパケット損失率のための品質閾値は、値をプロビジョニングしています。
RTP/RTCP Timeout (rto(<timeout>,st=<start-time>)): This event indicates that neither RTP nor RTCP packets have been received on this connection for a period of time equal to the <timeout> value (in seconds). The timeout value can be supplied as a decimal number from 1 to 65535 in the parameter when the request is made. The <timeout> parameter will be supplied in ObservedEvents when the event is reported - it then simply repeats the value used. If an RTP or RTCP packet is received before the timer expires, then the timer is reset and re-started. The event will only be generated if the timer expires without an RTP or RTCP packet arriving on the specified connection during the specified period of time. Note that if the event is requested without the <timeout> parameter, then a default timeout of 60 seconds is assumed. The <timeout> value will still be reported in ObservedEvents, even if no timeout value was indicated in the request (the default value will be indicated in that case). This is a one-shot event in that once the event occurs, a further request is required in order to re-initialize the timer.
RTP / RTCPタイムアウト（RTO（<タイムアウト>、ST =は<開始時間を>））：このイベントは、どちらRTPもRTCPパケットがに（<タイムアウト>の値に等しい時間の間、この接続で受信されていることを示しています秒）。要求が行われたときにタイムアウト値は、パラメータに1〜65535の10進数として供給することができます。イベントが報告されている場合、<タイムアウト>パラメータがObservedEventsに供給されることになる - それは、単に使用される値を繰り返します。タイマーが切れる前にRTPまたはRTCPパケットを受信した場合には、タイマーがリセットされ、再起動されます。タイマーは、指定期間中に指定の接続に到着RTPまたはRTCPパケットなしで期限切れになった場合、イベントにのみ生成されます。イベントは、<タイムアウト>パラメータなしで要求された場合、その後、60秒のデフォルトのタイムアウトが想定されることに注意してください。 <タイムアウト>値がまだタイムアウト値は、要求（デフォルト値は、その場合に示される）に示されなかった場合でも、ObservedEventsに報告されるであろう。イベントが発生したら、これがさらに要求は、タイマーを再初期化するために必要である、という点で、ワンショット・イベントです。
Another optional <start-time> parameter may also be included. This is used to indicate when the timer starts. It can have one of the following values:
別のオプションの<開始時間>パラメータを含めることもできます。これは、タイマーが起動したときを示すために使用されます。これは、次のいずれかの値を持つことができます。
* "im" for immediate i.e., the timer starts as soon as the request is received. This is the default.
*「IM」すなわち即時のためには、タイマーはすぐに要求が受信されると開始します。これがデフォルトです。
* "ra" to indicate that the timer should start only after an RTCP packet has been received from the other end (i.e., the timer will be initiated when the first RTCP packet is received after the request is made). Note that in the case where the other end does not support RTCP, the timer will never be initiated.
RTCPパケットはもう一方の端（第RTCPパケットを受信したときに、要求が行われた後、すなわち、タイマーが開始される）から受信された後、タイマーのみ開始すべきことを示す*「RA」。もう一方の端は、RTCPをサポートしていない場合には、タイマーが開始されないことに注意して下さい。
Note that either the <timeout> or <start-time> may be included in the request, but only the <timeout> value is included in the report.
その<タイムアウト>のいずれかに注意してくださいまたは<開始時間>要求に含まれていてもよいが、唯一の<タイムアウト>値は、レポートに含まれています。
An example of a request might be as follows:
次のように要求の例は次のようになります。
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 R: r/rto@364823(N)(120,st=im)
0123456789B0 R：364823 @ / RTO R（N）（120、ST = IM）MGCP 1.0 X ds/ds1-3/6@gw-o.whatever.net RQNT 2001
In this case, a notify will occur if there is a period of time when no RTP or RTCP packets have been received on connection 364823 for 120 seconds.
この場合、RTPまたはRTCPパケットは120秒間接続364823で受信されていない場合の時間がある場合に発生する通知。
The resulting NTFY with observed events would be as follows:
次のように観察されたイベントでの結果NTFYは次のようになります。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 O: r/rto@364823(120)
0123456789B0 O：364823 @ R / RTO（120）MGCP 1.0 X ds/ds1-3/6@gw-o.whatever.net NTFY 3002
Sampling Rate Changed (sr): This event is only included here to maintain compatibility with the previous version of this package. This event indicates that the packetization period changed to some decimal number in milliseconds enclosed in parenthesis, as in SR(20).
サンプリングレート変更（SR）：このイベントは、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。このイベントは、パケット化期間はSR（20）のように、括弧で囲まれたミリ秒単位でいくつかの10進数に変更したことを示しています。
Used Codec Changed (uc): This event is only included here to maintain compatibility with the previous version of this package. This event is requested without a parameter, but when reported, the hexadecimal payload type is enclosed in parenthesis, as in UC(8), to indicate the codec was changed to PCM A-law. Codec Numbers are specified in RFC 3551 [26], or in a new definition of the audio profiles for RTP that replaces this RFC.
使用されるコーデックは、（UC）を変更：このイベントは、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。このイベントは、パラメータなしで要求されているが、報告された場合、進ペイロードタイプは、コーデックがPCM A則に変えたことを示すために、UC（8）のように、括弧で囲まれています。コーデック番号は、RFC 3551 [26]、またはこのRFCを置き換えるRTP用のオーディオプロファイルの新しい定義で指定されています。
Package Name: RES Version: 0
パッケージ名：RESバージョン：0
The "RES" package provides local connection option support for resource reservations as well as an event to indicate reservation loss.
「RES」パッケージには、ローカル接続オプションのリソース予約のためのサポートだけでなく、予約の損失を示すために、イベントを提供します。
A number of LocalConnectionOption parameters are used in doing resource reservations: "reservation request", "reservation direction", "reservation confirmation" and "resource sharing".
「予約要求」、「予約の方向」、「予約確認」と「リソースの共有を」：LocalConnectionOptionパラメータの数は、リソース予約を行う際に使用されています。
Reservation Request LocalConnectionOption: The gateways can be instructed to perform a reservation on a given connection using RSVP. When a reservation is needed, the Call Agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service". The absence of reservation can be indicated by asking for the "best effort" service, which is the default value for this parameter.
予約要求LocalConnectionOption：ゲートウェイは、RSVPを使用して、指定された接続上で予約を行うように指示することができます。予約が必要な場合は、コールエージェントは「制御負荷」または「保証サービス」のいずれかで使用されるべきで予約プロファイルを指定します。予約がない場合は、このパラメータのデフォルト値である「ベストエフォート」のサービスのために尋ねることによって示すことができます。
Whether or not RSVP will be done is dependent on whether the reservation request LocalConnectionOption parameter has been included in a connection request for this connection (with either "controlled load" or "guaranteed service" indicated). If a modify connection (MDCX) request requires a change in the reservation and the "reservation request" parameter is not included in the LocalConnectionOptions, but was included in the LocalConnectionOptions for a previous connection request for that connection, then the "reservation request" value defaults to its previously saved value for that connection. If a modify connection (MDCX) request explicitly contains a "reservation request", indicating a request for "best effort" for a connection that has an existing reservation, the existing reservation will be torn down.
RSVPが行われるかどうかは、予約要求LocalConnectionOptionパラメータが（「制御負荷」または「保証サービス」指示のいずれかで）この接続のための接続要求に含まれているかどうかに依存しています。接続を変更した場合（MDCX）は、要求は、その後、「予約要求」の値をLocalConnectionOptionsに含まれていない予約および「予約要求」パラメータの変更を必要としますが、その接続のための以前の接続要求のためのLocalConnectionOptionsに含まれていましたその接続のためにその以前に保存された値がデフォルト。変更接続（MDCX）要求が明示的に既存の予約を持って接続するための「ベストエフォート」のための要求を示す「予約要求」を、含まれている場合は、既存の予約は取り壊されます。
Reservation Direction LocalConnectionOption: When reservation has been requested on a connection, the gateway will examine the reservation direction LocalConnectionOption parameter to determine the direction that the reservations require and do the following:
予約の方向LocalConnectionOption：予約が接続に要求された場合は、ゲートウェイは予約が必要で、次の操作を実行する方向を決定するために予約方向LocalConnectionOptionパラメータを調べます。
* Start emitting RSVP "PATH" messages if the reservation
direction LocalConnectionOptions parameter specified "send-
only" or "send-receive".
* Start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the reservation direction parameter specified "receive-only" or "send-receive".
*スタートはすぐに予約方向パラメータは「唯一-受信」または「送信・受信」を指定した場合、それは「PATH」メッセージを受信すると、RSVP「RESV」メッセージを発します。
If an RSVP reservation is requested, but the reservation direction LocalConnectionOption parameter is missing, the reservation direction defaults to the previously saved value of the reservation direction parameter for that connection. If there was no previous reservation direction parameter for that connection, the value is deduced from the connection mode. That is:
RSVP予約が要求されますが、予約方向LocalConnectionOptionパラメータが欠落している場合は、その接続のための予約方向パラメータの以前に保存した値に予約方向のデフォルト。その接続には、以前の予約方向パラメータがなかった場合は、値が接続モードから推定されます。あれは：
* Start emitting RSVP "PATH" messages if the connection is in "send-only", "send-receive", "conference", "network loop back" or "network continuity test" mode (if a remote connection descriptor has been received).
リモート接続記述子を受信した場合、接続が「送信専用」、「送信・受信」、「会議」、「ネットワークループバック」または「ネットワーク導通試験」モード（である場合*スタートはRSVP「PATH」メッセージを発します）。
* Start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the connection is in "receive-only", "send-receive", "conference", "network loop back" or "network continuity test" mode.
*スタートとすぐに接続が「受信専用」、「送信・受信」、「会議」、「ネットワークループバック」であるか「ネットワーク導通試験」モードならば、それは「PATH」メッセージを受信すると、RSVP「RESV」メッセージを発します。
Reservation Confirmation LocalConnectionOption: Another LocalConnectionOption parameter for RSVP reservations is the reservation confirmation parameter, which determines what the resource reservation pre-condition (see [1]) is for acknowledging a successful connection request:
予約確認LocalConnectionOption：RSVP予約のための別のLocalConnectionOptionパラメータはリソース予約事前条件が成功した接続要求を承認するためのものである（[1]参照）かを決定する予約確認パラメータです。
* If the reservation confirmation parameter is set to "none",
the gateway will "Ack" the connection request without
waiting for reservation completion. This is the default
behavior.
* If the "reservation confirmation" parameter is set to "send-only", the gateway will "Ack" when the PATH message has been sent and the corresponding RESV is received to indicate successful reservation in the send direction.
「予約確認」パラメータが「送信専用」に設定されている場合*、ゲートウェイは、PATHメッセージが送信され、対応するRESVを送信方向に成功した予約を示すために、受信される「ACK」であろう。
* If the "reservation confirmation" parameter is set to "receive-only", the gateway will "Ack" when reservation confirm for a reservation has been received.
「予約確認」パラメータが「受信専用」に設定されている場合*、ゲートウェイは、予約の予約確認が受信された「ACK」であろう。
* If the reservation confirmation parameter is set to "send-receive", the gateway will "Ack" only after the PATH message has been sent and the corresponding RESV has been received for send direction, and reservation confirm has been received for the receive direction.
*予約確認パラメータは、「送信 - 受信」に設定されている場合、ゲートウェイPATHメッセージが送信され、対応するRESVが送信方向のために受信された、予約確認が受信方向のために受信された後にのみ意志「ACK」 。
Note that:
ご了承ください：
Values "receive-only" and "send-receive" are triggers for the gateway to request reservation confirm (RESVCONF) when it sends out the RESV.
値は、「専用受信」と「送信 - 受信」、それはRESVを送信する際に、予約確認（RESVCONF）を要求するためのゲートウェイのトリガーです。
Pre-conditions SHOULD only be added for the direction(s) for which resource reservations have been requested. If a direction is added as a pre-condition, and that direction was not requested in the resource reservation, the direction MUST simply be ignored as a pre-condition.
前提条件は、リソース予約が要求されているため方向（S）のために添加されるべきです。方向が前提条件として追加され、その方向はリソース予約で要求されなかった場合、方向は、単に事前条件として無視されなければなりません。
In this approach, resource reservation success is the pre-condition to final acknowledgement of the connection request. If the reservation fails, the connection request also fails (error code 404 - insufficient bandwidth) - as will any other part of the transaction, e.g., a notification request included as part of the connection request. A typical example of this would be a request to ring the phone and look for off-hook, included with the connection request. If the reservation fails, the phone will not ring. Similarly, if the phone is already off-hook, the command fails and there will be no resource reservation.
このアプローチでは、リソース予約の成功は、接続要求の最終確認に前提条件です。予約が失敗した場合、接続要求はまた、（ - 帯域幅不足のエラーコード404） - 失敗したトランザクションの他の部分は、例えば、通知要求は、接続要求の一部として含まれるように。この典型的な例では、接続要求に含まれる電話を鳴らすとオフフックを探すための要求であろう。予約が失敗した場合、電話は鳴りません。電話がオフフックすでにある場合は同様に、コマンドが失敗し、リソース予約はありません。
A provisional response SHOULD be provided if confirmation is expected to occur outside the normal retry timers and in fact a provisional response MUST be provided if the reservation confirmation parameter has value "send-receive" (without a provisional response, SDP information cannot be returned until the final "Ack" which will not occur until the reservation is complete. This can result in a deadlock since the SDP information typically needs to be passed to the other end in order for it to initiate the RSVP PATH message in the other direction). The SDP information and connectionID MUST be included in both the provisional response and the final response. Note that in order to ensure rapid detection of a lost final response, final responses issued after provisional responses for a transaction SHALL be acknowledged, i.e., they SHALL include an empty "ResponseAck" parameter in the final response (see [1]).
確認が予約確認パラメータが「送信 - 受信」（暫定応答せずに、SDP情報にまで戻すことができない値を有する場合、暫定的な応答を提供しなければならない通常のリトライタイマーの外側と実際に発生すると予想される場合に、暫定応答が提供されなければなりません予約が完了するまで発生しない。SDP情報は、典型的には、それが他の方向RSVP PATHメッセージを開始するためにもう一方の端に渡される必要があるので、これはデッドロックをもたらすことができる最終的な「ACK」）。 SDP情報とconnectionIDは、暫定的な応答と最終応答の両方に含まれなければなりません。失われた最終的な応答の迅速な検出を保証するために、トランザクションの暫定応答の後に発行された最終的な応答が認められるものと注意し、すなわち、それらは最終的な応答（[1]参照）空「ResponseAck」パラメータを含まなければなりません。
If the transaction time is outside the expected bounds (time T-HIST - see the section on provisional responses in [1]), error code 406 (transaction timeout) SHOULD be returned.
トランザクション時間が予想範囲外である場合（時刻T-HISTは - [1]に暫定応答のセクションを参照）、エラーコード406（トランザクションタイムアウト）が返されるべきです。
Also note that if the reservation confirmation parameter is omitted, the value of the reservation confirmation parameter defaults to its previously saved value. If there is no previously saved value for the reservation confirmation parameter, or the reservation confirmation parameter has the value "none", then successful resource reservation is not a pre-condition to providing an acknowledgement to the connection request (i.e., the gateway can "Ack" right away without waiting for the reservation to complete and a provisional response will not be necessary).
また、その以前に保存された値に予約確認パラメータのデフォルトの値は、予約確認パラメータが省略されている場合ことに注意してください。以前に保存した予約確認パラメータの値、または予約確認パラメータが何がある場合は値「どれも」、そして成功したリソース予約は、接続要求（すなわちへの確認応答を提供する前提条件ではありませんしていない、ゲートウェイは「缶すぐに完了するために予約して）必要ではないでしょう暫定応答を待たずにACK」。
Resource Sharing LocalConnectionOption: It may be possible to share network resources across multiple connections. An example is a call-waiting scenario, where only one connection will ever be active at a time. In a 3-way calling scenario with a similar set of connections, sharing is not possible. Only the Call Agent knows what may be possible, depending on the feature that is being invoked.
リソース共有LocalConnectionOption：複数の接続間のネットワークリソースを共有することも可能です。例では、唯一つの接続が今まで一度にアクティブになり、コールウェイティングシナリオ、です。接続の類似したセットで3方向通話のシナリオでは、共有することはできません。唯一のコールエージェントが呼び出されている機能に応じて、可能であるかもしれないものを知っています。
In order to allow the Call Agent to indicate that sharing is possible, a resource sharing LocalConnectionOption parameter is introduced. This parameter can have one of the following values:
コールエージェントはその共有を示すためにできるようにするためにLocalConnectionOptionパラメータを共有するリソースが導入され、可能です。このパラメータには、次のいずれかの値を持つことができます。
* A value "$" can be specified where $ refers to "this connection". This value is used when doing a create connection and indicates the intent to share resources with this connection.
$は「この接続」を指し*値「$」は指定することができます。この値は、作成、接続を行う際に使用されると、この接続とリソースを共有する意図を示しています。
* A connection ID can be specified which indicates that this is a request to share resources with the connection having this connection ID (allowing multiple connections to share resources with the connection indicated).
*接続IDは、これは（複数の接続を示す接続とリソースを共有することを可能にする）、このコネクションIDを有する接続とリソースを共有するための要求であることを示して特定することができます。
* The value can be empty, which indicates a request to no longer share the resources of this connection with other connections.
*値は、もはや他の接続と、この接続のリソースを共有するための要求を示しており、空にすることができます。
In the case of a CRCX, the default value for the resource sharing local connection option is empty, and for an MDCX, the default value is its current value.
CRCXの場合に、リソース共有ローカル接続オプションのデフォルト値は空であり、そしてMDCXため、デフォルト値は現在の値です。
The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period.
RSVPフィルタは接続の特性から推定されます。 RSVPリソースプロフィールは接続の帯域幅とパケット化期間から推定されます。
Note that if RSVP is used with PacketCable Dynamic Quality of Service [35], then the parameters in NCS [36] would be used instead of the reservation direction, confirmation and reservation sharing parameters described here.
RSVPは、サービスのPacketCableの動的品質[35]で使用される場合、次いで、NCSのパラメータは、[36]の代わりにここで説明した予約方向、確認及び予約の共有パラメータで使用されることに留意されたいです。
The Local Connection Options for the "RES" package consist of the following:
「RES」パッケージのローカル接続オプションには、以下で構成されています。
* The resource reservation parameter, encoded as the keyword "r", followed by a colon and the value "g" (guaranteed service), "cl" (controlled load) or "be" (best effort).
*コロンと値「G」（保証サービス）、「CL」（制御された負荷）、または「である」（ベストエフォート）、続いて、キーワード「R」としてエンコード資源予約パラメータ、。
* The reservation direction parameter, encoded as the keyword "r-dir" followed by a colon and the value "sendonly", "recvonly" or "sendrecv".
*キーワードとしてエンコード予約方向パラメータ、「R-DIR」コロンと「sendonlyの」値、「recvonlyで」または「のsendrecv」が続きます。
* The reservation confirmation parameter, encoded as the keyword "r-cnf" followed by a colon and the value "none", "sendonly", "recvonly" or "sendrecv".
キーワード「R-CNF」コロンと値「なし」、「sendonlyの」、「recvonlyで」または「のsendrecv」が続くとしてエンコード*予約確認パラメータ。
* The resource sharing parameter, encoded as the keyword "r-sh" followed by a colon and either:
コロン、キーワード「R-SH」としてエンコード*リソース共有パラメータ、および次のいずれか
* The wild-card character "$" indicating this connection,
indicating future plans to share resources with this
connection, or
* A connection ID, indicating a request to share resources with the connection having the specified connection ID (and all other connections sharing resources with that connection), or
*接続IDを指定した接続ID（およびその接続とリソースを共有するすべての他の接続）を有する接続とリソースを共有するための要求を示す、または
* An empty value (i.e., "r-sh:" with no value indicated), indicating a request to no longer share the resources of this connection with other connections
*空の値（即ち、「R-SH：」NO値で示される）、もはや他の接続と、この接続のリソースを共有するための要求を示します
Note that normally local connection options that are associated with a package have the package prefix included as per the package extension rules in [1]. The local connection options in the "RES" package are exceptions. The package prefix is not included in the case of the "RES" package because it was created before the extension rules in [1] were defined.
パッケージに関連付けられている通常、ローカル接続オプションは、パッケージ接頭辞[1]パッケージの拡張ルールに従って含まれていることに留意されたいです。 「RES」パッケージ内のローカル接続オプションは例外です。それが作成されたため、[1]における拡張ルールが定義された前に、パッケージの接頭辞は「RES」パッケージの場合には含まれていません。
The following events are included as part of the resource reservation package:
次のイベントは、リソース予約パッケージの一部として含まれています。
------------------------------------------------------
| Symbol | Definition | R | S Duration |
|------------------------------------------------------|
| re | Resource Error | C | |
| rl | Resource Lost | C | |
------------------------------------------------------
Resource Error (re): This is an indication that an error in the resource reservation occurred during the life of the connection. This event is not requested with a parameter, but is reported with a parameter (see possible values below). This event may or may not indicate the permanent loss of the reservation (i.e., any error associated with the reservation whether permanent or temporary will be reported). If requested on an endpoint (without specifying the connection ID), the request refers to all present and future connections on that endpoint. When reported, the connectionID is always supplied along with a reason for the error indicated as a parameter. One of the following possible reasons for loss MUST be included as the parameter when the event is reported:
リソース・エラー（再）：これは、リソース予約の誤差は、接続の寿命の間に発生したことを示しています。このイベントは、パラメータで要求されていませんが、パラメータ（以下可能な値を参照）で報告されています。このイベントは、または予約の永久的な損失を示していてもいなくてもよい（すなわち、永久的または一時的に報告されるかどうかの予約に関連する任意のエラー）。 （接続IDを指定せずに）エンドポイントで要求された場合、要求は、そのエンドポイント上のすべての現在および将来の接続を指します。報告された場合には、connectionIDは常にパラメータとして示されたエラーの理由と一緒に供給されています。イベントが報告されたときの損失のために、以下の考えられる理由の一つは、パラメータとして含まれている必要があります
- "resverr" is used to indicate that a ResvErr message was
received.
- "patherr" is used to indicate that a PathErr message was received.
- 「のPathErrは」のPathErrメッセージが受信されたことを示すために使用されます。
- "other"
- 「その他」
In addition to a parameter indicating one of the reasons above, additional information on the type of error MAY be included as a second parameter in the form of a quoted string.
上記の理由のいずれかを示すパラメータに加えて、エラーのタイプに関する追加情報は、引用符で囲まれた文字列の形態の第2のパラメータとして含まれていてもよいです。
Example report might include:
例の報告は、次のものがあります
O: res/rl@0A3F58(resverr)
O：RES / RL @ 0A3F58（resverr）
or
または
O: res/rl@0A3F58(resverr, "some additional commentary")
O：RES / RL @ 0A3F58（resverr、 "いくつかの追加の解説"）
Note that this event will not be reported if an error occurs while a resource reservation is initially being set up (i.e., the event was only reported as a result of an error that occurred after the reservation was set up).
リソース予約が最初に（すなわち、イベントのみ予約を設定した後に発生したエラーの結果として報告された）に設定されている間にエラーが発生した場合、このイベントは報告されないことに注意してください。
Resource Lost (rl): Loss of reservation during the life of a connection can be reported by using the "rl" event. This event is not requested with a parameter, but is reported with a parameter (see below for possible values). If requested on an endpoint (without specifying the connection ID), the request refers to all present and future connections on that endpoint.
リソースロスト（RL）：接続の生活の間に予約の損失は、「RL」イベントを使用して報告することができます。このイベントは、パラメータで要求されていませんが、パラメータ（可能な値については下記を参照）で報告されています。 （接続IDを指定せずに）エンドポイントで要求された場合、要求は、そのエンドポイント上のすべての現在および将来の接続を指します。
When reported, the connectionID is always supplied along with a reason for the loss indicated as a parameter. One of the following possible reasons for loss MUST be supplied as the parameter when the event is reported:
報告された場合には、connectionIDは常にパラメータとして示された損失の理由と一緒に供給されています。イベントが報告されたときの損失のために、以下の考えられる理由の一つは、パラメータとして指定されなければなりません。
- "resvtear" indicating that the reservation loss was indicated by ResvTear message.
- 予約損失がたResvTearメッセージによって示されたことを示す「たResvTear」。
- "pathtear" indicating that the reservation loss was indicated by PathTear message.
- 予約損失がPathTearメッセージによって示されたことを示す「pathtear」。
- "other"
- 「その他」
In addition to a parameter indicating one of the reasons above, additional information on the type of error MAY be included as a second parameter in the form of a quoted string.
上記の理由のいずれかを示すパラメータに加えて、エラーのタイプに関する追加情報は、引用符で囲まれた文字列の形態の第2のパラメータとして含まれていてもよいです。
Example report might include:
例の報告は、次のものがあります
O: res/rl@0A3F58(ResvTear)
O：RES / RL @ 0A3F58（たResvTear）
or
または
O: res/rl@0A3F58(ResvTear, "some other commentary")
O：RES / RL @ 0A3F58（たResvTear、 "他のいくつかの解説"）
Note that this event will not be reported if an error occurs while a resource reservation is initially being set up (i.e., the event is only reported if the reservation was lost after it was initially set up).
リソース予約が最初に（それが最初にセットアップされた後に予約が失われた場合、すなわち、イベントのみが報告されている）に設定されている間にエラーが発生した場合、このイベントは報告されないことに注意してください。
Package Name: A Version: 1
パッケージ名：バージョン：1
---------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------------------------------------------------------------|
| ann(url) | Play an Announcement | | TO, C variable |
| oc | Operation Complete | x | |
| of | Operation Failure | x | |
---------------------------------------------------------------
Changes from the previous version: change to conform to standard reporting of operation failure and operation complete events.
前バージョンからの変更：変更は、動作不良や動作の完全なイベントの標準報告に準拠します。
The announcement signal is qualified by a URL name:
アナウンス信号がURL名によって修飾されています。
S: ann(http://scripts.example.net/all-lines-busy.au)
S：アン（http://scripts.example.net/all-lines-busy.au）
The URL name MAY be followed by a list of initial parameters, separated by commas. However, standard parameters are not included as part of this package definition (Note: use of additional parameters is optional and would result in a proprietary interface).
URL名は、カンマで区切られた初期パラメータのリストが続きます。しかし、標準的なパラメータは、このパッケージ定義（：追加のパラメータの使用は任意であり、独自のインターフェイスをもたらす注）の一部として含まれていません。
The gateway SHOULD support one or more standard URL schemes such as:
ゲートウェイは、次のような1つまたは複数の標準のURLスキームをサポートする必要があります。
* file, http, ftp (RFC 1738 [28]), which indicate where the audio file is located (where to load the file from before playing the audio file on the gateway).
*ファイル、HTTP、FTP（RFC 1738 [28]）、音声ファイルが置かれている場所を示す（ここで、ゲートウェイ上のオーディオファイルを再生する前からファイルをロードします）。
* RTSP URL (section 3.2 of RFC 2326 [29]), which in this case allows the media gateway to directly initiate playing of the announcement via an RTSP server.
* RTSP URL（RFC 2326のセクション3.2 [29]）、この場合には直接RTSPサーバを介してアナウンスの再生を開始するためにメディアゲートウェイを可能にします。
The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Further indications of failure are provided in the operation failure event as a comment after the name of the failed event in the form of a quoted string.
正常な応答（「200」のリターンコード）のための前提条件は、正しい構文と機能（サポートは、この要求のために利用可能である）です。標準MGCPのリターンコードは、障害が発生した場合に適用されます。故障のさらなる適応症は、引用符で囲まれた文字列の形で失敗したイベントの名前の後にコメントとして動作不良イベントで提供されています。
If the announcement cannot be played out for a reason determined after a successful response to the request has been provided, an operation failure event will be returned. The failure MAY be explained by some commentary (in the form of a quoted string), as in:
発表は決定理由のために再生できない場合は、要求に成功した応答が提供された後、動作不良のイベントが返されます。失敗は同様に、（引用符で囲まれた文字列の形で）いくつかの論評によって説明することができます。
O: a/of(a/ann,"file not found")
O：（A /アン、 "ファイルが見つかりません"）の/
The "operation complete" event will be detected when the announcement is played out.
アナウンスが再生されるとき、「動作完了」イベントが検出されます。
O: a/oc(a/ann)
O：/ OCまで（へ/中）
Package Name: Script Version: 1
パッケージ名：スクリプトのバージョン：1
-----------------------------------------------------------------
| Symbol | Definition | R | S | Duration |
|-----------------------------------------------------------------|
| ir(..) | Intermediate Results/Req.| x | BR | |
| java(url,...) | Load & Run java script | | TO | variable |
| oc | operation complete | x | | |
| of | operation failure | x | | |
| perl(url,...) | Load & Run perl script | | TO | variable |
| tcl(url,...) | Load & Run TCL script | | TO | variable |
| vxml(url,...) | Load & Run VXML doc. | | TO | variable |
| xml(url,...) | Load & Run XML script | | TO | variable |
-----------------------------------------------------------------
Changes from the previous version of the package: "vxml" was added as a language type for loading and running VXML documents; change to conform with standard reporting of operation failure and operation complete events; addition of "ir" event.
パッケージの以前のバージョンからの変更点：「VXMLは、」ロードとVXML文書を実行するための言語タイプとして追加されました。動作不良や動作の完全なイベントの標準報告に準拠するように変更。 「IR」イベントの追加。
The current definition defines keywords for the most common languages. More languages may be defined in later versions of this package.
現在の定義は、最も一般的な言語のキーワードを定義します。その他の言語は、このパッケージのそれ以降のバージョンで定義されていてもよいです。
The "signal" specifying the scripting language is parameterized with a URL indicating the location of the script. The URL parameter MAY be optionally followed by a comma-separated list of arguments as initial parameters to use in running the script. URL schemes may include file ftp, or http schemes with syntax according to RFC 2396 [30]. As an example:
スクリプト言語を指定する「信号」は、スクリプトの場所を示すURLでパラメータです。 URLパラメータは、必要に応じてスクリプトを実行する際に使用する初期パラメータとして引数をカンマで区切ったリストを続けてもよいです。 URLスキームは、RFC 2396 [30]に記載の構文を使用して、ファイルのFTP、またはHTTPスキームを含むことができます。例として：
S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2, ...,argn)
S：スクリプト/ VXML（ftp://ftp.example.net/credit-card.vxml,arg1,arg2、...、ARGN）
The argument list "arg1,arg2,...,argn" is passed to the script/document as a list of initial parameters.
引数リスト「ARG1、ARG2、...、ARGNは」初期パラメータのリストとしてスクリプト/ドキュメントに渡されます。
The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Some further (non-application/script specific) failure indications MAY be provided in the operation failure event as a comment in the form of a quoted string following the name of the failed event.
正常な応答（「200」のリターンコード）のための前提条件は、正しい構文と機能（サポートは、この要求のために利用可能である）です。標準MGCPのリターンコードは、障害が発生した場合に適用されます。いくつかの（非アプリケーション/スクリプトの特定）、さらに失敗指摘は、失敗したイベントの名前を、以下の引用符で囲まれた文字列の形式でコメントとして動作不良イベントに提供することができます。
Example
例
O: script/of(script/vxml,"file not found")
O：（スクリプト/ VXML、 "ファイルが見つかりません"）のスクリプト/
The script produces an output, which consists of one or several text strings, separated by commas. This provides the return-status of the script as well as return parameters (if there are any)
スクリプトは、カンマで区切られた1つのまたは複数のテキスト文字列で構成された出力を生成します。これは、（もしあれば）、スクリプトのリターン・ステータスだけでなく、リターン・パラメータを提供します
O: script/oc(script/vxml,return-status=<status>, name1=value1,name2=value2,...)
O：スクリプト/ OC（スクリプト/ VXML、リターン状況= <状態>、NAME1 = VALUE1、NAME2 =値2、...）
where <status> can have one of the values "success" or "failure". This is then followed by output parameters as a comma-separated list of name-value pairs.
ここで、<状態>は値を「成功」か「失敗」のいずれかを持つことができます。これは、名前と値のペアのカンマ区切りリストとして出力パラメータが続きます。
Intermediate Result/Request (ir(<params>)): This provides a way for:
中間結果/要求（IR（<のparams>））：これは、ための方法を提供します：
* The script to inform the Call Agent of intermediate results
(e.g., a case where it is important because of timing
concerns to inform the Call Agent prior to operation
complete).
* The script to request some information from the Call Agent.
*コール・エージェントからいくつかの情報を要求するスクリプト。
* The Call Agent to inform the script of some event or information that may be important for the operation of the script (in this case "ir" is used as a signal).
*コール・エージェントは、（この場合は「IR」信号として使用されている）でスクリプトの動作のために重要であるかもしれないいくつかのイベントや情報のスクリプトを通知します。
Parameters (i.e., <params>) SHOULD be a comma-separated list of name-value pairs e.g., ir(name1=value1,name2=value2,..). The Call Agent MAY include event parameters when it requests this event, in which case, the MGCP syntax requirements require that the action be specified (e.g., "R: ir(N)(nam1=value1,name2=value2,..)").
パラメータ（すなわち、<paramsは>）名前と値のペア、例えば、IR（NAME1 = VALUE1、NAME2 =値2、...）のカンマ区切りのリストであるべきです。それはこのイベント、その場合には、MGCP構文の要件は、アクションを指定する必要を要求するときにコールエージェントは、イベントのパラメータを含むことができる（例えば、「R：IR（N）（NAM1 = VALUE1、NAME2 =値2、...）」 ）。
If the Call Agent requests "ir" as a signal, at least one parameter MUST be provided.
コールエージェントが信号として「IR」を要求した場合、少なくとも1つのパラメータが提供されなければなりません。
When requesting the "ir" signal, the Call Agent MUST also repeat the original script signal. This is in order to be consistent with the semantics of TO signals in MGCP (i.e., if the original "script" signal is not included, then the signal/script will be stopped). The only problem with this is that there is a possible race condition in which a request to send an "ir" signal could occur just as the script stopped. In order to avoid this confusion, the following is RECOMMENDED: when the script signal is included with an "ir" signal, include a parameter (of the script signal) to indicate that this is not a new instance of the script i.e., if there is no script executing at the present time do not start executing a new one.
「IR」信号を要求する場合、コールエージェントはまた、元のスクリプト信号を繰り返す必要があります。これは、MGCPの信号の意味論と一致するため（元の「スクリプト」信号が含まれていない場合、すなわち、信号/スクリプトが停止される）です。これで唯一の問題は、「IR」信号を送信するための要求は、スクリプトが停止と同じように発生することがあった可能性競合状態が存在することです。この混乱を避けるために、以下を推奨します：スクリプト信号が「IR」信号に含まれている場合、そこにあれば、これはスクリプトすなわちの新しいインスタンスではないことを示すために（スクリプト信号の）パラメータを含めます新しいものの実行を開始していない現時点で実行一切のスクリプトではありません。
The "ir" signal is only associated with an executing script. If none are running when a request for the event/signal is made, or if a new script request is not included with the request, then the "ir" signal/event will not be executed (i.e., the "ir" event with its parameters is passed to an existing script for parsing and execution and is considered opaque as far as MGCP as concerned. If no such script exists, response code "800" will be returned, indicating that the script is not executing).
「IR」信号のみ実行スクリプトに関連付けられています。どれもイベント/信号の要求がなされているか、新しいスクリプト要求が要求に含まれていない場合は、「IR」信号/イベントが持つ（すなわち、「IR」イベントを実行されませんとき実行されていない場合は、そのパラメータが解析および実行のために既存のスクリプトに渡され、限り懸念MGCPのような不透明であると考えられる。そのようなスクリプトが存在しない場合、レスポンスコード「800」は、スクリプト）が実行されていないことを示す、戻されます。
The following response code is associated with this package:
以下の応答コードは、このパッケージに関連付けられています：
Code Text Explanation
コードテキスト説明
800 Script not Request for "ir" signal or event Executing but no script is executing at the time the request was received.
800スクリプトは、「IR」信号またはイベントの実行要求ではないが、何のスクリプトは、要求を受信した時点で実行されません。
Note that package specific error codes include the package name following the error code. For example, if error code 800 occurs in response to a request with a transaction ID of 1001, it would be sent as:
パッケージ固有のエラーコードがエラーコード以下のパッケージ名が含まれていることに注意してください。エラーコード800は、1001のトランザクションIDを持つリクエストに応答して発生した場合、例えば、それは次のように送信されます。
800 1001 /SCRIPT
800 1001 / SCRIPT
The following packages and their versions have been registered with IANA as per the instructions in [1].
以下のパッケージとそのバージョンは、[1]の指示に従ってIANAに登録されています。
Package Title Name Version
------------- ---- -------
Announcement A 1
DTMF D 1
Digit Map Extension DM1 0
Media Format FM 0
Generic G 1
Handset H 1
Line L 1
RTP R 1
Resource Reservation RES 0
Script SCRIPT 1
Supplementary Tones SST 0
Signal List SL 0
Trunk T 1
The following extension digit map letter has been registered with IANA:
次の拡張ケタ地図手紙はIANAに登録されています。
Package Letter
------- ------
DM1 P
The following Local Connections have been registered with IANA:
以下のローカル接続は、IANAに登録されています：
Field Name
------- -----
Media Format fmtp
Reservation Confirmation r-cnf
Reservation Direction r-dir
Resource Sharing r-sh
The MGCP packages contained in this document do not require any further security considerations beyond those indicated in the base MGCP specification [1].
この文書に含まれるMGCPパッケージは、ベースMGCP仕様[1]に示された値を越える更なるセキュリティ上の配慮を必要としません。
Special thanks are due to the authors of the original MGCP 1.0 specification: Mauricio Arango, Andrew Dugan, Isaac Elliott, Christian Huitema, and Scott Picket.
マウリシオ・アランゴ、アンドリューデュガン、イサクエリオット、クリスチャンのHuitema、およびスコット・ピケット：特別な感謝は、元のMGCP 1.0仕様の作者によるものです。
Thanks also to the reviewers of this document, including but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks.
また、を含むがこれらに限定されない、このドキュメントの校閲、おかげ：ジェリーKamitses、ソナス・ネットワーク。デイブ・アウエルバッハ、ダン・ウィング、シスコシステムズ、エド・ガイ、EMCソフトウェア。マーティンWakley、ノーテルネットワーク。
[1] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[1]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（MGCP）バージョン1.0"、RFC 3435、2003年1月。
[2] Bellcore, "LSSGR: Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP)", GR-317-CORE, Issue 2, December 1997.
[2] Bellcoreの、 "LSSGR：総合デジタル通信網ユーザ部（ISDNUP）を使用したコール制御用スイッチングシステムジェネリック要件"、GR-317-CORE、2号、1997年12月。
[3] ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724, November 1988.
[3] ITU-T、 "電話ユーザパートシグナリング手順"、ITU-T Q.724、1988年11月。
[4] ANSI, "OAM&P - Terminating Test Line Access and Capabilities", T1.207-2000.
[4] ANSI、 "OAM＆P - テスト回線アクセスと機能の終了"、T1.207-2000を。
[5] Bellcore, "Notes on the Network", Special Report SR-2275, Issue 3, December 1997.
[5] Bellcoreのを、 "ネットワーク上の注意"、特別報告書のSR-2275、第3号、1997年12月。
[6] Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997.
[6]のBellcore、 "コール処理" GR-505-CORE、1号、1997年12月。
[7] Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, Issue 1, June 1996.
[7]ベルコア、 "LSSGR：アナログインタフェースのシグナリング"、GR-506-CORE、第1号、1996年6月。
[8] ITU-T, "Technical Characteristics of Tones for the Telephone Service", ITU-T E.180, March 1998.
[8] ITU-T、ITU-T E.180、1998年3月 "電話サービスのためのトーンの技術的特性"。
[9] ITU-T, "Various Tones Used in National Networks", ITU-T E.180, Supplement 2, January 1994.
[9] ITU-T、 "ナショナル・ネットワークで使用される様々なトーン"、ITU-T E.180、サプリメント2、1994年1月。
[10] ITU-T, "Applications of Tones and Recorded Announcements in Telephone Services", ITU-T E.182, March 1998.
[10] ITU-T、 "トーンのアプリケーションと電話サービスで録画お知らせ"、ITU-T E.182、1998年3月。
[11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586, Issue 1, June 2000.
[11] Bellcoreの、「転送でんわFSD-1450年1月2日、GR-586、第1号、2000年6月のサブは-ます。
[12] Bellcore, "CPE Compatibility Considerations for the Voiceband Data Transmission Interface", SR-TSV-002476, December 1992.
、SR-TSV-002476 [12] Bellcoreの、 "音声帯域データ伝送インタフェースのためのCPEの互換性に関する注意事項"、1992年12月。
[13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000.
[13] Bellcoreの、 "LSSGR：ビジュアルメッセージ待機インジケータジェネリック要件（FSD 2000年1月2日）"、GR-1401、問題01、2000年6月。
[14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section 6.6, GR-30-CORE, Issue 02, December 1998.
[14] Bellcoreの、 "LSSGR音声帯域データ伝送インタフェース"、セクション6.6、GR-30-CORE、発行02、1998年12月。
[15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[15]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue 01, June 2000.
[16] Bellcoreの、 "LSSGR：待つ、FSD 1201年1月2日コール"、GR-571、問題01、2000年6月を。
[17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR-531-CORE, Issue 1, June 2000.
[17] Bellcoreの、 "LSSGR：検証接続のFSD 25-05-0903"、GR-531-CORE、1号、2000年6月。
[18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000.
[18] Bellcoreの、「LSSGR：CLASS特集：キャッチホン、FSD 1090年1月2日、GR-575、問題01、2000年6月にアイデンティティ配達を呼び出します。
[19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[19]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR-220, Issue 2, April 2002.
[20] Bellcoreの、 "クラスの特徴：画面編集（FSD 30-28-0000）"、GR-220、第2号、2002年4月。
[21] ITU-T, "Procedure for document facsimile transmission in the general switched telephone network", ITU-T T.30, April 1999.
[21] ITU-Tは、ITU-T T.30、1999年4月 "一般に文書のファクシミリ送信手順は、交換電話網"。
[22] ITU-T, "300 bits per second duplex modem standardized for use in the general switched telephone network", ITU-T V.21, November 1988.
[22] ITU-T、ITU-T V.21、1988年11月 "一般的に使用するための標準化第二二重モデム当たり300ビット交換電話網"。
[23] Telcordia Technologies, "Telcordia Technologies Specification of Signaling System Number 7", GR-246-CORE, Issue 7, December 2002.
[23]のTelcordia Technologies社、GR-246-CORE、7号、2002年12月 "シグナリングシステム番号7ののTelcordia Technologies社の仕様"。
[24] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue 02, December 2000.
[24]のTelcordia Technologies社、 "LSSGR：CLASS特集：名前配達ジェネリック要件を呼び出す（FSD 1070年1月2日）"、GR-1188、問題02、2000年12月。
[25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000.
[25]のTelcordia Technologies社、 "LSSGR：CLASS機能：ナンバーデリバリー（FSD 1051年1月2日）の呼び出し"、GR-31、問題01、2000年6月を。
[26] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[26] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、RFC 3551、2003年7月。
[27] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[27]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、1997年9月。
[28] Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[28]バーナーズ=リー、T.、Masinter、LとM. McCahill編、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[29] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[29] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[30] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[30]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[31] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[31]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[32] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
冗長のために[32]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、JC、ベガ・ガルシア、A.及びS.フォッシー-Parisis、「RTPペイロードオーディオデータ」、RFC 2198、1997年9月。
[33] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[33] Schulzrinneと、H.およびS. 2000 Petrackと、 "DTMFケタ、電話トーン、および電話信号のためのRTPペイロード"、RFC 2833、2000年5月。
[34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.
[34]フォスター、B.、 "MGCP CASパッケージ"、RFC 3064、2001年2月。
[35] PacketCableTM, Dynamic Quality if Service Specification, http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07- 030815.pdf
[35] PacketCableTM、動的なサービス品質仕様であれば、http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07- 030815.pdf
[36] PacketCableTM Network-Based Call Signaling Protocol http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08- 030728.pdf
[36] PacketCableTMネットワークベースのコールシグナリングプロトコルhttp://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08- 030728.pdf
[37] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds., "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[37]グローブ、C.、パンタレオ、M.、アンダーソン、T.及びT.テイラー編、 "ゲートウェイ制御プロトコルバージョン1"、RFC 3525、2003年6月。
[38] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
[38]アランゴ、M.、デュガン、A.、エリオット、I.、のHuitema、C.及びS.ピケット、 "メディアゲートウェイ制御プロトコル（MGCP）バージョン1.0"、RFC 2705、1999年10月。
Bill Foster Cisco Systems
ビル・フォスターシスコシステムズ
Phone: +1 250 758 9418 EMail: bfoster@cisco.com
電話：+1 250 758 9418 Eメール：bfoster@cisco.com
Flemming Andreasen Cisco Systems Edison, NJ 08837
フレミングAndreasenのシスコシステムズエジソン、NJ 08837
EMail: fandreas@cisco.com
メールアドレス：fandreas@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。