[要約] RFC 3660は、MGCPパッケージの基本的な仕様を定義しており、MGCPを使用してメディアゲートウェイを制御するためのプロトコルを提供します。このRFCの目的は、MGCPパッケージの標準化と相互運用性の向上です。
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
基本的なメディアゲートウェイ制御プロトコル（MGCP）パッケージ
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.
Copyright（c）The Internet Society（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.
このドキュメントは、コミュニティの情報のために公開されています。現在、多くの製品に展開されている非ITFプロトコルについて説明しています。実装者は、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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).
RFC 2705 [38]で定義されているMGCP 1.0（および現在[1]で更新された）は、MGCPの以前のバージョンと比較して、オンオフ（OO）シグナルの意味についていくつかの追加の説明を提供しました。これは、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.
一貫性と相互運用性を向上させるためになされた別の変更は、定義された信号があるが、「操作完了」と「操作障害」イベントが以前に一部として含まれていなかったパッケージに「操作完全」と「操作障害」イベントを追加することでした。パッケージの。定義上、タイムアウトタイプ信号を含むすべてのパッケージには、[1]で定義されている「操作障害」（ "of"）および「操作完了」イベントが含まれています。パッケージの説明のかどうか。
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」と「of」イベントの定義が含まれている場合、パッケージで提供されるイベント定義は、ここに示されているものをオーバーライドする場合があります。しかし、そのような慣行は落胆しており、潜在的な後方互換性の問題を回避するために純粋に許可されています。
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、アナウンスサーバー、およびスクリプトパッケージは、このドキュメントに含まれています。更新されたベース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.
場合によっては、既存のパッケージに新しいイベントが追加されています。もちろん、既存のパッケージの変更により、パッケージバージョン番号がUnversioned（バージョン0）からバージョン1に更新されました。
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]の2つのパッケージは含まれていません。これらは「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桁を上回る方法が定義されていなかったため、MF CASは、別のドキュメントで他のパッケージ（つまり、「MS」、「MO」、および「MD」パッケージ）によって提供されるようになりました。
* 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]に含まれているものを超えて、新しいパッケージも含まれています。これらは、信号リスト、リソース予約、メディア形式、補足サービス、およびデジットマップ拡張パッケージです。特に、リソース予約（ "res"）およびメディア形式（ "fm"）パッケージは、新しいLocalConnectionOptionsが含まれているという点で、このドキュメントの他のパッケージとは異なります。これは、[1]の新しい拡張ルールによって許可されています。このタイプの将来のパッケージは、名前空間の問題を避けるために、ローカル接続オプションの前にパッケージのプレフィックスを使用する必要があります（ "<package-name>/<local connection option>"）。ただし、MGCP 1.0の更新に関連するこれらのパッケージの到着のタイミングのため、これは「RE」パッケージと「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.
* タイムアウト信号に。
* 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.
期間：信号のデフォルトの期間を指定します。信号の説明に明示的に記載されていない限り、期間が不特定のままになっている場合、デフォルトのタイムアウトは無限であると想定されます。期間は、信号が複雑なシーケンス（たとえば、スクリプトまたは桁の拍動）が含まれる場合に変動すると宣言される場合があります。この場合、時間は処理時間または信号環境のいずれかによって異なる場合があります。
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)
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、つまり1秒全体で割り切れる最も近い非ゼロ値に丸められる場合があります。ただし、パッケージ内の個々の信号定義は、他の丸めルールを定義する場合があります。
Note that Time-Out signals that involve other parameters still allow the use of the "to" signal parameter e.g.:
他のパラメーターを含むタイムアウト信号は、「to」信号パラメーターを使用することを可能にすることに注意してください。
S: T/sit(1,to=3000)
The order of the "to" parameter relative to the other parameters is not important.
他のパラメーターに対する「to」パラメーターの順序は重要ではありません。
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）シグナル、シグナル、およびイベントの「 "" and " - "の場合は、パラメーターがありませんそのパッケージのイベントの説明。
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.
デフォルトのタイムアウト値は、このパッケージで「to」信号パラメーターによって定義されているタイムアウト信号のコールエージェントが過度にリダンスする場合があることに注意してください。詳細については、このドキュメントのセクション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 HERTZ）と同じ周波数とレベルを使用しますが、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）：ITU-T E.180 [8]およびE.182 [10]を参照してください。このマップは、北米でトーンを再注文するためにマップします（GR-506コア[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].
FAXトーン（FT）：V.21 Fax Preambleの存在によってFAXコールが検出されるたびにFAXトーンイベントが生成されます。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
G/LD@0A3F58
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回答トーン（ANS）またはV.8修正回答トーン（ANSAM）トーンを示します。これは、データコールの存在を意味することに注意してください。また、イベントの名前にもかかわらず、モデム以外のデバイスはそのようなトーン、たとえばファックスマシンを生成する可能性があることに注意してください。
Operation Complete (oc): The standard definition of operation complete [1].
操作Complete（OC）：操作の標準定義Complete [1]。
Operation Failure (of): The standard definition of operation failure [1].
操作障害（of）：操作障害の標準定義[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].
Ringback（RBK（ConnectionID））：これは「RT@ConnectionID」のエイリアスであり、後方互換性のみでここに含まれています。コールエージェントは、新しい実装の接続を介したリングバックに「RBK（ConnectionID）」の代わりに「RT@ConnectionID」を使用することをお勧めします。リングバック信号は接続に適用されますが、「RBK」信号は「@Connection」構文をサポートしていません。信号が要求される場合、[1]で指定されているように、接続IDまたは接続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]を参照してください。リンギングトーンとも呼ばれます - 接続が行われ、呼び出しの信号が呼び出されたパーティーまたはサービスポイントに適用されていることを呼び出し元に助言するトーン。北米では、このトーンは、周波数が440および480 Hertzとそれぞれ-19 dBMの2つのACトーンの組み合わせであり、-16 dBMの合計レベルを提供します。
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.
可聴リングトーンのケイデンスは2秒オンで、続いて4秒オフになります。GR-506-CORE [7] -LSSGR：シグナル伝達、セクション17.2.5を参照してください。
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.
この信号は、構文「RT@ConnectionID」を使用して、エンドポイントに直接適用するか、接続に接続することができます。エンドポイントにリングバック信号が適用される場合、エンドポイントがオンフックと見なされた場合、リングバックトーンを再生しようとするエラーと見なされ、そのような試行が行われたときにエラーを返す必要があります（エラーコード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」、「DO」、「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トーンWildCardを含むDTMFトーンは、イベントを要求するときに[1]で定義されているイベント範囲表記を使用できることに注意してください。たとえば、「D/[0-9]（n）」。
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.
デフォルトのタイムアウト値は、このパッケージで「to」信号パラメーターによって定義されているタイムアウト信号のコールエージェントが過度にリダンスする場合があることに注意してください。詳細については、このドキュメントのセクション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に記載されています。オンフックである電話でDTMFトーンを再生しようとするエラーが発生し、そのような試行が行われたときにエラーを返す必要があります（エラーコード402-電話オンフック）。イベントコードは、数字マップで指定できます。GR-506コア[7]、セクション15に従って、信号として要求された場合、50 msの最小トーン期間の後に45ミリ秒の最小間診断期間が続きます。「S：SL/S（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 = <tone>、to = <time>、su = <trueorfalse>）））：このイベントは、指定された<tone>が<time>よりも大きいかどうかを示すために使用できます。表示された値（および期間を超えたら報告されます）。パラメーターは任意の順序で提供できます。<tone>の値は、DTMFパッケージ（イベントの場合はxを含むが信号ではなく）で指定されたDTMFトーンシンボル（パッケージ名を含めない）のいずれかになります。このパラメーターが存在しない場合、発生するDTMFトーンが報告されます。パラメーター<time>はミリ秒で、ゲートウェイで最も近い10ミリ秒に丸められる場合があります。イベントを要求するときに要求できる<time>の最小値は40ミリ秒です。信号を要求する場合、要求できる<time>の最小値は50ミリ秒です。イベントまたは信号のいずれかで要求できる<time>の最大値は60000ミリ秒です。イベントとして要求されたときに「to = <<time>」パラメーターが存在しない場合、イベントはトーンが完了したときにトーンの完全な期間（最大60000ミリ秒）を報告します。観測値として報告されると、両方のパラメーターが常に提供されます。この場合、<tone>は実際のトーンが検出され、<time>は次のとおりです。
* The <time> specified in the request (possibly rounded), or
* リクエストで指定された<time>（おそらく丸みがあります）、または
* If the request did not contain a "to=<time>" parameter, the full duration of the tone.
* リクエストに「to = <<time>」パラメーターが含まれていない場合、トーンの完全な期間。
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は帯域内に渡され続けるべきであることを示しています。パラメーターのデフォルト値は、欠落している場合、「false」です。「SU」パラメーターは、「D/DD」を信号として要求するときに含めてはなりません。
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」は、dtmfトーンをtoへの信号として生成する機能を提供します。信号として適用されると、操作が完了する前に追加の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秒以上押しているかどうかを検出するために、RequestEvents行「r：d/dd（n）（dg =＃、to = 2000）」でリクエストを行うことができます。。結果の観察された平均線は「O：d/dd（dg =＃、to = 2000）」です。
Suppose instead, that the RequestedEvents line contains
代わりに、RequestedEvents行に含まれるとします
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)
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 = <tone>、<on-or-off>））：この信号は、オンオフ信号としてDTMFトーンを生成するために使用されます。<tone>パラメーターは、DTMFパッケージの特定のトーンのシンボルのいずれかです（つまり、「0」から「9」、「A」、「B」、「C」、「D」、「*」、または「＃」）。<オンまたはオフ>インジケータは、[1]に従ってon on on on and "" - "の場合です。<tone>パラメーターを提供する必要があります。そうしないと、538-「イベント/信号パラメーターエラー」のリターンコードが応答で提供されます。<on-or-off>パラメーターが欠落している場合、デフォルトは通常どおり信号をオンにすることです（つまり、 ""はデフォルトです）。「」と「 - 」は予約された文字であり、<tone>パラメーターと簡単に区別されるため、パラメーターの順序は重要ではありません。
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].
操作Complete（OC）：これは、操作Completeの標準定義です[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)
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.
「数字マップに従って蓄積する」アクションで使用すると、Timer Tは2つの値のいずれか（T）またはT-批評的です。「現在のダイヤル文字列」が数字マップのパターンのいずれかを一致させるために少なくとも1つのシンボルが必要な場合、タイマーTは、部分的なダイヤルタイミングに対応する値t-startialを採用します。マッチを作成するのに必要なタイマーがすべてである場合、タイマーTは、クリティカルダイヤルタイミングに対応する値T臨界を引き受けます。「数字マップに従って蓄積する」アクションなしでタイマーTを使用すると、タイマーTは値t臨界を引き受けます。T-starialのデフォルト値は16秒で、T-Criticalのデフォルト値は4秒です。プロビジョニングプロセスは、これらの両方を変更する場合があります。タイマーTが使用されない場合、桁内タイミングは実行されません。
The following examples illustrate this. Consider the digit map:
次の例はこれを示しています。数字マップを考えてみましょう。
(xxxxxxx|x11T)
（xxxxxxxx | 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が数字マップに従って蓄積されると仮定します。「4」と言う最初のDTMF入力では、少なくとも1つのシンボルが必要であるため、タイマーTはt-partialの値で開始されます。「1」が入力された場合、T-Partialの値でタイマーTの再起動につながります。「1」が再び入力された場合、「411」の現在のダイヤル文字列があり、マッチを作成するために必要なすべてのタイマーがあります。したがって、タイマーTは値t-criticalで再起動されます。
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].)
（1 [2-3T]。）
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-臨界に設定されることにつながります。
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-Partialに設定されることにつながります。さらに、Timer 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入力を検出するために、数字マップと一致する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」、「MM」、「OC」、「PST」、「QT」、「SIT」、および「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"信号はooからto;に変更されました。「as」と「bl」はooから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.
デフォルトのタイムアウト値は、このパッケージで「to」信号パラメーターによって定義されているタイムアウト信号のコールエージェントが過度にリダンスする場合があることに注意してください。詳細については、このドキュメントのセクション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].
回答監督（AS）：このイベントは、発生回答監督を示すために使用されます。ほとんどの場合、コールリクエストに応じて安定したオフフックの結果です。このイベントは、パッケージの以前のバージョンとの後方互換性のために含まれています。好ましい代替品は、適切なCASパッケージで「Answer」イベントを使用することです[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）：ITU-T E.180 [8]を参照してください。北米では、Station Busyは2つのACトーンと480および620 HERTZの周波数とそれぞれ-24 dBMのレベルの組み合わせで、-21 dBMの合計レベルが得られます。ステーションのビジートーンのケイデンスは0.5秒オンで、その後0.5秒オフが続き、その後繰り返されます。GR-506-CORE [7] -LSSGR：シグナル伝達、セクション17.2.6を参照してください。
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を参照）。信号として生成される場合、トーンの周波数はまたは-8 Hz内でなければなりませんが、イベントに対応するトーンの周波数は-30 Hz内でなければなりません。
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を参照）。信号として生成される場合、トーンの周波数は-20 Hz内でなければなりませんが、イベントに対応するトーンの周波数は-30 Hz内でなければなりません。
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]で定義されている連続性テスト要件、およびBellcore 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線から2線接続の場合、コールエージェントは次のようなリクエストを発信元のゲートウェイに送信する場合があります。
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/CO2、T/OC、T/OF OF
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,+)
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).
元のゲートウェイは、要求された「Go」トーンを送信し、適切な「リターントーン」を探します。リターントーンを受信すると、発信元のゲートウェイはGOトーンを削除し、指定されたパフォーマンス制限（つまり、GR-246コア、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」信号は、信号のタイムタイム時に操作の完全なイベントが発生するように信号を送信します。デフォルト以外のタイムアウト値が必要な場合、「〜」パラメーターを使用できます（例： "s：t/co1（to = 2000）"）。
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.
ゲートウェイがタイムアウト前に連続性テストの障害を検出すると、操作障害イベントが生成されます。それ以外の場合、連続性テストの障害は、タイムアウトが発生する前にリターントーンイベントを受信できないことによって決定されます（操作完全イベント）。一般的な信号と同様に、操作完全および操作失敗イベントは、信号の名前でパラメーター化されます。
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/CO2」）。
* A notification of the operation failure event indicates failure prior to timeout (i.e., "O: t/of(t/co1)").
* 操作障害イベントの通知は、タイムアウト前の障害を示します（つまり、「O：t/of（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)").
* 操作完全イベントの通知は、タイムアウトの発生前にリターントーンが適切に受信されなかったことを示しています（つまり、「O：T/OC（T/CO2）」）。
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 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」信号が要求されます）。Goトーンが消えるとすぐに、リターントーンが削除されることを確認するのは、終了端までです。コールエージェントは、連続性テストの結果が得られたときに終了終了時に、「コンテスト」または「ループバック」接続（または「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 Hzが受信され、1780 Hzが送信またはその逆）。対応する「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).
Continuity Transponder（ct（in = <tone-in>、out = <tone-out>、<or->））：この信号は、接続モードとは無関係にトランスポンダー機能を提供するために使用されます。つまり、これは代替方法です。「ContTest」接続モードと同じ機能を提供します。パラメーターは任意の順序で提供できます。<tone-in>および<tone-out>パラメーターは、これらのシンボルに関連する2010 Hzおよび1780 Hzトーンに対応する値「CO1」または「CO2」を持つことができます。トーンの1つが「CO1」である場合、もう1つは「CO2」でなければなりません（つまり、<tone-in>と<tone-out>は異なる値を持つ必要があります。ループバックが必要な場合は、「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:
検出すると、<tone-in>、<tone-out>は見返りに生成されます。<tone-out>に対応するトーンは、次のいずれかまで生成され続けます。
* The signal is explicitly turned off (e.g., "S: t/ct(-)") or
* 信号は明示的にオフになっています（例： "s：t/ct（ - ）"）または
* Removal of the <tone-in> tone is detected.
* <tone-in>トーンの削除が検出されます。
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.
Loopback（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 Hz- [4]を参照してください。
Operation Complete (oc): This is the standard definition of operation complete [1].
操作Complete（OC）：これは、操作Completeの標準定義です[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）：1000 Hzトーン - [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.
Reorder Tone（RO）：このマップは、ITU-T e.182仕様の輻輳トーンにマップします。北米では、再注文トーンは、2つのACトーンと480および620 HERTZの周波数とそれぞれ-24 dBMのレベルの組み合わせであり、-21 dBMの合計レベルが得られます。再注文トーンのケイデンスは0.25秒オンで、その後0.25秒オフが続き、継続的に（タイムアウトまで）繰り返されます。GR-506-Core [7]、セクション17.2.7を参照してください。
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].
Special Information Tone（SIT（＃））：ITU-T E.180 [8]で説明されているように、特別な情報トーンは、3つのトーンが生成され、その後に1秒のサイレントピリオド（合計から期間）が生成されるトーン期間で構成されています。約2秒）。信号として使用する場合は、1〜7のパラメーター値でパラメーター化する必要があり、次の意味はSR-2275、[5]のセクション6.21.2で定義されています。
-------------------------------------------
| 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の小数点以下でパラメーター化され、ゲートウェイが検出する必要があるトーンを示す必要があります。結果の通知には、パラメーターも含まれます。他の国では、国固有の定義を備えた1つ以上の特別な情報トーンがある場合があります（ITU-T E.180Supp。2[9]を参照）。この場合、[9]で定義されている特別な情報トーン1は座っています（1）、特別な情報トーン2はSIT（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)
NTFY 3002 DS/DS1-3/6@GW-O.HATEVER.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テストラインテストの進行状況トーン（-10 dBM0で2225 Hzまたは-25 Hz）。[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進数として提供されます。パラメーターが省略されている場合、デフォルト値は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が想定されます。パターンは、観測値で（パラメーターが要求されていない場合でも）。
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/OF
In this case the Call Agent will either receive:
この場合、コールエージェントは以下を受信します。
* An ObservedEvent indicating that the test has passed (i.e., "O:t/op(95)") or
* テストが渡されたことを示す観察vent（すなわち、「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.
* パターンが受信される前にタイムアウトが発生したことを示す観測値（つまり、「O：T/OC（T/TP）」）は、テストが失敗したことを示します。もちろん、操作の障害も同様に障害を示します。
No Circuit (zz): This is an alias for Special Information Tone 2, i.e., "sit(2)".
回路なし（ZZ）：これは、特別な情報トーン2、つまり「Sit（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」シグナルは、それぞれOOから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.
デフォルトのタイムアウト値は、このパッケージで「to」信号パラメーターによって定義されているタイムアウト信号のコールエージェントが過度にリダンスする場合があることに注意してください。詳細については、このドキュメントのセクション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）：ITU-T E.180 [8]を参照してください。北米では、Station Busyは2つのACトーンと480および620 HERTZの周波数とそれぞれ-24 dBMのレベルの組み合わせで、-21 dBMの合計レベルが得られます。ステーションの忙しいトーンのケイデンスは0.5秒で、その後0.5秒オフが繰り返されます。GR-506-Core [7]、セクション17.2.6を参照してください。オンフックである電話で忙しいトーンを試してみようとするのはエラーと見なされ、そのような試みが行われたときにエラーを返す必要があります（エラーコード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:
Caller-ID（CI（時間、数字、名前））：GR-1188 [24]、GR-30-CORE [14]、およびGR-31 [25]を参照してください。後方互換性のために、3つのフィールドのそれぞれはオプションですが、それぞれのコンマは常に含まれます。一般的な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/dd/hh/mm」としてコード化されています。ここで、mmは01〜12の間の月の2桁の小数値です。また、瞬間は軍事現地時間に従ってコード化されている2桁の値です。たとえば、00は真夜中、01は午前1時、13は午後1時です。（注：月、日、時間、分の各値の各値には、1月の月が「1」ではなく2桁の「01」で示されます）。
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).
名前パラメーターは、呼び出し線名を識別する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"、 "John Doe"）
An example indicating that the name and number are private:
名前と番号がプライベートであることを示す例：
S: l/ci(09/14/17/26,P,P)
S：L/CI（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]仕様を参照してください。北米では、ダイヤルトーンは、350および440 HERTZの周波数とそれぞれ-13dBMのレベルを持つ2つの連続ACトーンの組み合わせであり、-10 dBMの合計レベルを提供します。GR-506-CORE [7] -LSSGR：シグナル伝達、セクション17.2.1を参照してください。オンフックである電話でダイヤルトーンを再生しようとするのはエラーと見なされ、そのような試行が行われたときにエラーを返す必要があります（エラーコード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）：GR-506-CORE [7]、セクション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].
Tone On Hold（HT）：「Hold」に配置された呼び出しサブスクライバーを安心させるために使用されるトーン。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）：メッセージ待機インジケータートーンは、ダイヤルトーン（それぞれ-13dbmで350および440 Hertz）と同じ周波数とレベルを使用しますが、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].
操作Complete（OC）：これは、操作Completeの標準定義です[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）：ネットワーク切断は、ファーエンドパーティーが切断されていることを示します。ラインに送信される信号は、国によって異なる場合があるため、メディアゲートウェイにプロビジョニングされます。北米では、この信号はオープンスイッチ間隔であり、ループ電流フィードオープン信号（LCFO）がラインに適用されます（GR-506-CORE [7]を参照してください。]、セクション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).
オフフック警告トーン（OT）：オフフック警告トーン、レシーバーオフフックトーン（ROHトーン）としても知られています。これは、電話が正しくハングアップしていないときに電話がかかる刺激的な騒音です。北米では、ROHトーンは、1400 HERTZ、2060 HERTZ、2450 HERTZ、2600 HERTZの周波数で4つのトーンを組み合わせることで生成され、0.1秒で0.1秒オフの登場で繰り返されます。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）：GR-506-CORE [7]、セクション14を参照してください。プロビジョニングプロセスは、リンギングケイデンスを定義する場合があります。リンギング信号は、適用するリンギングサイクル（繰り返し）の最大数を指定する信号パラメーター「REP」でパラメーター化される場合があります。「rep」の値は10進数で指定されており、1から255の値を持つことができます。
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).
「rep」パラメーターが指定されている場合、繰り返しの数が完了したときの信号タイムアウト（つまり、操作完全イベントを要求でき、タイムアウト/リング数の最後に発生します）。
If the "rep" parameter is supplied, then any timeout ("to") value that is included will be ignored, i.e.:
「rep」パラメーターが提供される場合、含まれるタイムアウト（ "to"）値は無視されます。
S: l/rg(rep=6,to=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.:
パラメーター「to = 12000」が含まれていない前の例と同じように扱われます。もちろん、「to」パラメーターが「担当者」なしで含まれている場合、それはI.E。：に作用されます。
S: l/rg(to=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]、セクション14を参照してください。R1〜R5のデフォルト値は、特徴的なリンギングパターン1〜5で定義されています。GR-506コア[7]。R0、R6、およびR7のデフォルト値は、通常の鳴り響きです（つまり、同じケイデンス「RG」）。プロビジョニングプロセスは、これらの各信号のリンギングケイデンスを定義する場合があります。特徴的なリンギング信号は、適用するリンギングサイクルの最大数（繰り返し）を指定する信号パラメーター「rep」でパラメーター化される場合があります。「rep」の値は10進数で指定されており、1〜255の値を持つことができます。
The following will apply the ringing signal for up to 6 ringing cycles:
以下は、最大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)
「rep」パラメーターが指定されている場合、繰り返しの数が完了したときの信号タイムアウト（つまり、操作完全イベントが要求され、タイムアウト/リング数の最後に発生します）
If the "rep" parameter is supplied, then any timeout ("to") value that is included will be ignored, i.e.:
「rep」パラメーターが提供される場合、含まれるタイムアウト（ "to"）値は無視されます。
S: l/r1(rep=6,to=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.:
パラメーター「to = 12000」が含まれていない前の例と同じように扱われます。もちろん、「to」パラメーターが「担当者」なしで含まれている場合、それはI.E。：に作用されます。
S: l/r1(to=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.
Reorder Tone（RO）：このマップは、ITU-T e.182 [10]仕様の輻輳トーンにマップします。北米では、再注文トーンは、周波数が480および620 HERTZの2つのACトーンとそれぞれ-24 dBMのレベルの組み合わせであり、合計レベルの-21 dBMを提供します。再注文トーンのケイデンスは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）：「リマインダーリング」とも呼ばれます。このトーンは、呼び出しが転送されたことを示すために物理転送ライン（アイドル状態）に適用されるリングのバーストであり、ユーザーに通話が転送されることを思い出させることができますサブ機能がアクティブです。米国では、それは0.5（-0、0.1）のパワーリンギングのバーストであると定義されています（[11]を参照）。
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]:
Special Information Tone（SIT（＃））：ITU-T E.180 [8]で説明されているように、特別な情報トーンは、3つのトーンが生成されるトーン期間で構成され、その後に1秒のサイレントピリオドが続きます（合計まで約2秒の期間）。SR-2275、セクション6.21.2 [5]で定義されている次の意味は、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 |
-------------------------------------------
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.
他の国では、国固有の定義を備えた1つ以上の特別な情報トーンがある場合があります（ITU-T E.180Supp。2[9]を参照）。この場合、[9]で定義されている特別な情報トーン1は座っています（1）、特別な情報トーン2はSIT（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.
Stutter Dial Tone（SL）：Stutter Dial Tone（GR-506-Core [7]のRecallダイヤルトーンとも呼ばれ、ITU-T E.182 [10]の「特別なダイヤルトーン」が使用されます）は、アクションとリクエストを確認するために使用されます。ユーザーからの追加の入力。例のアプリケーションは、宛先アドレスを入力する前に、コールウェイティングをキャンセルすることです。
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:
Stutterダイヤルトーン信号は、信号パラメーター「del」でパラメーター化される場合があります。これにより、確認トーンとダイヤルトーンの間に適用されるミリ秒の遅延が指定されます。パラメーターは、0〜10000ミリ秒の任意の値を持つことができ、100（つまり、10分の1）で割り切れる最も近い非ゼロ値に丸められます。以下は、確認トーンとダイヤルトーンの間に1.5秒の遅延でStutterダイヤルトーンを適用します。
S: l/sl(del=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）：2秒の440 Hzトーン、10秒ごとに1/2秒のトーンが続きます。このイベントは、パッケージの以前のバージョンとの後方互換性のために含まれています。
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".
Visualメッセージ待機インジケーター（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.
代替コール待合トーン（WT、WT1、..、WT4）：ITU-T E.180 [8]を参照してください。北米のトーン定義については、GR-506-CORE [7]、セクション14.2を参照してください。「WT」と「WT1」はどちらも、北米では300プラスまたはマイナス50ミリ秒に適用される440 Hzのトーンであるデフォルトのコール待合トーンのエイリアスです。その後、トーンは10秒後に1回繰り返されます。
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).
これらの信号は、デフォルトのタイムアウト値が12秒のタイムアウト信号であるため、単一のリクエストでトーンを2回再生できます（GR-571-CORE [16]を参照）。ただし、ケース（GR-575コア[18]の要件R3-73）があり、単一のトーンのみが必要です。その場合、コールエージェントは、2番目のトーン（例： "s：wt（to = 2000）" " - 2秒後に信号を停止して2番目のトーンが発生しないように信号を停止する）を排除するために、より短いタイムアウト期間でリクエストを行う場合があります。）。
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）：ITU-T E.180 [8]を参照 - ベルコアドキュメント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 Hz（DTMF #DIGIT）の60ミリ秒と350 440 Hzの940ミリ秒で構成されています。ダイヤルトーン）、200 msの時定数で指数関数的に減衰します。Bellcore Document 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」信号タイプがOOからBRに変更されました。
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.:
Caller-ID：コールエージェントからイベントとして要求された場合、イベントをパラメーター化してはなりません。ただし、イベントが報告されたときにパラメーターが含まれています。
O: l/ci(09/14/17/26,"555 1212","John Doe")
O：L/CI（09/14/17/26、 "555 1212"、 "John Doe"）
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）：イベントとして要求された場合、コールエージェントには、いくつかのリングの後に報告するリクエストを示すREPパラメーターをオプションに含めることができます。
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)
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」イベントと同様に、これらのいずれかがイベントとして要求されたときに「rep」パラメーターが含まれている場合、それも報告されます。パラメーターで要求されていない場合、パラメーターもレポートに含まれていません。その場合、イベントは、要求されたケイデンスが検出されるとすぐにイベントが報告されます。
Stutter Dial Tone (sl): Stutter Dial Tone MUST not be parameterized when requested as an event. However, the "del" parameter is reported.
Stutter Dial Tone（SL）：Stutterダイヤルトーンは、イベントとして要求されたときにパラメーター化してはなりません。ただし、「del」パラメーターが報告されています。
RQNT 1234 aaln/1@rgw2.example.net X: AB123FE0 R: h/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)
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.
* ハンドセットパッケージのすべての信号には、信号として要求されたときに「〜」パラメーターを含めることができます。
* However, requests to be notified about these events MUST NOT include the "to" parameter, i.e., the "to" parameter is not valid in RequestedEvents.
* ただし、これらのイベントについて通知されるリクエストには、「to」パラメーター、つまり「to」パラメーターは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.
デフォルトのタイムアウト値は、このパッケージで「to」信号パラメーターによって定義されているタイムアウト信号のコールエージェントが過度にリダンスする場合があることに注意してください。詳細については、このドキュメントのセクション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.
Conference Depart（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.
Conference Join（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].
コンフォートトーン（CM）：快適なトーンは、通話が処理されており、発信者が待つ必要があることを示すために使用されます。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）：ITU-T E.180、サプリメント2 [9]を参照してください。これは「空いているトーン」とも呼ばれ、北米では「再注文トーン」にマップします（GR-506-Core [7]、セクション17.2.7を参照）。
Operation Complete (oc): The standard definition of operation complete [1].
操作Complete（OC）：操作の標準定義Complete [1]。
Operation Failure (of): The standard definition of operation failure [1].
操作障害（of）：操作障害の標準定義[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].
Pay Tone（PT）：支払いが必要であることを示すトーン。ITU-T E.182 [10]を参照してください。
Package Name: dm1 ("dm" followed by the number "1") Version: 0 Extension Digit Map Letters: P
パッケージ名：dm1（ "dm"に続く番号 "1"）バージョン：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].
操作Complete（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（<リスト>））：<list>には、再生される信号のコンマ分離されたリストが含まれています。<list>の各信号は、type brまたはtypeのいずれかでなければなりません。意味的には、信号リストはまだタイプタイムアウトの単一のパラメーター化された信号として扱われます。リストの信号は、指定された左から右の順序で次々に完了するように再生されます。リスト内の各信号のパッケージを指定する必要があります。たとえば、DTMF数字123456を再生するには：
S: sl/s(d/1,d/2,d/3,d/4,d/5,d/6)
S：SL/S（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.
これにより、DTMF桁1、2、3、4、5、および6が整理されます。
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.
リスト内の信号の1つとして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).
ゲートウェイが順序付けられた信号リストを再生すると、無限のタイムアウトで信号に遭遇する場合、信号リスト信号が停止するまでその信号を再生し続けることに注意してください（つまり、リストの後半の他の信号は再生されません）。
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」）イベントが要求された場合、リストの最後の信号が再生されたときに一度検出されます（リストに信号があるかどうかに関係なく）。操作完全イベントは、信号リスト名自体のみを報告します。つまり、次のように提供されるパラメーターはありません。
O: sl/oc(sl/s)
O：sl/oc（sl/s）
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.
* イベントが発生した時点で再生されていたリストの信号がタイプである場合、To Signalはすぐに停止し、リスト内の他の信号は再生されません。
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 [15]の「FMTP」属性と類似しており、対応するSDP FMTP属性を使用できるすべての同じメディア形式に適用できます（つまり、メディア形式のMIMEタイプのメディア形式パラメーター）。メディア形式のパラメーターは、キーワード「fmtp」または「o-fmtp」としてエンコードされ、その後、メディア形式名（mimeサブタイプのみ）で始まるコロンと引用文字そのメディア形式で。簡単にするために、「コーデック」と「メディア形式」という用語を次のように交換可能に使用します。複数の形式は、次のような「FMTP」ローカル接続オプションを複数回繰り返すことによって示される場合があります。
L:a: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"
The two formats may be mixed.
2つの形式が混在する場合があります。
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"
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パラメーターがコーデックの最初または2回目の発生に適用されるかどうかは明らかではありません。それの問題は、コーデックの順序付けが重要であること（つまり、コーデックが好ましい順序でリストされている）であり、上記の構文は「formatx」が優先されるかどうかを示す方法を提供しません（つまり、最初の「codec1」に関連付けられています）またはそうでない（つまり、2番目の「Codec1」に関連付けられています）。このジレンマを解決するために、同じコーデックが複数の形式で要求される場合、「fmtp」形式の文字列のコーデック名の後にコロンと<オーダー>が続きます。nコーデックリストの同じコーデックの発生、つまり：
L:a: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.
「formatx」は、「a：codec1; codec1」リストの「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.
文字列「O-」（つまり、「O-FMTP」）を使用して「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",...
A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", 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:
1つの例では、RFC 2833 [33]で定義されているように、メディア形式「電話イベント」と併せてメディア形式のパラメーターLCOを使用しています。「FMTP」メディア形式のパラメーターなしでメディア形式の「電話イベント」が使用されている場合、DTMF桁（RFC 2833 [33]の電話イベント0-15）が想定されています - そのような慣行は落胆します。一方、メディア形式のパラメーターLCOを使用して、RFC 2833を介して要求されているイベントの正確なセットを指定することができます[33]。例：
L: a:PCMU;telephone-event,fmtp:"telephone-event 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.
別のケースでは、コールエージェントは、一部のフォーマットパラメーターが「必須」であることを示している場合がありますが、他のパラメーターはオプションです。以下の例では、電話イベント0-15は「必須」ですが、電話イベント16、70、71はオプションです。
L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71",
fmtp:"telephone-event 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"
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"
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
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"
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
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"
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.
これらの2つのローカルコネクションオプションは、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.
デフォルトのタイムアウト値は、このパッケージで「to」信号パラメーターによって定義されているタイムアウト信号のコールエージェントが過度にリダンスする場合があることに注意してください。詳細については、このドキュメントのセクション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」および「CO2」など）は、接続ID（「s：r/co1@connectionid」など）を示す必要があります。[1]に記載されているように、ConnectionIDの「*」ワイルドカードを使用して、すべての既存の接続にイベントが要求される場合があります。
Example:
例：
R: r/uc@* (request to detect uc on all connections) or
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)
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 "）。これらは、ネットワークループバック（NetWloop）またはネットワーク連続性テスト（NetWtest）モードと組み合わせて使用して、RTP回路の連続性をテストできます。ただし、IPの連続性をテストする場合、1トーンテストで十分な場合、つまり、一方の端で「CO1」を生成および検出し、ネットワークループバックモードの接続モードをもう一方の端にあります。テストは、トーンではなく電話イベントを使用して実行できることに注意してください。つまり、RFC 2833 [33]のイベント167は「CO1」に対応しています。この場合、次のようなローカル接続オプションを使用して接続リクエストが作成されます。
L: a:PCMU;telephone-event,fmtp:"telephone-event 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.
電話イベント167のサポートをリクエストするために。両端がイベントをサポートする場合、CO1トーン自体とは対照的に、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]が受信されたことを示しています。この通知は、この接続のゲートウェイによって送信されたパケットが目的地に到着しなかったか、受け入れられなかったことを示しています（たとえば、ポートが閉じられた）。このイベントが要求されると、イベントが通知される前に発生しなければならないICMPの到達可能なパケットの数を示すために、1〜255の小数点を持つ単一のパラメーターを含めることができます。パラメーターが提供されていない場合、リクエストが付属している場合、デフォルト値は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)
* 最初のパラメーターは、受信したICMPの到達不可能なパケットの数です（つまり、リクエストに含まれていたのと同じ値、または要求されたイベントがパラメーター化されていない場合の値3）
* The second parameter is the error code indicated in the ICMP unreachable packet, e.g.:
* 2番目のパラメーターは、ICMPの到達不可能なパケットに示されているエラーコードです。
0 = net unreachable;
0 = net reachable;
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)
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.
この場合、接続ID 364823との接続でこのゲートウェイから送信されたRTPおよび/またはRTCPパケットの結果として、5つのICMPポートの到達不可能なパケットが受信された場合、通知が発生します。
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の到達不可能なパケットが受信されたことを示しています。2番目のパラメーター（ "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」です。これは、メディアゲートウェイに、コントローラーがジッターバッファサイズの変更を必要とすることを伝えます。メディアゲートウェイからコントローラーへの通知の構文は「JI（####）」です。####は1から65536の小数です。
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.
Media Start（MA）：メディア開始イベントは、最初の有効な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].
操作Complete（OC）：これは、操作Completeの標準定義です[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）：パケット損失率は、括弧で示されている100,000パケットあたりのパケットの指定された10進数（1〜100,000の範囲）のしきい値を超えています。たとえば、PL（10）は、100,000パケットで10のドロップレートです。このイベントは、コールエージェントが報告したいパケット損失率を示すパラメーターで要求されます。パケットの損失がその値を超える場合、イベントは同じパラメーターで報告されます。イベントは、パケット損失のしきい値を超えた場合にのみ1回報告されます。報告されると、次のリクエストはパケット損失測定値を再挿入し、しきい値を再度超えたときに報告します。
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（<timeout>、st = <start-time>）））：このイベントは、rtpもRTCPパケットもこの接続で<timeout>値に等しい期間（秒）。タイムアウト値は、リクエストが行われたときにパラメーターの1〜65535の小数点として供給できます。<timeout>パラメーターは、イベントが報告されたときに観測因子に供給されます - 次に、使用される値を単純に繰り返します。タイマーの有効期限が切れる前にRTPまたはRTCPパケットが受信された場合、タイマーはリセットされて再起動されます。このイベントは、指定された期間中に指定された接続にRTPまたはRTCPパケットが到着することなくタイマーが期限切れになる場合にのみ生成されます。イベントが<timeout>パラメーターなしで要求されている場合、60秒のデフォルトのタイムアウトが想定されることに注意してください。<timeout>値は、リクエストにタイムアウト値が示されていなくても、観察された平均で引き続き報告されます（その場合、デフォルト値は示されます）。これは、イベントが発生すると、タイマーを再発行するためにさらにリクエストが必要であるという点で、ワンショットイベントです。
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:
別のオプションの<Start-Time>パラメーターも含めることができます。これは、タイマーがいつ開始されるかを示すために使用されます。次の値のいずれかを持つことができます。
* "im" for immediate i.e., the timer starts as soon as the request is received. This is the default.
* 即時の場合、つまり、リクエストが受信されるとすぐにタイマーが起動します。これがデフォルトです。
* "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.
* 「RA」は、RTCPパケットをもう一方の端から受信した後にのみタイマーが起動することを示すことを示します（つまり、リクエストが作成された後に最初のRTCPパケットが受信されたときにタイマーが開始されます）。もう一方の端が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.
<timeout>または<start-time>のいずれかがリクエストに含まれる場合がありますが、レポートには<timeout>値のみが含まれていることに注意してください。
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)
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パケットが接続364823で120秒間受信されていない期間がある場合、通知が発生します。
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)
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）のように、括弧内に囲まれたミリ秒の数ミリ秒でパケット化期間がいくつかの小数に変更されたことを示しています。
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）：このイベントは、このパッケージの以前のバージョンとの互換性を維持するために、ここでのみ含まれています。このイベントはパラメーターなしで要求されますが、報告されると、CodecがPCM A-Lawに変更されたことを示すために、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".
「予約リクエスト」、「予約方向」、「予約確認」、「リソース共有」など、リソースの予約を行う際に、多くのローカルコネクションオプションパラメーターが使用されています。
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パラメーターが含まれているかどうかに依存します（「制御された負荷」または「保証サービス」のいずれかが示されています）。Modify Connection（MDCX）要求に予約の変更が必要であり、「予約要求」パラメーターがLocalConnectionOptionsに含まれていないが、その接続の以前の接続要求のLocalConnectionOptionsに含まれていた場合、「予約要求」値はデフォルトは、その接続の以前に保存された値になります。Modify Connection（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".
* RSVPの「パス」メッセージの発現を開始します。「Send-Receive」または「Send-Receive」を指定したLocalConnectionOptionsパラメーターを予約する場合。
* Start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the reservation direction parameter specified "receive-only" or "send-receive".
* 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).
* 接続が「send-only」、「send-receive」、「conference」、「network loop back」または「network continuityテスト」モードにある場合、RSVPの「パス」メッセージの発現。
* 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.
* 接続が「受信のみ」、「送信受信」、「会議」、「ネットワークループバック」、または「ネットワーク連続性テスト」モードにある場合、「パス」メッセージを受信するとすぐに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予約の別のローカルコネクションオプションパラメーターは、リソース予約の事前条件（[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.
* 予約確認パラメーターが「なし」に設定されている場合、ゲートウェイは予約の完了を待たずに接続要求を「ACK」します。これがデフォルトの動作です。
* 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.
* 「予約確認」パラメーターが「送信専用」に設定されている場合、パスメッセージが送信され、対応する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.
* 予約確認パラメーターが「send-receive」に設定されている場合、ゲートウェイはパスメッセージが送信され、対応する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.
値「受信専用」および「送信受信」は、Gatewayが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.
事前条件は、リソースの予約が要求されている方向に対してのみ追加する必要があります。指示が事前条件として追加され、その方向がリソースの予約で要求されなかった場合、その方向は単に事前条件として無視する必要があります。
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情報は返品できません。予約が完了するまで発生しない最終的な「ACK」。これにより、SDP情報を反対側に渡す必要があるため、これはデッドロックになる可能性があります。SDP情報とConnectionIDは、仮の応答と最終応答の両方に含める必要があります。失われた最終応答の迅速な検出を確保するために、トランザクションに対する暫定的な回答の後に発行された最終的な応答が認められることに注意してください。つまり、最終応答に空の「応答」パラメーターを含めるものとすることに注意してください（[1]を参照）。
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：複数の接続でネットワークリソースを共有することが可能かもしれません。例は、コール待合シナリオで、一度に1つの接続のみがアクティブになります。同様の接続セットを備えた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.
* $が「この接続」を参照する場合、値「$」を指定できます。この値は、CREATE接続を実行するときに使用され、この接続とリソースを共有する意図を示します。
* 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 Dynamic of Service [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).
* キーワード「R」としてエンコードされたリソース予約パラメーター、続いてコロンと値「G」（保証サービス）、「CL」（制御荷重）または「BE」（BEの努力）が続きます。
* 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："が示されていない）、この接続のリソースを他の接続と共有しなくなることを示します
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:
リソースエラー（RE）：これは、リソース予約のエラーが接続の存続期間中に発生したことを示しています。このイベントはパラメーターでは要求されませんが、パラメーターで報告されます（以下の値を参照）。このイベントは、予約の永続的な損失を示している場合と、そうでない場合があります（つまり、恒久的または一時的に予約に関連するエラーが報告されます）。（接続IDを指定せずに）エンドポイントで要求された場合、リクエストは、そのエンドポイントのすべての現在および将来の接続を指します。報告されると、ConnectionIDは常にパラメーターとして示されたエラーの理由とともに提供されます。イベントが報告された場合、次の可能な理由の1つをパラメーターとして含める必要があります。
- "resverr" is used to indicate that a ResvErr message was received.
- 「resverr」は、resverrメッセージが受信されたことを示すために使用されます。
- "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.
上記の理由の1つを示すパラメーターに加えて、引用された文字列の形式の2番目のパラメーターとしてエラーのタイプに関する追加情報を含めることができます。
Example report might include:
レポートの例には以下が含まれます。
O: res/rl@0A3F58(resverr)
or
または又はそれとも若しくは乃至或るいは
O: res/rl@0A3F58(resverr, "some additional commentary")
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は常にパラメーターとして示される損失の理由とともに提供されます。イベントが報告された場合、次の可能な理由の1つをパラメーターとして提供する必要があります。
- "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.
上記の理由の1つを示すパラメーターに加えて、引用された文字列の形式の2番目のパラメーターとしてエラーのタイプに関する追加情報を含めることができます。
Example report might include:
レポートの例には以下が含まれます。
O: res/rl@0A3F58(ResvTear)
or
または又はそれとも若しくは乃至或るいは
O: res/rl@0A3F58(ResvTear, "some other commentary")
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)
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/of（a/ann、 "ファイルが見つかりません"）
The "operation complete" event will be detected when the announcement is played out.
「Operation Complete」イベントが発表されたときに検出されます。
O: a/oc(a/ann)
O：a/oc（a/ann）
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：script/vxml（ftp://ftp.example.net/credit-card.vxml、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：スクリプト/of（script/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,...)
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.
<status>は、値「成功」または「失敗」の1つを持つことができます。次に、その後、名前と価値のペアのコンマ分離されたリストとして出力パラメーターが続きます。
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,..)").
パラメーター（すなわち、<パラメラ>）は、name-valueペアのコンマ分離されたリストである必要があります。コールエージェントには、このイベントを要求するときにイベントパラメーターを含めることができます。その場合、MGCP構文要件はアクションを指定する必要があります（例： "r：ir（n）（nam1 = value1、name2 = value2、.."）。
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」信号/イベントが実行されない場合は、パラメーターは、解析と実行のために既存のスクリプトに渡され、関係する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.
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:
パッケージ固有のエラーコードには、エラーコードに続くパッケージ名が含まれることに注意してください。たとえば、1001のトランザクションIDでリクエストに応じてエラーコード800が発生した場合、次のように送信されます。
800 1001 /SCRIPT
800 1001 /スクリプト
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.
元のMGCP 1.0仕様の著者に感謝します：Mauricio Arango、Andrew Dugan、Isaac Elliott、Christian Huitema、Scott Picket。
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.
この文書のレビュアーにも感謝します。これには以下に限定されません。Dave Auerbach、Dan Wing、Cisco Systems;Ed Guy、EMCソフトウェア。Nortel NetworksのMartin Wakley。
[1] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[1] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（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：Integrated Services Digital Networkユーザーパーツ（ISDNUP）を使用したコールコントロールのシステム一般要件の切り替え」、GR-317-CORE、1997年12月号2号。
[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、「Call Processing」GR-505-CORE、Issue 1、1997年12月。
[7] Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE, Issue 1, June 1996.
[7] Bellcore、「LSSGR：アナログインターフェイスのシグナリング」、GR-506コア、1996年6月1日、第1号。
[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、「Subfering Sub-Features FSD-01-02-1450、GR-586、Issue 1、2000年6月に電話してください。
[12] Bellcore, "CPE Compatibility Considerations for the Voiceband Data Transmission Interface", SR-TSV-002476, December 1992.
[12] Bellcore、「VoiceBandデータ送信インターフェイスのCPE互換性の考慮事項」、SR-TSV-002476、1992年12月。
[13] Bellcore, "LSSGR: Visual Message Waiting Indicator Generic Requirements (FSD 01-02-2000)", GR-1401, Issue 01, June 2000.
[13] Bellcore、「LSSGR：Visualメッセージ待機インジケーター一般的な要件（FSD 01-02-2000）」、GR-1401、Issue 01、2000年6月。
[14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section 6.6, GR-30-CORE, Issue 02, December 1998.
[14] Bellcore、「LSSGR VoiceBandデータ送信インターフェイス」、セクション6.6、GR-30-CORE、Issue 02、1998年12月。
[15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[15] Handley、M。and 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：Call Waiting、FSD 01-02-1201」、GR-571、Issue 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、2000年6月1日、第1号。
[18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000.
[18] Bellcore、「LSSGR：クラス機能：Call Call WaitingでのID配信の呼び出し、FSD 01-02-1090、GR-575、Issue 01、2000年6月。
[19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[19] Postel、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、2002年4月号2号。
[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、「一般的な切り替えの電話ネットワークで使用するために標準化された1秒あたり300ビットモデム」、ITU-T V.21、1988年11月。
[23] Telcordia Technologies, "Telcordia Technologies Specification of Signaling System Number 7", GR-246-CORE, Issue 7, December 2002.
[23] Telcordia Technologies、「Telcordia Technologies Signaling System Number 7」、GR-246-Core、2002年12月7号、第7号。
[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：クラス機能：名前配信の一般的な要件（FSD 01-02-1070）の呼び出し」、GR-1188、2000年12月2日、第02号。
[25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000.
[25] Telcordia Technologies、「LSSGR：クラス機能：通話番号配信（FSD 01-02-1051）」、GR-31、Issue 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] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Berners-Lee、T.、Masinter、L。and M. McCahill、eds。、「Uniform Resource Locators（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.、Rao、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[31] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[31] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.C.、Vega-Garcia、A。and S. Fosse-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. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
[34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.
[34] Foster、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] Groves、C.、Pantaleo、M.、Anderson、T。and T. Taylor、eds。、「Gateway Control Protocolバージョン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] Arango、M.、Dugan、A.、Elliott、I.、Huitema、C。and S. Pickett、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 2705、1999年10月。
Bill Foster Cisco Systems
ビル・フォスター・シスコ・システム
Phone: +1 250 758 9418
EMail: bfoster@cisco.com
Flemming Andreasen Cisco Systems Edison, NJ 08837
Flemming Andreasen Cisco Systems Edison、NJ 08837
EMail: fandreas@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。