RFC3660 日本語訳
3660 Basic Media Gateway Control Protocol (MGCP) Packages. B. Foster,F. Andreasen. December 2003. (Format: TXT=145147 bytes) (Updates RFC2705) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Foster Request for Comments: 3660 F. Andreasen Updates: 2705 Cisco Systems Category: Informational December 2003
コメントを求めるワーキンググループB.フォスターの要求をネットワークでつないでください: 3660のF.Andreasenアップデート: 2705年のシスコシステムズカテゴリ: 情報の2003年12月
Basic Media Gateway Control Protocol (MGCP) Packages
基本的なメディアゲートウェイ制御プロトコル(MGCP)パッケージ
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
IESG Note
IESG注意
This document is being published for the information of the community. It describes a non-IETF protocol that is currently being deployed in a number of products. Implementers should be aware of RFC 3525 [37], which was developed in the IETF Megaco Working Group and the ITU-T SG16, and is considered by the IETF and ITU-T to be the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address. The IETF Megaco Working Group and the ITU-T Study Group 16 are developing extensions to RFC 3525 [37] that for functions of the type in addressed in this document.
このドキュメントは共同体の情報のために発表されています。 それは現在多くの製品の中に配備されている非IETFプロトコルについて説明します。 ImplementersはMGCPがアドレスに設計されたのをRFC3525[37]を意識しているべきです。([37]はIETF Megaco作業部会とITU-T SG16で開発されて、IETFとITU-Tによって需要を満たす規格ベース(包含はセキュリティ問題を見直した)の方法であると考えられます)。 IETF Megaco作業部会とITU-T Study Group16はタイプの関数のために中に中にこのドキュメントを記述したRFC3525[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.
このドキュメントは基本的なセットのメディアゲートウェイControlプロトコル(MGCP)パッケージを提供します。 ジェネリック、線、トランク、受話器、RTP、DTMF(二元的な利根Multifrequency)、発表サーバ、およびスクリプトパッケージは、追加説明によるRFC2705からのパッケージのアップデートといくつかの場合、これらのパッケージの新しいバージョンです。 これらに加えて、5個の新しいパッケージがここで定義されます。 これらは、信号リストと、資源予約と、メディア形式と、補っているサービスとケタ地図拡大パッケージです。
Foster & Andreasen Informational [Page 1] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[1ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 パッケージ. . . . . . . . . . . . . . . . . . . . 3 1.2のリスト。 既存のRFC2705パッケージへの変化。 . . . . . . . . . 3 1.2.1. 信号タイプ. . . . . . . . . . . . . 3 1.2では、.2に変化してください。 操作完全、そして、操作失敗. . . . 3 1.2.3。 バージョン. . . . . . . . . . . . . . . . 4 1.2.4をパッケージしてください。 イベント定義、別名、および相互運用性問題. . . . . . . . . . . . . . . . . . . . . 4 1.2.5。 新しい出来事. . . . . . . . . . . . . . . . . . . 5 1.3。 新しいパッケージと除かれたパッケージ. . . . . . . . . . . 5 2。 パッケージ. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1。 一般的なメディア・パッケージ。 . . . . . . . . . . . . . . . . . 7 2.2. DTMFは.112.3をパッケージします。 トランクパッケージ。 . . . . . . . . . . . . . . . . . . . . . 16 2.4. パッケージ. . . . . . . . . . . . . . . . . . . . . . 24 2.5を裏打ちしてください。 受話器エミュレーションパッケージ。 . . . . . . . . . . . . . . . 33 2.6. 補っているサービスはパッケージに調子を変えさせます。 . . . . . . . . . . 36 2.7. ケタ地図拡大。 . . . . . . . . . . . . . . . . . . 37 2.8. リストパッケージに合図してください。 . . . . . . . . . . . . . . . . . . 38 2.9. メディアはパラメタパッケージ. . . . . . . . . . . . . 39 2.10をフォーマットします。 RTPパッケージ。 . . . . . . . . . . . . . . . . . . . . . . 43 2.11. 資源予約パッケージ. . . . . . . . . . . . . . 48 2.11.1。 記述。 . . . . . . . . . . . . . . . . . . 48 2.11.2. パラメタコード化. . . . . . . . . . . . . . . 52 2.11.3。 出来事. . . . . . . . . . . . . . . . . . . . . 53 2.12。 発表サーバパッケージ。 . . . . . . . . . . . . . . 55 2.13. スクリプトパッケージ. . . . . . . . . . . . . . . . . . . . . 56 3。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 59 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 59 5. 承認. . . . . . . . . . . . . . . . . . . . . . . 59 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.1。 引用規格. . . . . . . . . . . . . . . . . . 60 6.2。 有益な参照. . . . . . . . . . . . . . . . . 62 7。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 63 8。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 64
1. Introduction
1. 序論
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.
このドキュメントは基本的なセットのメディアゲートウェイControlプロトコル(MGCP)パッケージを提供します。 ジェネリック、線、トランク、受話器、RTP、DTMF、発表サーバ、およびスクリプトパッケージは、追加説明があるRFC2705[38]からのパッケージのアップデートといくつかの場合、これらのパッケージの新しいバージョンです。 これらに加えて、5個の新しいパッケージがここで定義されます。 これらは、信号リストと、資源予約と、メディア形式と、補っているサービスとケタ地図拡大パッケージです。
Foster & Andreasen Informational [Page 2] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[2ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [31].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[31])で説明されるように本書では解釈されることであるべきです。
1.1. List of Packages
1.1. パッケージのリスト
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]で定義されるようにMGCP1.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 |
-------------------------------------------
------------------------------------------- | パッケージ| 名前| |-------------------------------------------| | 一般的なメディア・パッケージ| G| | DTMFパッケージ| D| | トランクパッケージ| T| | 線パッケージ| L| | 受話器パッケージ| H| | 補っているサービスパッケージ| SST| | ケタ地図拡大| DM1| | 信号リストパッケージ| SL| | メディアはパッケージをフォーマットします。| FM| | RTPパッケージ| R| | 資源予約パッケージ| RES| | 発表サーバパッケージ| A| | スクリプトパッケージ| スクリプト| -------------------------------------------
1.2. Changes to Existing RFC 2705 Packages
1.2. 既存のRFC2705パッケージへの変化
1.2.1. Change in signal types
1.2.1. 信号タイプでは、変化してください。
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).
MGCP1.0、RFC2705[38]で定義されて、(そして、下にOn(OO)信号の意味における何らかの追加明確化がMGCPの以前のバージョンと比較されたなら、現在、[1])でアップデートしています。 伴走との信号定義のいくつかにおける何らかの矛盾へのこのリードはRFCで2705[38]をパッケージします。 ここに外のTime(TO)をタイプするためにオフなタイプOnからいくつかの信号を変えることによって含まれているパッケージの中にこれを修正してあります。
1.2.2. Operation Complete and Operation Failure
1.2.2. 操作完全、そして、操作失敗
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
一貫性と相互運用性を改良すると行われた別の変更が加えることになっていた、「操作が」 しかし、TOがある信号が定義したパッケージ、どこの「操作失敗」出来事を終了するか、「パッケージの」 出来事が以前に含まれていなかった操作の完全な「操作失敗」部分。 定義上それが含むすべてのパッケージ
Foster & Andreasen Informational [Page 3] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[3ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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")と「操作完全である」("oc")出来事を含みます、パッケージ記述の一部としてそれらを提供するかどうかの如何にかかわらず。
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.
外のTime信号のないパッケージが"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"と“of"出来事が支持されると明らかに言及するために良い習慣であると考えられます。 定義が全くパッケージに含まれていないなら、デフォルト構文と意味論は想定されます。
Please refer to [1] for additional details on these events.
これらの出来事に関する追加詳細のための[1]を参照してください。
1.2.3. Package Versions
1.2.3. パッケージバージョン
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、発表サーバ、およびスクリプトパッケージは以前にRFC2705[38]に含まれたパッケージの新しいバージョンです。 アップデートされたベースMGCP1.0仕様[1]はパッケージバージョンを監査する任意の能力を提供します。 道具がversionedしたどんなゲートウェイもSHOULDをパッケージします、また、このオプションを実行してください。
1.2.4. Event Definitions, Aliases and Interoperability Issues
1.2.4. イベント定義、別名、および相互運用性問題
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).
いくつかの場合、出来事には、同じくらいか他のパッケージと推薦状がCallエージェントによる補欠の今後の実現の使用のためにされた別名があります。 最大限のインターオペラビリティのために、ゲートウェイはまだこれらの出来事を実行しなければなりません(事実上、それらはいつも出来事、パッケージの中の信号などのすべてを実行しなければなりません)。
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.
以前に定義されたいくつかの出来事が、相互運用性を考慮するためにゲートウェイとCallエージェントの両方の特定の食糧を供給することを必要とします。 それらの場合では、その感情への警告は含まれています。
Foster & Andreasen Informational [Page 4] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[4ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
1.2.5. New Events
1.2.5. 新しい出来事
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までアップデートされるパッケージバージョン番号をもたらしました。
1.3. New Packages and Excluded Packages
1.3. 新しいパッケージと除かれたパッケージ
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:
RFC2705[38]からの2個のパッケージは含まれていません。 これらは、「mf」と「NAS」パッケージです。 これらのパッケージはRFC2705[38]で定義されたすべてのunversionedされた(バージョン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パッケージが定義された道を全くoutpulse MFケタに持っていなかったので、他のパッケージ(すなわち、「さん」、「MO」、および「MD」パッケージ)で現在、別々のドキュメントにMF CASを提供します。
* 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.
* RFC2705[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.
また、新しいパッケージはRFC2705[38]に含まれていたことを超えて含まれています。 これらは、信号リストと、資源予約と、メディア形式と、補っているサービスとケタ地図拡大パッケージです。 特にResource予約(「RES」)とメディア形式(「FM」)パッケージは他のパッケージと本書では新しいLocalConnectionOptionsを含んでいるという点において異なっています。 これは[1]に新しい拡大規則で許容されています。 このタイプの将来のパッケージは、名前スペース問題を避けるのに市内接続オプション(「<パッケージ名の>/<市内接続オプション>」)の正面でパッケージ接頭語を使用しなければなりません。MGCP1.0をアップデートすることに比例したこれらのパッケージの到着のタイミングのために、しかしながら、「RES」と「FM」パッケージのためにこれをしませんでした。 結果として起こる新しい市内接続オプションをIANAに登録してあります。 パッケージ接頭語が含まれている将来のケースのために、パッケージ名だけが、登録される必要があります。
2. Packages
2. パッケージ
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出来事にかかわるそれらのパッケージにおいて用語「信号」と「出来事」はイベント(「信号」)を適用するためにCallエージェントからメディアゲートウェイまでの要求を微分するのに使用されます、メディアゲートウェイに起こって、「通知される」「出来事」の検出を求める要求からCallエージェントまで。
Foster & Andreasen Informational [Page 5] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[5ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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: Callエージェントが出来事を要求できるなら、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: 何も出来事のためにこのコラムに現れないなら、Callエージェントは出来事に合図できません。 さもなければ、以下のシンボルは出来事のタイプを特定します:
* OO On/Off signal
* OO On/オフな信号
* TO Time-Out signal.
* 外のTO Timeは合図します。
* BR Brief signal.
* BR Briefは合図します。
In addition, a "C" will be included if the signal can be generated
on a connection.
さらに、信号が接続のときに発生できると、「C」は含まれるでしょう。
Duration: specifies the default duration of TO signals. If a
duration is left unspecified, then the default timeout will be
assumed to be infinite, unless explicitly noted in the description
of the signal. A duration may also be declared as being variable
in a case where signals involve complex sequencing (e.g., scripts
or digit out-pulsing) where the amount of time may vary with
either processing time or the signaling environment.
持続時間: TO信号のデフォルト持続時間を指定します。 持続時間が不特定のままにされると、デフォルトタイムアウトが無限であると思われるでしょう、信号の記述で明らかに注意されない場合。 また、持続時間は信号が処理時間かシグナリング環境のどちらかに従って時間が異なるかもしれないところで複雑な配列(例えば、スクリプトかケタの出ている脈打つ)にかかわる場合で可変であるとして宣言されるかもしれません。
Default time-out values may be over-ridden by the Call Agent for any Time-Out event defined in this document (with the exception of those that have a default value of "variable") by a "to" signal parameter which specifies the timeout value in milliseconds (see [1]). The following example indicates a timeout value of 20 seconds:
デフォルトタイムアウト値はミリセカンドでタイムアウト値を指定する“to"信号パラメタによって本書では(「可変」のデフォルト値を持っているものを除いて)定義されたどんな外のTime出来事のためにもCallエージェントによってくつがえされるかもしれません。([1])を見てください。 以下の例は20秒のタイムアウト値を示します:
S: sst/cw(to=20000)
S: sst/cw(=20000への)
As indicated in [1]: by default, a supplied time-out value MAY be rounded to the nearest non-zero value divisible by 1000, i.e., whole second. However, individual signal definitions within a package may define other rounding rules.
[1]にみられるように: デフォルトで、すなわち、供給されたタイムアウト値は全体の秒の間、1000年までに分割可能な最も近い非ゼロ値に四捨五入されるかもしれません。 しかしながら、パッケージの中の個々の信号定義は他の一周規則を定義するかもしれません。
Foster & Andreasen Informational [Page 6] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[6ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
Note that Time-Out signals that involve other parameters still allow the use of the "to" signal parameter e.g.:
他のパラメタにかかわる外のTime信号がまだ“to"信号パラメタの使用を許していることに注意してください、例えば:
S: T/sit(1,to=3000)
S: T/は座っています。(=1対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]に従って、下にOn(OO)信号は「+」 (つくことを意味します)か「-」でparameterizedされます(興味を失うことを意味して)。 パラメタがなくなるなら、デフォルトは信号をつけることです。 外のTime信号と異なって、出来事が起こる場合、下にOn信号は止まりません。
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.
オンにオフな(OO)信号のための外のTime(TO)信号のための“to"パラメタ、「+」、および「-」以外に、パッケージにおける信号と出来事には、そのパッケージのために出来事の記述で明らかに示されない場合、パラメタが本書ではありません。
In some of the signal definitions below, specific tone definitions are provided even though actual frequencies may vary from country to country.
以下での信号定義のいくつかに、実際の頻度は国によって違うかもしれませんが、特定のトーン定義を提供します。
2.1. Generic Media Package
2.1. 一般的なメディア・パッケージ
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|
---------------------------------------------------------------
--------------------------------------------------------------- | シンボル| 定義| R| S持続時間| |---------------------------------------------------------------| | Cf| トーンを確認してください。| | Br| | cg| 混雑トーン| | TO無限| | フィート| ファックストーン| x| | | それ| インタセプトトーン| | TO無限| | ld| 長い持続時間接続| C| | | mt| モデムトーン| x| | | oc| 操作完全です。| x| | | of| 操作失敗| x| | | 軽くたたくこと(###)| 検出されたパターン| x| OO| | Pt| 先取りトーン| | TO無限| | rbk(…) | Ringback| | TO、180秒のC| | rt| Ringbackトーン| | TO、180秒のC| ---------------------------------------------------------------
Foster & Andreasen Informational [Page 7] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[7ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
New events added to this package from the previously unversioned package: "oc"
新しい出来事は以前にunversionedされたパッケージからこのパッケージに加えました: "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"信号パラメタによってこのパッケージで定義されたどんな外のTime信号のためにもCallエージェントによってくつがえされるかもしれないことに注意してください。 このドキュメントのセクション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と440Hertz)としての同じ頻度とレベルを使用しますが、Confirmation利根は3回繰り返されたオンな下にある0.1秒で0.1秒のリズムでそうします。 GR506コア[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-CORE[7]セクション17.2.7について言及する)の再オーダー・トーンへのこの地図。
Fax Tone (ft):
The fax tone event is generated whenever a fax call is detected by
the presence of V.21 fax preamble. The fax tone event SHOULD also
be generated when the T.30 CNG tone is detected. See ITU-T
Recommendations T.30 [21] and V.21 [22].
ファックスで、トーン(フィート)を送ってください: ファックス呼び出しがV.21ファックス序文の存在によって検出されるときはいつも、ファックストーンイベントは発生します。 ファックスはイベントSHOULDに調子を変えさせます、また、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].
トーン(それ)を妨害してください: これはITU-T E.180 Supplement2[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
この出来事は接続に検出されます。 接続が全く要求の一部として指定されないとき、出来事は終点のためのすべての接続に適用されます、接続が創造される時にかかわらず。 「すべての接続」ワイルドカード、([1])がまた、このような場合使用されるかもしれなくて、事実上、一貫性のために好まれるのを確実にしてください。 コネ
Foster & Andreasen Informational [Page 8] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[8ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
either case, the name of the connection on which the event was
detected will be included when the event is observed, e.g.:
どちらのケースも、出来事が例えば観測されるとき、出来事が検出された接続の名前は含まれるでしょう:
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 Answerトーン(ANS)かV.8 Modified Answer利根(ANSam)がフェーズ反転のあるなしにかかわらず調子を変えるのを示します。 これがデータ呼び出しの存在を含意することに注意してください。 また、出来事の名前にもかかわらず、モデム以外の装置がそのようなトーン(例えば、ファックス装置)を発生させるかもしれないことに注意してください。
Operation Complete (oc):
The standard definition of operation complete [1].
操作の完全な(oc): 操作完全な[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.
検出されていた状態で(軽くたたくこと(###))、型に基づいて作ってください: この出来事は相互運用性を確実にするためにCallエージェントとメディアゲートウェイの間で同意される必要がある特別な食糧を供給することを必要とします。 それは、後方に「G」パッケージのバージョン0との互換性を維持するために保有されます。 10進0〜999までの数値が検出するパターンを指定している状態で、この出来事をparameterizedしなければなりません。 また、報告されると、パターンはパラメタとして含まれています。
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 Supplement2[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 "のための別名であり、遅れている互換性だけのためにここに含まれています。 Callエージェントが新しい実現に接続の上でリング後部への「rbk(connectionID)」の代わりに" rt@connectionID "を使用するのは、お勧めです。 ringback信号は接続のときに適用されますが、"rbk"信号は"@connection"構文をサポートしません。 信号が要求されているとき、それは、[1]で指定されるように接続IDと共にparameterizedされていて接続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.
Ringbackは(rt)に調子を変えさせます: ITU-T E.180[8]とITU-T E.182[10]を参照してください。 また、鳴ると呼ばれて、調子を変えてください--接続が作られていて、呼ぶ信号が被呼者かサービスポイントに適用されていると訪問者に忠告するトーン。 北アメリカでは、このトーンは、-16dBmの結合したレベルを与えるためには440と480Hertzの頻度とそれぞれ-19dBmのレベルがある2つの交流トーンの組み合わせです。
Foster & Andreasen Informational [Page 9] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[9ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
Audible Ring利根へのリズムは4秒までにオンで、続いているオフさ2秒です。 GR506コア[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 "を使用することでこの信号を適用できます。 ringback信号を終点に適用するとき、終点がフックであると考えられるなら試みる誤りとプレーringbackが調子を変えると考えて、そのような試みをするとき(エラーコード402--オンフックに電話をしてください)、その結果、誤りを返さなければなりません。 ringback信号が接続に適用されるとき、どんなそのようなチェックも作られていないことです。
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]、接続のときに要求された信号で指定されるそれをプレーしなければならないことに注意してください。 例えば、キャッチホン状況で、ringbackトーンは「不活発な」モードにおける接続のときにプレーされるかもしれません。
Foster & Andreasen Informational [Page 10] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[10ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
2.2. DTMF package
2.2. DTMFパッケージ
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 | | |
--------------------------------------------------------------
-------------------------------------------------------------- | シンボル| 定義| R| S持続時間| |--------------------------------------------------------------| | 0 | DTMF0| x| Br| | 1 | DTMF1| x| Br| | 2 | DTMF2| x| Br| | 3 | DTMF3| x| Br| | 4 | DTMF4| x| Br| | 5 | DTMF5| x| Br| | 6 | DTMF6| x| Br| | 7 | DTMF7| x| Br| | 8 | DTMF8| x| Br| | 9 | DTMF9| 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トーン持続時間| x| 3秒のTO| | ()。 | DTMF OO信号| | OO| | L| 長い持続時間インディケータ| x| | | oc| 操作完全です。| x| | | of| 操作失敗| x| | | T| 趾間部タイマ| x| 16秒のTO| | X| DTMFはワイルドカードに調子を変えさせます。| x| | | | あらゆるケタ0-9を合わせてください。| | | --------------------------------------------------------------
Changes from the previous version of the package: events "dd", "do", "oc" were added.
パッケージの旧バージョンからの変化: イベント"dd"、「してください」、"oc"は加えられました。
Note that DTMF tones including the DTMF tones wildcard can use the eventRange notation defined in [1] when requesting events, e.g., "D/[0-9](N)".
DTMFトーンワイルドカードを含むDTMFトーンが出来事、例えば、「D/[0-9](N)」を要求するとき[1]で定義されたeventRange記法を使用できることに注意してください。
Note that default time-out values may be over-ridden by the Call Agent for any Time-Out signal defined in this package by a "to" signal parameter. Refer to section 2 of this document, as well as [1] for details.
デフォルトタイムアウト値が“to"信号パラメタによってこのパッケージで定義されたどんな外のTime信号のためにもCallエージェントによってくつがえされるかもしれないことに注意してください。 このドキュメントのセクション2、および詳細のための[1]を参照してください。
Foster & Andreasen Informational [Page 11] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[11ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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--オンフックに電話をしてください)その結果、誤りを返さなければならないことに注意してください。 ケタ地図でイベントコードを指定できます。 セクション15、50msの最小のトーン持続時間は45msの最小の趾間部沈黙の期間までに続かれるでしょう、GR-506-CORE[7]に従って信号として要求されていてすなわち、信号リストで要求されるならいつのように「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トーンの検出、そして/または、世代を許容するかもしれないことに注意してください。 しかしながら、これはCallエージェントと発表サーバの間の一貫した食糧を供給することを必要とします(それは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は<時間>、<TrueOrFalse su=>と等しいように<トーン>と等しい))に調子を変えさせます: 指定された<トーン>であるときに、/で持続時間が>値が示した(そして、持続時間がいったん超えられていると、報告されます)<時間より長くなるかどうかを示すのにこの出来事を使用できます。 順不同にパラメタを提供できます。 DTMFトーンシンボル(パッケージ名を含んでいることのない)のどれかがDTMFパッケージの中に指定されていたなら(信号ではなく、出来事に関するケースにXを含んでいて)、<トーン>の値はそうすることができます。 このパラメタが欠けると、起こるどんなDTMFトーンも報告されるでしょう。 パラメタ<時間>はミリセカンドであって、ゲートウェイによって最も近い10msに一周されるかもしれません。 出来事が信号を要求する40原稿Whenであるよう要求するとき要求できる<時間>の最小値、要求できる<時間>の最小値は50原稿です。60000原稿Ifが出来事として要求されるとパラメタが欠けている「=<時間>」であるという出来事か信号のどちらかのために要求できる<時間>の最大値、トーンが完成するとき、出来事はトーンの完全な持続時間(最大60000ms)を報告するでしょう。 ObservedEventとして報告すると、いつも両方のパラメタを提供します。 この場合、<トーン>は検出された実際のトーンです、そして、<時間>はどちらかです:
* The <time> specified in the request (possibly rounded), or
* または<時間>が要求(ことによると、一周する)で指定した。
* If the request did not contain a "to=<time>" parameter, the
full duration of the tone.
* 要求が「=<時間>」パラメタを含まなかったなら、トーンについて継続します完全な。
The parameter "su" MAY be included when this is requested as an
event (but is not reported). This parameter is used to indicate
whether or not the DTMF digits requested should be suppressed
これが出来事(しかし、報告されない)として要求されているとき、パラメタ"su"は含まれるかもしれません。 このパラメタは、ケタが要求したDTMFが抑圧されるべきであるかどうかを示すのに使用されます。
Foster & Andreasen Informational [Page 12] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[12ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
それが要求されると、バンドです。 可能な値は「本当です」、DTMFが、通過され続けているはずであるのを示しながら、バンドにおけるDTMFがバンドで抑圧されて「誤るべきであること」を示して。 消えるなら、パラメタのデフォルト値は「誤っています」。 信号として「D/dd」を要求するとき、"su"パラメタを含んではいけません。
When used as a signal, "dd" provides the ability to generate a
DTMF tone as a TO signal. When applied as a signal, an additional
50 ms of silence will be tacked onto the end before the operation
complete occurs, i.e., "S: dd(dg=5,to=2500)" will play the DTMF
tone for the number "5" for 2.5 seconds, followed by 50 ms of
silence period. The operation complete (if requested) will be
notified after the silence interval occurs. Any value from 50 ms
to 60000 ms can be requested. Gateways generating or detecting
the tone may round off the requested time to the nearest 10 ms.
信号として使用されると、"dd"はTO信号としてDTMFトーンを発生させる能力を提供します。 信号として適用されると、沈黙の追加50msが操作の前に終わりに完全な状態で鋲で留められる、すなわち、起こる、「S:」 「dd(=2500へのdg=5)」はDTMFトーンを数「沈黙の期間の50msによって続かれた2.5秒間の5インチ」プレーするでしょう。 沈黙間隔が生じた後に操作完全、そして、(要求される)は通知されるでしょう。 どんな50msから60000msまでの値も要求できます。 トーンを発生するか、または検出するゲートウェイは要求された時間で最も近い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)".
2秒より長い間うるさく求められたケタを検出するのに「長い持続時間」出来事に代わって"dd"出来事を使用できます。 例えば、ユーザが2秒より長い間長い「#」を押すかどうか検出するためにRequestedEvents線で要求をすることができた、「R:」 「d/dd(N)(dgは=2000への#、と等しいです)。」 結果として起こるObservedEvents線がそうであるだろう、「O:」 「d/dd(dgは=2000への#、と等しいです)。」
Suppose instead, that the RequestedEvents line contains
代わりにそれが線が含むRequestedEventsであると仮定してください。
R: d/[0-9*#],d/dd
R: d/[0-9 *#]、d/dd
Suppose the user then pushes the "#" for 2.5 seconds. In this
case, two events will be notified:
次に、ユーザが2.5秒間の「#」を押すと仮定してください。 この場合、2回の出来事が通知されるでしょう:
O: d/#
O: d/#
when the "#" key is first pressed, and
そして「#」キーが最初に押されるとき。
O: d/dd(dg=#,to=2500)
O: d/dd(=2500へのdg=#)
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
DTMF OOは合図します((<トーンdg=>、>の<)をします): この信号は、オンオフ信号としてDTMFトーンを発生させるのに使用されます。 すなわち、<トーン>パラメタがDTMFパッケージの中の特定のトーンのシンボルのどれかである、(「0インチ、「9インチ、「A」、「B」、「C」、「D」、「*」、または「#」)、」 >インディケータの<が「+」である、オンである、「-」、[1]に従って下に。 そうでなければ、>パラメタを提供しなければならない<トーン、538の復帰コード--「出来事/信号パラメタ誤り」を応答に提供するでしょう。 >パラメタの<がなくなるなら、デフォルトはいつものように信号をつける(すなわち、「+」はデフォルトです)ことです。 パラメタの注文は重要ではありません。
Foster & Andreasen Informational [Page 13] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[13ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
since "+" and "-" are reserved characters and are easily
distinguished from the <tone> parameter.
以来、「+」と「-」は、控え目なキャラクタであり、<トーン>パラメタと容易に区別されます。
Long Duration Indicator (l):
The "long duration indicator" is observed when a DTMF signal is
produced for a duration larger than two seconds. In this case,
the gateway will detect two successive events: first, when the
signal has been recognized, the DTMF signal, and then, 2 seconds
later, the long duration signal.
長い持続時間インディケータ(l): DTMF信号が2秒より大きい持続時間のために作り出されるとき、「長い持続時間インディケータ」は観測されます。 この場合、ゲートウェイは2つの連続した出来事を検出するでしょう: 信号が認識されていて、DTMF信号であって、次に、2秒より遅れているときの最初に、長い持続時間信号。
Operation Complete (oc):
This is the standard definition of operation complete [1].
操作の完全な(oc): これは操作完全な[1]の標準定義です。
Operation Failure (of):
This is the standard definition of operation failure [1].
操作失敗(of): これは操作失敗[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): 出来事として、または、タイムアウト(TO)信号としてタイマTを使用できます。 信号として、唯一の振舞いが[1]で定義されるように“TO"信号の正常な特性(すなわち、出来事が全くタイムアウトの前に起こらないと、操作の完全な出来事は発生する)です。
As an event, Timer T is a digit input timer that can be used in
two ways:
出来事として、Timer Tは2つの方法で使用できるケタ入力タイマです:
* When timer T is used with the accumulate according to digit
map action, the timer is not started until the first DTMF
tone is entered, and the timer is restarted after each new
DTMF tone is entered until either a digit map match or
mismatch occurs. In this case, timer T functions as an
inter-digit timer as illustrated by:
* タイマTがいつで使用されているか、ケタ地図動作に従って、蓄積してください、そして、最初のDTMFトーンが入れられるまで、タイマは始動されないで、ケタ地図マッチかミスマッチのどちらかが現れるまでそれぞれの新しいDTMFトーンが入れられた後にタイマは再開されます。 この場合、Tが趾間部タイマとして機能するタイマは以下で例証しました。
R: D/[0-9T](D)
R: D/[0-9T](D)
* When timer T is used without the "accumulate according to
digit map" action, the timer is started immediately and
simply cancelled (but not restarted) as soon as a DTMF tone
is entered. In this case, timer T can be used as an inter-
digit timer when overlap sending is used, as in:
* タイマTが「ケタ地図に従って、蓄積してください」動作なしで使用されるとき、DTMFトーンが入れられるとすぐに、タイマは、すぐに、始動されて、単に取り消されます(しかし、再開されません)。 オーバラップ発信がこの場合使用されているとき、以下のように相互ケタタイマとしてタイマTを使用できます。
R: D/[0-9](N), D/T(N)
R: D/[0-9](N)、D/T(N)
When used with the "accumulate according to digit map" action,
timer T takes on one of two values, T-partial or T-critical. When
at least one more symbol is required for the "current dial string"
to match any one of the patterns in the digit map, timer T takes
on the value T-partial, corresponding to partial dial timing. If
a timer is all that is required to produce a match, timer T takes
「ケタ地図に従って、蓄積してください」動作と共に使用されると、タイマTはT部分的であるかT重要な2つの値の1つを帯びます。 「現在のダイヤルストリング」がケタ地図のパターンのどれかに合うのに少なくとももうひとつのシンボルが必要であるときに、タイマTはT目がなくて、部分的なダイヤルタイミングに対応する値を呈します。 タイマがマッチを生産するのに必要であるすべてなら、タイマTは取ります。
Foster & Andreasen Informational [Page 14] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[14ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
on the value T-critical corresponding to critical dial timing.
When timer T is used without the "accumulate according to digit
map" action, timer T takes on the value T-critical. The default
value for T-partial is 16 seconds and the default value for
T-critical is 4 seconds. The provisioning process may alter both
of these. If timer T is not used, then inter-digit timing will
not be performed.
重要なダイヤルタイミングとのT値で批判的な対応。 タイマTが「ケタ地図に従って、蓄積してください」動作なしで使用されるとき、タイマTはT批判的に値を呈します。 デフォルト値、T部分的であるのが、16秒とデフォルト値である、T批判的であるのは、4秒です。 食糧を供給することの過程はこれらの両方を変更するかもしれません。 タイマTが使用されていないと、趾間部タイミングは実行されないでしょう。
The following examples illustrate this. Consider the digit map:
以下の例はこれを例証します。 ケタ地図を考えてください:
(xxxxxxx|x11T)
(xxxxxxx| x11T)
and assume that DTMF and the timer T is accumulated according to
digit map. At the first DTMF input, say "4", timer T is started
with a value of T-partial since at least one more symbol is
required. If "1" is then input, it leads to a restart of timer T
with a value of T-partial again. If "1" is now input again, we
have a current dial string of "411" and a timer is now all that is
required to produce a match. Hence timer T is now restarted with
value T-critical.
そして、ケタ地図によると、DTMFとタイマTが蓄積されると仮定してください。 最初のDTMF入力のときに、「4インチ、少なくとももうひとつのシンボルが必要であるので、タイマTはT部分的の値から始動されます。」と言ってください。 「次に、1インチは入力されて、再びT部分的の値でタイマTの再開に通じます。」 「1インチは現在再び入力されます、そして、私たちには、「411」の現在のダイヤルストリングがあります、そして、現在、タイマはマッチを生産するのに必要であるすべてです」なら。 したがって、値がT重要な状態でタイマTは現在、再開されます。
Finally, consider the following subtle examples (all assuming DTMF
and timer T being accumulated according to digit map):
最終的に、↓これが微妙な例であると考えてください(ケタ地図によると、蓄積されながらDTMFとタイマTをすべて仮定して):
The digit map
ケタ地図
(1[2-3T].)
(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に通じる」入力。 その上、その後の入力、「2インチか「タイマTが完全に無関係であるので、何3インチも、似合いの二人はすぐに、引き起こされるでしょう」。
Foster & Andreasen Informational [Page 15] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[15ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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〜9DTMFケタにも調子を変えさせます。 しかしながら、コードが発生させた現実の出来事は検出されたケタのためにイベントコードになるでしょう。 DTMFトーンワイルドカードは、ケタ地図に対して合わせられるために入力されたDTMFを検出するのにしばしば使用されます。
2.3. Trunk Package
2.3. トランクパッケージ
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 |
----------------------------------------------------------------
---------------------------------------------------------------- | シンボル| 定義| R| S持続時間| |----------------------------------------------------------------| | as| 答え指揮| x| Br| | bl| ブロッキング| | Br| | bz| 忙しい| | 30秒まで | | co1| 連続トーン(調子を変えに行ってください。| x| 3秒まで | | | または、トーンを返してください。) | | | | co2| 連続テスト(調子を変えに行ってください。| x| 3秒まで | | | または、二元的なトーンにおけるトーンを返してください。| | | | | 手順) | | | | ct(…) | 連続トランスポンダー| | OO| | lb| ループバック| | OO| | nm| 新しいミリワットトーン| x| 3秒まで| | mm| 最も新しいミリワットトーン| x| 3秒まで| | oc| 操作完全です。| x| | | of| 操作失敗| x| | | om| 古いミリワットトーン| x| 3秒まで| | pst| 永久的な信号トーン| | TO無限| | qt| 落ち着いた終了| | TO無限| | ro| 追加注文トーン| x| 30秒まで | | 座ってください(#)。| 特別な情報トーン| x| 2秒まで | | | | | (注意を見ます) | | Tl| 試運転用線路| x| TO無限| | tp(###)| テストパターン| x| 3秒まで| | zz| サーキットがありません。| x| 2秒まで| ----------------------------------------------------------------
New events added to this package from the previously unversioned package: "bz", "ct", "mm", "oc", "pst", "qt", "sit", and "tp".
新しい出来事は以前にunversionedされたパッケージからこのパッケージに加えました: "bz"、「ct」、「mm」、"oc"、"pst"、"qt"、「座ってください」、および"tp"。
Changes in event types: "co1", "co2", "nm", "om", "tl", "zz" signals changed from OO to TO; "as" and "bl" changed from OO to BR.
イベントタイプにおける変化: 「co1"、「co2"、「nm」、"om"「Tl」と"zz"信号は、OOからTOに変えました」。 "as"と"bl"はOOからBRに変化しました。
Foster & Andreasen Informational [Page 16] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[16ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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"信号パラメタによってこのパッケージで定義されたどんな外のTime信号のためにもCallエージェントによってくつがえされるかもしれないことに注意してください。 このドキュメントのセクション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パッケージ[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]を参照してください。 北アメリカでは、ステーションBusyは、-21dBmの結合したレベルを与えるためには480と620Hertzの頻度とそれぞれ-24dBmのレベルがある2つの交流トーンの組み合わせです。 0.5秒までに離れて続かれて、次に、繰り返すとき、駅のBusy利根へのリズムは0.5秒です。 GR506コア[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): セクション3.1を見てください。2010Hzのトーン、(.1 .3 [2])について。 または、または、信号として発生すると、+の中にトーンの頻度があるに違いない、--、+の中に8Hz、出来事に対応するトーンの頻度がそうしなければならない間、いてください--30Hz。
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): セクション3.1を見てください。1780Hzのトーン、(.1 .3 [2])について。 または、または、信号として発生すると、+の中にトーンの頻度があるに違いない、--、+の中に20Hz、出来事に対応するトーンの頻度がそうしなければならない間、いてください--30Hz。
In continuity testing the tone corresponding to the signal at the
originating gateway is referred to as the "go" tone, and the tone
連続テストで、由来しているゲートウェイの信号に対応するトーンは「行ってください」というトーン、およびトーンと呼ばれます。
Foster & Andreasen Informational [Page 17] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[17ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
corresponding to the event at that same gateway is referred to as
the "return" or "check" tone.
その同じゲートウェイの出来事に対応するのは「リターン」か「チェック」トーンと呼ばれます。
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.
Bellcore GR-317-CORE[2]仕様によってすなわち、リターントーンの通知の意味論がそれ以上と同じくらい良いITU-T Q.724[3]でトーンを定義するときトーンが連続テスト要件に従って行われる連続の世代と通知が受け取りましたが、テストに合格したという指示であることに注意してください。 詳細は以下のパラグラフに明らかにされます。
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:
Callエージェントが連続テストを開始したがっているとき、co1とco2によって表された連続トーンは使用されています。 2つのタイプのテスト、シングル・トーン、および二元的なトーンがあります。 二元的なトーンの場合では、どちらのトーンも送ることができました、そして、以下に示すようにトランクインタコネクト(4ワイヤか2ワイヤ)によって、正反対は受信されました:
Originating Terminating
============ ===========
由来している終わり============ ===========
4w -------------- 1780 Hz -----------> 2w
<------------- 2010 Hz ------------ (transponder)
4w-------------- 1780Hz----------->2w<。------------- 2010Hz------------ (トランスポンダー)
2w -------------- 2010 Hz -----------> 2w/4w
<------------- 1780 Hz ------------ (transponder)
2w-------------- 2010Hz----------->2w/4w<。------------- 1780Hz------------ (トランスポンダー)
4w -------------- 2010 Hz -----------> 4w
<------------- 2010 Hz ------------ (loopback)
4w-------------- 2010Hz----------->4w<。------------- 2010Hz------------ (ループバック)
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:
Callエージェントが、どのテストが与えられた終点に適用されるべきであるかを情報に食糧を供給することで知っていると予想されます。 例として、2結線への4ワイヤに関して、Callエージェントは由来しているゲートウェイへの以下のように要求を送るかもしれません:
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
S: t/co1
R: t/co2,t/oc,t/of
RQNT1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: t/co1R: t/co2、t/oc、t/
On a terminating side of a trunk, the call agent may request a
continuity test connection (connection mode "conttest") to the
terminating gateway as follows:
トランクの終わり側面では、呼び出しエージェントが連続テスト接続(接続モード「最もconttest」)を以下の終わりゲートウェイに要求するかもしれません:
CRCX 3001 ds/ds1-2/4@tgw34.example.net
C: 3748ABC364
M: conttest
CRCX3001 ds/ds1-2/4@tgw34.example.net C: 3748ABC364M: 最もconttestである
Foster & Andreasen Informational [Page 18] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[18ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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,+)
RQNT3001 ds/ds1-2/4@tgw34.example.net X: 1233472秒間: t/ct(=co2、+からのコネ=co1)
The originating gateway would send the requested "go" tone, and
would look for the appropriate "return tone". Once the return
tone is received, the originating gateway removes the go tone and
checks to see that the return tone has been removed within the
specified performance limits (i.e., GR-246-CORE, T1.113.4, Annex B
[23]). When it detects that the test is successful, the gateway
will send a notification of the return tone event (Note that
notification of the return tone event therefore must not be sent
prior to detection of the removal of the return tone).
由来しているゲートウェイは、要求されていることでの「行ってください」というトーンを送って、適切な「リターントーン」を探すでしょう。 由来しているゲートウェイは、碁のトーンを取り除いて、リターントーンがいったん受け取られているようになると、指定された性能限界の中でリターントーンを取り除いてあるのを確実にするためにチェックします。(すなわち、GR-246-CORE、T1.113.4(Annex 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"信号が信号回のアウトであるときに、操作の完全な出来事が起こるように、あります」。 デフォルト以外のタイムアウト値が望まれているなら、“to"パラメタは使用されるかもしれません(例えば、「S: T/co1(=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.
ゲートウェイがタイムアウトの前に連続テストの失敗を検出すると、操作失敗出来事は発生するでしょう。 さもなければ、タイムアウトが起こる前にリターントーン出来事を受けないこと(操作の完全な出来事)で連続テストの失敗は決定します。 一般に、操作が完成する信号と操作がTOと共に失敗するとき、出来事は信号の名前でparameterizedされます。
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/co1)のt/」)の前に失敗を示します。
* 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
トランクの終わり端では、「ループバック」接続(シングル・トーンテスト)か「最もconttestな」接続(二元的なトーンテスト)のどちらかが作られています(あるいはまた「T/lb」か「T/ct」信号は要求されています)。 碁のトーンが見えなくなるとすぐに、リターントーンが取り除かれるのを確実にするのが終了終わりまで達しています。 The
Foster & Andreasen Informational [Page 19] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[19ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
Call Agent requests the removal of "contest" or "loopback"
connections (or "T/lb" or "T/ct" signals) at a termination end
when the results of the continuity test are obtained.
連続テストの結果が得られる終了終わりに「コンテスト」か「ループバック」接続(または、「T/lb」か「T/ct」信号)の解任にエージェント要求に電話をしてください。
When "conttest" is used, the endpoint is provisioned as to which
transponder test is being performed (2010 Hz received and 1780 Hz
sent or vice versa). In the case of the corresponding "T/ct"
signal, the Call Agent can specify which tone is received and sent
as parameters.
「最もconttestに」使用されると、どのトランスポンダーテストが実行されるかに関して終点は食糧を供給されます(2010Hzが受信されました、そして、1780Hzは発信したか、逆もまた同様です)。 対応する「T/ct」信号のケースでは、Callエージェントは、どのトーンがパラメタとして受け取られて、送られるかを指定できます。
Note that continuity tones in the trunk package are only ever sent
to the telephony endpoint. For network-based continuity, there
are continuity tones available in the RTP ("R") package. Although
a transponder (dual tone) test can be done, a single tone test is
generally sufficient in the case of continuity testing across an
IP network.
トランクパッケージの中の連続トーンが今までに電話終点に送られるだけであることに注意してください。 ネットワークベースの連続のために、RTP(「R」)パッケージの中に利用可能な連続トーンがあります。 トランスポンダー(二元的なトーン)テストができますが、一般に、シングル・トーンテストは連続がIPネットワークの向こう側にテストされる場合に十分です。
Continuity Transponder(ct(in=<tone-in>,out=<tone-out>, <+ or ->)):
This signal is used to provide transponder functionality
independent of the connection mode, i.e., this is an alternative
way to provide the same functionality as the "conttest" connection
mode. The parameters can be provided in any order. The <tone-in>
and <tone-out> parameters can have values "co1" or "co2",
corresponding to the 2010 Hz and 1780 Hz tones associated with
those symbols. If one of the tones is "co1", then the other must
be "co2" and vice versa (i.e., <tone-in> and <tone-out> must have
different values; if loopback is required, then the "lb" signal in
this package or "loopback" connection mode should be used).
連続トランスポンダー(ct(中で=<調子を変える>では、アウトが外で<調子を変える>と等しく、<は+か->です)): この信号は接続モードの如何にかかわらずトランスポンダーの機能性を提供するのに使用されます、すなわち、これが「最もconttestな」接続モードと同じ機能性を提供する代替の方法です。 順不同にパラメタを提供できます。 <中で調子を変える>と<外で調子を変える>パラメタが値を持つことができる、「co1"か「co2"、2010Hzと1780Hzのトーンとの対応はそれらのシンボルと交際しました」。 トーンの1つがそうである、「co1"、次に、もう片方がそうであるに違いない、「co2"、逆もまた同様です(すなわち、中で<調子を変える>、外で<調子を変える>には、異価がなければなりません; ループバックが必要であるなら、このパッケージか「ループバック」接続モードによる「lb」信号は使用されるべきである)、」
On detecting <tone-in>, <tone-out> will be generated in return.
The tone corresponding to <tone-out> will continue to be generated
until either:
中で<調子を変える>を検出すると、外で<調子を変える>は代わりに発生するでしょう。 外で<調子を変える>に対応するトーンは、どちらかまで発生し続けるでしょう:
* The signal is explicitly turned off (e.g., "S: t/ct(-)") or
* または信号が明らかにオフにされる、(例えば、「S: t/ct(-)」)。
* Removal of the <tone-in> tone is detected.
* <中で調子を変える>トーンの取り外しは検出されます。
Note that while the signal is active (regardless of whether a tone
is active or not), media from the endpoint will not be forwarded
to or from the packet network (i.e., the continuity transponder
signal must be explicitly turned off by the Call Agent in order to
resume passing media between the packet network and the endpoint).
信号が活性である間(トーンがアクティブであるかどうかにかかわらず)終点からのメディアがパケット網かパケット網から転送されないことに注意してください(Callエージェントはパケット網と終点の間にメディアを向かわせるのを再開するために明らかにすなわち、連続トランスポンダー信号をオフにしなければなりません)。
Loopback (lb):
This signal is used to provide loopback functionality independent
of the connection mode, i.e., this is an alternative way to
provide the same functionality as "loopback" connection mode.
ループバック(lb): この信号は接続モードの如何にかかわらずループバックの機能性を提供するのに使用されます、すなわち、これが「ループバック」接続モードと同じ機能性を提供する代替の方法です。
Foster & Andreasen Informational [Page 20] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[20ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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).
ループバック信号が活性である間(トーンがアクティブであるかどうかにかかわらず)終点からのメディアがパケット網かパケット網から転送されないことに注意してください(Callエージェントはパケット網と終点の間にメディアを向かわせるのを再開するために明らかにすなわち、ループバック信号をオフにしなければなりません)。
New Milliwatt Tone (nm):
1004 Hz tone - refer to [4] and section 8.2.5 of [5].
新しいミリワットトーン(nm): 1004Hz、調子を変えてください--[5]について[4]とセクション8.2.5を参照してください。
Newest Milliwatt Tone (mm):
1013.8 Hz - refer to [4].
最も新しいミリワットトーン(mm): 1013.8Hz--[4]を参照してください。
Operation Complete (oc):
This is the standard definition of operation complete [1].
操作の完全な(oc): これは操作完全な[1]の標準定義です。
Operation Failure (of):
This is the standard definition of operation failure [1].
操作失敗(of): これは操作失敗[1]の標準定義です。
Old Milliwatt Tone (om):
1000 Hz tone - refer to [4] and section 8.2.5 of [5].
古いミリワットトーン(om): 1000Hz、調子を変えてください--[5]について[4]とセクション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)を落ち着けてください: 静かなTerminationは102トランクテストで使用されます。 参照部6.20 .5 [4]と同様に[5]。
Reorder Tone(ro):
This maps to congestion tone in the ITU-T E.182 specification. In
North America, reorder tone is a combination of two AC tones with
frequencies of 480 and 620 Hertz and levels of -24 dBm each, to
give a combined level of -21 dBm. The cadence for reorder tone is
0.25 seconds on, followed by 0.25 seconds off, repeating
continuously (until time-out). See GR-506-CORE [7], Section
17.2.7.
追加注文トーン(ro): 混雑へのこの地図はITU-T E.182仕様で色調を変えます。 北アメリカでは、追加注文トーンは、-21dBmの結合したレベルを与えるためには480と620Hertzの頻度とそれぞれ-24dBmのレベルがある2つの交流トーンの組み合わせです。 0.25秒までに離れて続かれて、絶え間なさ(タイムアウトまで)に繰り返すとき、追加注文トーンのためのリズムは0.25秒です。 GR506コア[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].
特別な情報トーン(座っています(#)): ITU-T E.180[8]で説明されるように、特別な情報トーンは3つのトーンが1秒(およそ2秒の総TOの期間)の沈黙期までに続かれた状態で作り出されるトーンの期間から成ります。 信号として使用されると、1〜7までのパラメタ値でそれをparameterizedしなければなりません、[5]についてSR-2275、セクション6.21.2で定義される以下の意味で。
Foster & Andreasen Informational [Page 21] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[21ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
-------------------------------------------
| 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 |
-------------------------------------------
------------------------------------------- | 座っている、(1)| 'RO'| 追加注文SIT、イントラ-LATA| | 座っている、(2)| "RO"| 追加注文SIT、相互LATA| | 座っている、(3)| 'NC'| サーキットがないSIT、イントラ-LATA| | 座っている、(4)| 「NC」| サーキットがないSIT、相互LATA| | 座っている、(5)| IC| SITを妨害してください。| | 座っている、(6)| VC| 空のコードSIT| | 座っている、(7)| イーオー| 他の効果がない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までの10進数で出来事をparameterizedして、ゲートウェイがどのトーンを検出しなければならないかを示さなければなりません。 また、結果として起こる通知はパラメタを含んでいます。 他国には、国の特定の定義がある1つ以上の特別な情報トーンがあるかもしれません。(ITU-T E.180 suppを参照してください。 2 [9]). この場合特別な情報トーン1、定義されたコネ[9]が座ることであるので、(1)、特別な情報トーン2が座ることである、(2)など
As an example, the Call Agent might make a request such as:
例として、Callエージェントは以下などの要求をするかもしれません。
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
R: t/sit(N)(2)
RQNT1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0R: t/が座っている、(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)
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: AB123FE0O: t/は座っています。(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テスト線テスト進歩トーン、(2225Hz+、--、-10dBm0の25Hz) [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(###)信号は##絶え間なくパターン#をチャンネルに挿入します。 10進数として0〜255までパラメタを提供します。 パラメタが省略されるなら、デフォルト値は10進95です。
In RequestedEvents, the parameter MAY be supplied to indicate what
pattern the Call Agent wishes the gateway to detect. If the
parameter is omitted, the value 95 is assumed. The pattern MUST
be returned in the ObservedEvent (even if the parameter was not
requested).
RequestedEventsでは、Callエージェントがどんなパターンをゲートウェイを検出したがっているかを示すためにパラメタを提供するかもしれません。 パラメタが省略されるなら、値95は想定されます。 ObservedEventでパターンを返さなければなりません(パラメタが要求されなかったとしても)。
Foster & Andreasen Informational [Page 22] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[22ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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を参照してください。 デジタルループバックをするだろう「ループバック」モードにおける接続のトランクの終了側面を、Callエージェントは要求するでしょう。 トランクの創作側面では、Callエージェントは、テストパターンがデジタル・チャンネルに注がれるよう要求して、パターンがタイムアウト時間中に返されたのを確実にするためにチェックするでしょう。 例として、Callエージェントは創作側で以下の要求をするでしょう:
RQNT 1234 ds/ds1-1/17@tgw2.example.net
X: AB123FE0
S: t/tp
R: t/tp, t/oc, t/of
RQNT1234 ds/ds1-1/17@tgw2.example.net X: AB123FE0 S: t/tp R: t/tpであって、t/ocなt/
In this case the Call Agent will either receive:
この場合、Callエージェントは受信するでしょう:
* An ObservedEvent indicating that the test has passed (i.e.,
"O:t/op(95)") or
* またはテストに合格したのを示すObservedEvent(すなわち、「O: t/オプアート(95)」)。
* An ObservedEvent indicating that the timeout occurred before
the pattern was received (i.e., "O:t/oc(t/tp)"), indicating
that the test failed. Of course an operation failure would
indicate failure as well.
* テストが失敗したのを示して、タイムアウトがパターンの前に起こったのを示すObservedEventを受け取りました(すなわち、「O: t/oc(t/tp)」)。 もちろん、操作失敗はまた、失敗を示すでしょう。
No Circuit (zz):
This is an alias for Special Information Tone 2, i.e., "sit(2)".
サーキットがありません(zz): すなわち、これがSpecial情報利根2への別名である、「座っている、(2)、」
Foster & Andreasen Informational [Page 23] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[23ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
2.4. Line Package
2.4. 線パッケージ
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 |
----------------------------------------------------------------
---------------------------------------------------------------- |シンボル| 定義| R| S持続時間| |----------------------------------------------------------------| |adsi(ストリング)| ADSI表示| | Br| |aw| 答えトーン| x| OO| |bz| 話中音| | 30秒まで | |ci(ti、ν、Na)| 訪問者イド| | Br| |dl| ダイヤルトーン| | 16秒まで | |e| 誤りトーン| x| 2秒まで | |hd| オフフック変遷| S| | |hf| フラッシュフック| x| | |ht| 保持トーンに関して| | OO| |hu| フックにおける変遷| S| | |lsa| サイド答え一口を裏打ちしてください。 | | OO| |mwi| メッセージWaiting ind。 | | 16秒まで | |nbz| ネットワーク忙しいです。| x| TO無限| |oc| 操作完全です。| x| | |of| 操作失敗| x| | |osi| ネットワーク分離| | TO900ms| |ot| オフフック警告トーン| | TO無限| |p| 迅速なトーン| x| Br| |rg| 鳴ります。| | 180秒まで | |r0、r1、r2| 特有の鳴ること| | 180秒まで | |r3、r4、r5| | | | |r6かr7| | | | |ro| 追加注文トーン| | 30秒まで | |rs| Ringsplash| | Br| |s(###)| 特有のトーンパターン| x| Br| |座ってください(#)。| 特別な情報トーン| | 2秒まで | | | | | (注意を見ます) | |sl| どもりダイヤルトーン| | 16秒まで | |v| トーンを警告します。| | OO| |vmwi| 視覚メッセージ| | OO| | | 準備中表示| | | |wt| キャッチホントーン| | 12秒まで| |wt1、wt2| 代替の呼び出し| | 12秒まで| |wt3、wt4| 待ちトーン| | (注意を見ます) | |y| レコーダー警告トーン| | TO無限| |z| テレホンカードサービストーン| | Br| ----------------------------------------------------------------
New events added to this package from the previously unversioned package: "ht", "osi", and "lsa".
新しい出来事は以前にunversionedされたパッケージからこのパッケージに加えました: "ht"、"osi"、および"lsa"。
Foster & Andreasen Informational [Page 24] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[24ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
イベントタイプにおける変化: 「z」という信号「y」はそれぞれTOと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"信号パラメタによってこのパッケージで定義されたどんな外のTime信号のためにもCallエージェントによってくつがえされるかもしれないことに注意してください。 このドキュメントのセクション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]を参照してください。 北アメリカでは、ステーションBusyは、-21dBmの結合したレベルを与えるためには480と620Hertzの頻度とそれぞれ-24dBmのレベルがある2つの交流トーンの組み合わせです。 繰り返して、駅のBusy利根へのリズムは0.5秒までに以下でオフさ0.5秒です。 GR506コア[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:
訪問者イド(ci(時間、数、名前)): GR30コアのGR-1188[24]、[14]、およびGR-31[25]を見てください。 遅れている互換性に、それぞれの3つの分野が任意ですが、それぞれのコンマはいつも含まれるでしょう。 一般的なMGCP文法によると、それはいつもすべての3つの分野を含むRECOMMENDEDです--次に、パラメタを省略することの代わりに空の引用文字列を使用できます:
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」(01と12の間の1カ月mmが2ケタデシマル値である、DDは01〜31日目、時間、および1分間2ケタ価値である)が軍事の現地時間に従ってコード化された2ケタの値であり、例えば、00が真夜中であり、01が午前1時であり、13が午後1時ので、コード化されます。(いつも注意: 2ケタをそれぞれの月の値に提供しなければなりません、デー、時間、分間、例えば1月が2ケタによって示される、「まさしくよりむしろ1インチ、「1インチ)、」
Foster & Andreasen Informational [Page 25] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[25ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
数のパラメタは呼ぶ行番号を特定する10進数字のASCII文字列としてコード化されます。 ストリングが引用されるなら、余白は受入れられますが、それらは無視されるでしょう。 引用文字列を提供するなら、ストリング自体は信号パラメタのためにいつものようにコード化された(RFC2279)UTF-8です。
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(RFC2279)です。
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:
以下の例は訪問者イド信号の使用を例証します:
S: l/ci(09/14/17/26, "555 1212", "John Doe")
S: l/ci(09/14/17/26、「1212、インチ555「ジョン・ドウ」)
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]仕様を参照してください。 北アメリカでは、ダイヤルトーンは、-10dBmの結合したレベルを与えるためにはそれぞれ-13dBmの440の350の頻度、Hertz、およびレベルがある2つの連続した交流トーンの組み合わせです。 GR506コア[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): GR506コア[7]、セクション12を見てください。 オフフックである電話でオフフックを要求してみるために誤りであるとそれを考えます、そして、そのような試みをするとき(エラーコード401--オフフックに電話をしてください)、その結果、誤りを返さなければなりません。
Foster & Andreasen Informational [Page 26] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[26ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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)をひらめかせてください: GR506コア[7]、セクション12を見てください。 試みる誤りと要求フラッシュがフックである電話を掛けると考えて、そのような試みをするとき(エラーコード402--オンフックに電話をしてください)、その結果、誤りを返さなければなりません。
Tone On Hold (ht):
A tone used to reassure a calling subscriber who has been placed
on "hold". Refer to ITU-T E.182 [10].
保持(ht)で、調子を変えてください: 「保持」に置かれた呼んでいる加入者を再保証するのに使用されるトーン。 ITU-T E.182[10]を参照してください。
On-hook Transition (hu):
See GR-506-CORE [7], Section 12. The timing for the on-hook
signal is for flash response enabled, unless provisioned
otherwise. It is considered an error to try and request flash
hook on a phone that is on-hook and an error MUST consequently be
returned when such attempts are made (error code 402 - phone on-
hook).
フックにおける変遷(hu): GR506コア[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)を裏打ちしてください: これが線の上のReverse Loop Current Feed(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と440Hertz)として同じ頻度とレベルを使用しますが、0.1秒のリズムがオンな状態で使用するというメッセージWaitingインディケータ(オフさ0.1秒の、そして、繰り返された10回)は従いました。 GR506コア[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")のための別名です。 ネットワーク話中音を必要とする今後のCallエージェント実現は"ro"信号を使用するべきです。 また、Callエージェントが"nbz"出来事について通知されるよう要求しないその未来はそれに推薦されます(一般に、ネットワークの忙しいイベントは線パッケージの中に必要ではありません; したがって、"ro"は出来事ではなく、信号にすぎません)。
Operation Complete (oc):
This is the standard definition of operation complete [1].
操作の完全な(oc): これは操作完全な[1]の標準定義です。
Operation Failure (of):
This is the standard definition of operation failure [1].
操作失敗(of): これは操作失敗[1]の標準定義です。
Foster & Andreasen Informational [Page 27] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[27ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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)をネットワークでつないでください: ネットワークDisconnectは、遠端パーティーが連絡を断ったのを示します。 線に送られる信号は、国によって違うかもしれないので、メディアゲートウェイで食糧を供給されます。 GR-506-CORE[7]を参照してください、とSee GR-505-CORE[6]も見ます、セクション4.5。この信号が北アメリカでは、線に付けられるLoop Current FeedオープンSignal(LCFO)をもたらす開いているスイッチ間隔である、(.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): また、受信機Off-Hook利根(ROH利根)として知られているオフフック警告トーン。 それが正しく掛けられないとき、これは電話が出すいらだたしい雑音です。 北アメリカでは、ROH利根が1400Hertz、2060Hertz、2450Hertz、および2600Hertzの頻度で四声を結合することによって、発生します、次に、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)のトーンは400Hzのトーンの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): GR506コア[7]、セクション14を見てください。 食糧を供給することの過程は鳴るリズムを定義するかもしれません。 鳴る信号は適用するために鳴るサイクル(反復)の最大数を指定する「レップ」という信号パラメタでparameterizedされるかもしれません。 「レップ」のための値は、小数で指定されて、1〜255までどんな値も持つことができます。 以下は6鳴るサイクルまで鳴る信号を適用するでしょう:
S: l/rg(rep=6)
S: l/rg(レップ=6)
If the "rep" parameter is specified, the signal times-out when the
number of repetitions are completed (i.e., an operation complete
event can be requested and will occur at the end of the
timeout/number of rings).
「レップ」パラメタが指定されるなら、外で繰返し数が完成する(すなわち、操作の完全な出来事は、要求できて、リングのタイムアウト/数の終わりに起こるでしょう)信号時間です。
If the "rep" parameter is supplied, then any timeout ("to") value
that is included will be ignored, i.e.:
「レップ」パラメタを提供すると、すなわち、どんな含まれているタイムアウト(“to")値も無視するでしょう:
S: l/rg(rep=6,to=12000)
S: l/rg(=12000へのレップ=6)
Foster & Andreasen Informational [Page 28] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[28ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
will be treated the same as the previous example where the
parameter "to=12000" was not included. Of course, if the "to"
parameter is included without the "rep", it will be acted upon
i.e.:
同じように「=12000」というパラメタが含まれていなかった前の例として扱われるでしょう。 もちろん、“to"パラメタが「レップ」なしで含まれていると、それが作用される、すなわち:
S: l/rg(to=12000)
S: l/rg(=12000への)
will ring for 12 seconds.
12秒ベルを鳴らして呼ぶでしょう。
It is considered an error to try and ring a phone that is off-hook
and an error MUST consequently be returned when such attempts are
made (error code 401 - phone off-hook).
オフフックである電話を鳴らしてみるために誤りであるとそれを考えます、そして、そのような試みをするとき(エラーコード401--オフフックに電話をしてください)、その結果、誤りを返さなければなりません。
Distinctive Ringing (r0, r1, r2, r3, r4, r5, r6 or r7):
See GR-506-CORE [7], Section 14. Default values for r1 to r5 are
as defined for distinctive ringing pattern 1 to 5 in GR-506-CORE
[7]. The default values for r0, r6 and r7 are normal ringing
(i.e., the same cadence "rg"). The provisioning process may
define the ringing cadence for each of these signals. The
distinctive ringing signals may be parameterized with the signal
parameter "rep" which specifies the maximum number of ringing
cycles (repetitions) to apply. The value for "rep" is specified
in decimal and can have any value from 1 to 255.
特有のRinging(r0、r1、r2、r3、r4、r5、r6またはr7): GR506コア[7]、セクション14を見てください。 r5へのr1のためのデフォルト値が特有の鳴るパターンのためにGR-506-CORE[7]で1〜5に定義されるようにあります。 r0、r6、およびr7のためのデフォルト値は、(すなわち、同じリズム"rg")を鳴らしながら、正常です。 食糧を供給することの過程はそれぞれに関するこれらの信号のために鳴るリズムを定義するかもしれません。 特有の鳴る信号は適用するために鳴るサイクル(反復)の最大数を指定する「レップ」という信号パラメタでparameterizedされるかもしれません。 「レップ」のための値は、小数で指定されて、1〜255までどんな値も持つことができます。
The following will apply the ringing signal for up to 6 ringing
cycles:
以下は6鳴るサイクルまで鳴る信号を適用するでしょう:
S: l/r1(rep=6)
S: l/r1(レップ=6)
If the "rep" parameter is specified, the signal times-out when the
number of repetitions are completed (i.e., an operation complete
event can be requested and will occur at the end of the
timeout/number of rings)
繰返し数であるときに、「レップ」パラメタが指定されるなら、外の信号時間は完成します。(すなわち、操作の完全な出来事は、要求できて、リングのタイムアウト/数の終わりに起こるでしょう)
If the "rep" parameter is supplied, then any timeout ("to") value
that is included will be ignored, i.e.:
「レップ」パラメタを提供すると、すなわち、どんな含まれているタイムアウト(“to")値も無視するでしょう:
S: l/r1(rep=6,to=12000)
S: l/r1(=12000へのレップ=6)
will be treated the same as the previous example where the
parameter "to=12000" was not included. Of course, if the "to"
parameter is included without the "rep", it will be acted upon
i.e.:
同じように「=12000」というパラメタが含まれていなかった前の例として扱われるでしょう。 もちろん、“to"パラメタが「レップ」なしで含まれていると、それが作用される、すなわち:
S: l/r1(to=12000)
S: l/r1(=12000への)
will ring for 12 seconds.
12秒ベルを鳴らして呼ぶでしょう。
Foster & Andreasen Informational [Page 29] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[29ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
It is considered an error to try and ring a phone that is off-hook
and an error MUST consequently be returned when such attempts are
made (error code 401 - phone off-hook).
オフフックである電話を鳴らしてみるために誤りであるとそれを考えます、そして、そのような試みをするとき(エラーコード401--オフフックに電話をしてください)、その結果、誤りを返さなければなりません。
Reorder Tone (ro):
This maps to congestion tone in the ITU-T E.182 [10]
specification. In North America, reorder tone is a combination of
two AC tones with frequencies of 480 and 620 Hertz, and levels of
-24 dBm each, to give a combined level of -21 dBm. The cadence
for reorder tone is 0.25 seconds on, followed by 0.25 seconds off,
repeating continuously.
追加注文トーン(ro): 混雑へのこの地図はITU-T E.182[10]仕様で色調を変えます。 北アメリカでは、追加注文トーンは、-21dBmの結合したレベルを与えるためには480と620Hertzの頻度、およびそれぞれ-24dBmのレベルがある2つの交流トーンの組み合わせです。 0.25秒までに離れて続かれて、絶え間なく繰り返すとき、追加注文トーンのためのリズムは0.25秒です。
Ringsplash (rs):
Also known as "Reminder ring", this tone is a burst of ringing
that may be applied to the physical forwarding line (when idle) to
indicate that a call has been forwarded and to remind the user
that a Call Forward sub-feature is active. In the US, it is
defined to be a 0.5(-0,+0.1) second burst of power ringing (see
[11]).
Ringsplash(rs): また、「思い出させるものリング」として知られていて、このトーンは呼び出しが進められたのを示して、Call Forwardサブの特徴がアクティブであることをユーザに思い出させるために物理的な推進線(活動していないときに)に付けられるかもしれない鳴ることの炸裂です。 米国では、それが、パワーの鳴ることの0.5(-0、+0.1)の2番目の炸裂になるように定義されます。([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まで値を持っているかもしれないパラメタによって定義されたトーンパターンを合図するか、または検出するのに使用されます。 出来事として指定されると、パラメタを含まなければなりません。 また、出来事が報告されるとき、パラメタは含まれるでしょう。 この出来事(それぞれのパラメタ値に関連しているトーンの定義)は、相互運用性を保障するためにCallエージェントとゲートウェイの特別な食糧を供給することを必要とします。 この信号は、このパッケージの旧バージョンとの互換性を維持するためにここに含まれています。
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]:
特別な情報トーン(座っています(#)): ITU-T E.180[8]で説明されるように、特別な情報トーンは3つのトーンが1秒(およそ2秒の総TOの期間)の沈黙期までに生産され、続かれているトーンの期間から成ります。 それは1〜7までのパラメタ値でparameterizedされるかもしれません、SR-2275で定義される以下の意味で、セクション6.21.2[5]:
-------------------------------------------
| sit(1) | RO' | reorder SIT, intra-LATA |
| sit(2) | RO" | reorder SIT, inter-LATA |
| sit(3) | NC' | no circuit SIT, intra-LATA |
| sit(4) | NC" | no circuit SIT, inter-LATA |
| sit(5) | IC | intercept SIT |
| sit(6) | VC | vacant code SIT |
| sit(7) | IO | ineffective other SIT |
-------------------------------------------
------------------------------------------- | 座っている、(1)| 'RO'| 追加注文SIT、イントラ-LATA| | 座っている、(2)| "RO"| 追加注文SIT、相互LATA| | 座っている、(3)| 'NC'| サーキットがないSIT、イントラ-LATA| | 座っている、(4)| 「NC」| サーキットがないSIT、相互LATA| | 座っている、(5)| IC| SITを妨害してください。| | 座っている、(6)| VC| 空のコードSIT| | 座っている、(7)| イーオー| 他の効果がないSIT| -------------------------------------------
Foster & Andreasen Informational [Page 30] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[30ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
If the parameter is left out, the NC' SIT tone that corresponds to
the signal "L/sit(3)" is assumed.
'パラメタが左のアウト、NCであるなら'信号に対応するSITトーン、「L/が座っている、(3)、」 想定されます。
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.180 suppを参照してください。 2 [9]). この場合特別な情報トーン1、定義されたコネ[9]が座ることであるので、(1)、特別な情報トーン2が座ることである、(2)など
Stutter Dial Tone (sl):
Stutter Dial Tone (also called Recall Dial Tone in GR-506-CORE [7]
and "special dial tone" in ITU-T E.182 [10]) is used to confirm
some action and request additional input from the user. An
example application is to cancel call-waiting, prior to entering a
destination address.
ダイヤルトーン(sl)をどもらせてください: Dial利根をどもらせてください。(GR-506-CORE[7]のまた、呼ばれたRecall Dial利根と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:
どもりトーン・ダイヤル信号は信号パラメタ"del"でparameterizedされるかもしれません。(それは、確認トーンとダイヤルトーンの間で適用するためにミリセカンドの遅れを指定するでしょう)。 パラメタは100(すなわち、コンマ1秒)で分割可能な最も近い非ゼロ値に一周した0〜10000msからのどんな値も持つことができます。 以下の意志は確認トーンとダイヤルトーンの間の1.5秒の遅れでどもりダイヤルトーンを当てはまります:
S: l/sl(del=1500)
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)を警告します: 持続時間であって、10秒毎のトーンの1/2秒によってあとに続く2 2番目の440Hzの利根。 この出来事はパッケージの旧バージョンとの遅れている互換性のために含まれています。
Visual Message Waiting Indicator (vmwi):
The transmission of the VMWI messages will conform to the
requirements in [13] and the CPE guidelines in [12]. Refer also
to section 6.6 of GR-30-CORE [14]. VMWI messages will only be
sent from the gateway to the attached equipment when the line is
idle. If new messages arrive while the line is busy, the VMWI
indicator message will be delayed until the line goes back to the
idle state. After the gateway restarts, the state of the signal
will be "off", and hence the Call Agent MUST refresh the CPE's
visual indicator if it is supposed to be "on".
視覚通話待ち指示器(vmwi): VMWIメッセージの伝達は[13]の要件と[12]のCPEガイドラインに従うでしょう。 また、GR-30-CORE[14]のセクション6.6を参照してください。 線が使用されていないときにだけ、VMWIメッセージをゲートウェイから付属設備に送るでしょう。 回線が話し中である間、新しいメッセージが到着すると、線が活動していない状態に戻るまで、VMWIインディケータメッセージは遅れるでしょう。 ゲートウェイが再開した後に、信号の状態は“off"になるでしょう、そして、したがって、Callエージェントはそれが“on"であるべきであるならCPEの視覚インディケータをリフレッシュしなければなりません。
Foster & Andreasen Informational [Page 31] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[31ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
代替のCall Waiting Tones、(wt、wt1、wt4)、: ITU-T E.180[8]を参照してください。 北米のトーン定義について、GR-506-CORE[7]、セクション14.2を参照してください。 「wt」、および「wt1"は北アメリカの300プラスのために適用された440HzのトーンであるデフォルトCall Waitingトーンのための両方の別名であるかおよびマイナス50は10秒の次にトーンがかつてたびたびである原稿です」。
These signals are timeout signals with a default timeout value of
12 seconds, which allows the tone to be played twice with a single
request (refer to GR-571-CORE [16]). However, there are cases
(Requirement R3-73 of GR-575-CORE [18]), in which only a single
tone is required. In that case, the Call Agent may make the
request with a shorter timeout period to eliminate the second tone
(e.g., "S: wt(to=2000)" - which stops the signal after 2 seconds
so that the second tone will not occur).
これらの信号は12秒のデフォルトタイムアウト価値があるタイムアウト信号です、トーンが二度ただ一つの要求でプレーするもの。(GR-571-CORE[16])は言及します。 そこでは、唯一のシングル・トーンがそうです。ケースがあります。(GR-575-CORE[18])の要件R3-73が必要です。 その場合、Callエージェントは、2番目のトーン(例えば、「S: wt(=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]を参照してください--BellcoreドキュメントSR-2275[5]部分6.20も。 記録装置が使用されているとき、このトーンは会話が記録されていることを冷ややかなパーティーに知らせるために線に関連づけられます--使用される典型的な値は15秒あたりの2番目の持続時間に0.5の1400Hzの利根です。
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+1477Hz(DTMF#ケタ)の60msと350+440Hz(ダイヤルトーン)の940msから成ります、200の時定数でBellcoreドキュメントSR-2275[5](セクション6.20)に原稿Referを指数関数的に腐食して
Foster & Andreasen Informational [Page 32] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[32ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
2.5. Handset Emulation Package
2.5. 受話器エミュレーションパッケージ
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 |
----------------------------------------------------------------
---------------------------------------------------------------- |シンボル| 定義| R| S持続時間| |----------------------------------------------------------------| |adsi(ストリング)| ADSI表示| x| Br| |aw| 答えトーン| x| OO| |bz| 話中音| x| 30秒まで | |ci(ti、ν、Na)| 訪問者イド| x| Br| |dl| ダイヤルトーン| x| 16秒まで | |e| 誤りトーン| x| 2秒まで | |hd| オフフック変遷| S| Br| |hu| フックにおける変遷| S| Br| |hf| フラッシュフック| x| Br| |ht| 保持で、調子を変えてください。| x| OO| |lsa| サイド答え一口を裏打ちしてください。 | x| OO| |mwi| インディアナ州を待つメッセージ | x| 16秒まで | |nbz| ネットワーク忙しいです。| x| TO無限| |oc| 操作完全です。| x| | |ot| オフフック警告トーン| x| TO無限| |of| 操作失敗| x| | |osi| ネットワーク分離| x| TO900ms| |p| 迅速なトーン| x| Br| |rg| 鳴ります。| x| 180秒まで | |r0、r1、r2| 特有の鳴ること| x| 180秒まで | |r3、r4、r5| | | | |r6かr7| | | | |ro| 追加注文トーン| x| 30秒まで | |rs| Ringsplash| x| Br| |s(###)| 特有のトーンパターン| x| Br| |座ってください(#)。| 座っている、トーン| x| 2秒まで | |sl| どもりダイヤルトーン| x| 16秒まで | |v| トーンを警告します。| x| OO| |vmwi| フィス。 メッセージWaitingインディアナ州| x| OO| |wt| 呼び出しWaitingトーン| x| 12秒まで | |wt1、wt2| 代替の呼び出し| x| 12秒まで| |wt3、wt4| 待ちトーン| | (注意を見ます) | |y| レコーダー警告トーン| x| TO無限| |z| カードServと呼びます。 トーン| 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.
「オフフック」などの出来事に合図して、検出できるのを除いて、受話器エミュレーションパッケージは線パッケージと同様です。
Foster & Andreasen Informational [Page 33] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[33ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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: 出来事としてCallエージェントによって要求される場合、出来事はparameterizedされません。 しかしながら、出来事が報告されるとき、パラメタは含まれています。
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.:
訪問者イド: 出来事としてCallエージェントによって要求されると、出来事をparameterizedしてはいけません。 しかしながら、出来事が報告されるとき、パラメタが含まれている、すなわち:
O: l/ci(09/14/17/26,"555 1212","John Doe")
O: l/ci(09/14/17/26、「1212、インチ555「ジョン・ドウ」)
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.:
サイド答え指揮を裏打ちしてください: 出来事としてCallエージェントによって要求されると、それは、逆の輪の電流給電(RLCF)がいつ断続的にターンされたかを示します。 それが要求されているとき、出来事はparameterizedされません。 しかしながら、それが報告されるとき、パラメタが含まれている、すなわち:
O: l/lsa(+) to indicate RLCF was turned on
O: l/lsa(-) to indicate RLCF was turned off
O: RLCFを示すl/lsa(+)はOで回されました: RLCFがオフにされたのを示すl/lsa(-)
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): 出来事として要求されると、Callエージェントが任意に何らかの数のリングの後に報告するという要求を示すレップパラメタを入れるかもしれない、例えば:
RQNT 1234 aaln/1@rgw2.example.net
X: AB123FE0
R: h/rg(N)(rep=3)
RQNT1234 aaln/1@rgw2.example.net X: AB123FE0R: h/rg(N)(レップ=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)
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: AB123FE0O: h/rg(レップ=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.
また、パラメタが要求に含まれていないなら、それはレポートに含まれていません。 その場合、鳴ることが検出されるとすぐに、出来事は報告されます。
Foster & Andreasen Informational [Page 34] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[34ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
特有のRinging(r0、r1、r2、r3、r4、r5、r6またはr7): また、"rg"出来事のように、これらの1つが出来事として要求されているとき、「レップ」パラメタが含まれているなら、それは報告されます。 また、それがパラメタで要求されないなら、パラメタはレポートに含まれていません。 その場合、要求されたリズムを取り囲むのが検出されるとすぐに、出来事は報告されます。
Stutter Dial Tone (sl):
Stutter Dial Tone MUST not be parameterized when requested as an
event. However, the "del" parameter is reported.
ダイヤルトーン(sl)をどもらせてください: 出来事として要求されると、どもりDial利根をparameterizedしてはいけません。 しかしながら、"del"パラメタは報告されます。
RQNT 1234 aaln/1@rgw2.example.net
X: AB123FE0
R: h/sl
RQNT1234 aaln/1@rgw2.example.net X: AB123FE0R: 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)
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: AB123FE0O: 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.:
視覚メッセージの待ち: 出来事としてCallエージェントによって要求されると、それは、視覚通話待ち指示器がいつ断続的にターンされたかを示します。 それが要求されているとき、出来事はparameterizedされません。 しかしながら、それが報告されるとき、パラメタが含まれている、すなわち:
O: l/vmwi(+) to indicate message waiting turned on
O: l/vmwi(-) to indicate message waiting turned off
O: メッセージの待ちを示すl/vmwi(+)はOをつけました: メッセージの待ちが興味を失ったのを示すl/vmwi(-)
Note that:
以下のことに注意してください。
* All TO signals in the handset package can include a "to"
parameter when requested as a signal.
* 信号として要求されると、受話器パッケージの中のすべてのTO信号が“to"パラメタを含むことができます。
* However, requests to be notified about these events MUST NOT
include the "to" parameter, i.e., the "to" parameter is not
valid in RequestedEvents.
* しかしながら、これらの出来事に関して通知されるという要求は“to"パラメタを含んではいけません、すなわち、“to"パラメタがRequestedEventsで有効ではありません。
Foster & Andreasen Informational [Page 35] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[35ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
2.6. Supplementary Services Tone Package
2.6. 補っているサービスはパッケージに調子を変えさせます。
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 |
----------------------------------------------------------------
--------------------------------------------------------------- |シンボル| 定義| R| S持続時間| |---------------------------------------------------------------| |cd| コンファレンスは出発します。| | Br| |cj| コンファレンスは接合します。| | Br| |cm| 安らぎトーン| | TO無限| |cw| 訪問者待ちトーン| | 30秒まで | |ht| 保持トーンに関して| | OO| |Ni| 負の符号表示| | TO無限| |ν| 入手不可能な数| | TO無限| |oc| 操作完全です。| x| | |of| 操作失敗| x| | |pr| 公衆電話認識| | Br| |Pt| ペイトーン| | 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"信号パラメタによってこのパッケージで定義されたどんな外のTime信号のためにもCallエージェントによってくつがえされるかもしれないことに注意してください。 このドキュメントのセクション2、および詳細のための[1]を参照してください。
The events in this package are defined as follows:
このパッケージにおける出来事は以下の通り定義されます:
Conference Depart(cd):
Tone used to indicate that a participant has left a conference
call. The tone characteristics are left to the specific gateway
implementation.
コンファレンスは(cd)を去ります: トーンは、以前はよく関係者が電話会議を残したのを示していました。 トーンの特性は特定のゲートウェイ実現に残されます。
Conference Join (cj):
Tone used to indicate that a party has joined a conference call.
The tone characteristics are left to the specific gateway
implementation.
コンファレンスは(cj)を接合します: トーンは、以前はよくパーティーが電話会議に加わったのを示していました。 トーンの特性は特定のゲートウェイ実現に残されます。
Comfort Tone (cm):
Comfort Tone is used to indicate that the call is being processed
and that the caller should wait. Refer to ITU-T E.182 [10].
安らぎトーン(cm): Comfort利根は、呼び出しが処理されていて、訪問者が待つべきであるのを示すのに使用されます。 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]を参照してください。
Foster & Andreasen Informational [Page 36] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[36ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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).
数の入手不可能なトーン(ν): ITU-T E.180、補足2[9]を参照してください。 また、「空のトーン」と地図を参照されて、これは北アメリカの「再オーダー・トーン」へのこと(GR-506-CORE[7]、セクション17.2.7を見る)です。
Operation Complete (oc):
The standard definition of operation complete [1].
操作の完全な(oc): 操作完全な[1]の標準定義。
Operation Failure (of):
The standard definition of operation failure [1].
操作失敗(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].
トーン(Pt)を支払ってください: その支払いを示すトーンが必要です。 ITU-T E.182[10]を参照してください。
2.7. Digit Map Extension
2.7. ケタ地図拡大
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
このパッケージはケタ地図における与えられたエントリーのための可能な限り短いマッチの振舞いをくつがえすのに使用されるExtension Digit Map Letterを定義します。([1])を見てください。 ケタ地図エントリーの端のときに、現在のダイヤルストリングが別のエントリーに部分的に合っていないなら、文字「P」(部分的なマッチオーバーライドのための)は、そのエントリーがマッチであると単に考えるようゲートウェイに命令します。 例えばケタが写像する当然のこと
([3-7]11|123xxxxxxx|[1-7]xxxxxxP|8xxxP)
xxxxxxP| ([3-7] 11|123xxxxxxx|[1-7]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」の現在のダイヤルストリングはマッチであると考えられるでしょう。
Foster & Andreasen Informational [Page 37] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[37ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
このパッケージのサポートは強くそうです。RECOMMENDED。
2.8. Signal List Package
2.8. 信号リストパッケージ
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 |
---------------------------------------------------------
--------------------------------------------------------- | シンボル| 定義| R| S持続時間| |---------------------------------------------------------| | oc| 操作完全です。| x| | | of| 操作失敗| x| | | s(リスト)| 信号リスト| | TO変数| ---------------------------------------------------------
Operation Complete (oc):
This is the standard definition of operation complete from [1].
操作の完全な(oc): これは[1]から完全な操作の標準定義です。
Operation Failure (of):
This is the standard definition of operation failure from [1].
操作失敗(of): これは[1]からの操作失敗の標準定義です。
Signal List(s(<list>)):
The <list> contains a comma-separated list of signals to be played
out. Each of the signals in <list> MUST be either of type BR or
type TO. Semantically, the signal list is still treated as a
single parameterized signal of type Time-Out though. The signals
in the list are played to completion one after the other in the
left to right order specified. The package for each signal in the
list must be specified. For example, to play out the DTMF digits
123456:
リスト(s(<リスト>))に合図してください: <リスト>は使い果たされるべき信号のコンマで切り離されたリストを含んでいます。 タイプBRかタイプTOには<リスト>のそれぞれに関する信号があるに違いありません。 もっとも、意味的に、信号リストはまだ外のタイプTimeのただ一つのparameterized信号として扱われています。 リストの信号は指定された正しいオーダーへの左で次々と完成に使われます。 リストの各信号のためのパッケージを指定しなければなりません。 例えば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(出来事/信号パラメタ誤り)を返さなければなりません。
Foster & Andreasen Informational [Page 38] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[38ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
Note that as the gateway plays the ordered list of signals, if it
encounters a TO signal with an infinite timeout, it will continue
to play that signal until the Signal List signal is stopped (i.e.,
other signals later in the list will never be played).
無限のタイムアウトに伴うTO信号に遭遇すると、ゲートウェイが信号の規則正しいリストをプレーするときSignal List信号が止められるまで(すなわち、後でのリストの他の信号は決して使われないでしょう)その信号を使い続けることに注意してください。
If the operation complete ("oc") event is requested, it will be
detected once, when the last signal in the list has been played
out (regardless of whether there are any TO signals in the list).
The operation complete event will only report the signal list name
itself, i.e., without the parameters supplied as in:
操作の完全な("oc")出来事が要求されると、それは一度検出されるでしょう、リストにおける最後の信号が展開されたとき(リストにどんなTO信号もあることにかかわらず)。 操作の完全な出来事はすなわち、以下のように提供されたパラメタのない信号リスト名自体を報告するだけでしょう。
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.
信号の信号のどれかが誤りにおける結果を記載するなら、Signal List信号のための操作失敗出来事は発生しなければなりません。 信号リスト名だけが含まれるでしょう、その結果、信号リストの信号のどれが実際に失敗したかを決定するのは可能ではありません。
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に出来事が起こった時で上演されていたリストの信号があると、TO信号はすぐに止まるでしょう、そして、リストの他の信号は全く使われないでしょう。
2.9. Media Format Parameter Package
2.9. メディアはパラメタパッケージをフォーマットします。
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
このパッケージはメディア形式パラメタLocal Connection Option(LCO)のサポートを提供します。 メディア形式パラメタLCOはSDP[15]の"fmtp"属性と同様であり、対応するSDP fmtp属性が使用されるかもしれない同じメディア形式のすべてに適切です(すなわち、メディアはどんなメディア形式MIMEの種類のためのパラメタもフォーマットします)。 形式名(MIME「副-タイプ」専用)がスペースで従ったメディアで始まるコロンと引用文字列があとに続いたキーワードの"fmtp"か"o-fmtp"がパラメタがそのメディア形式に関連づけたメディア形式で続いて、メディア形式パラメタはコード化されます。 簡単さのために、私たちは用語「コーデック」と「メディア」を使用するつもりです。
Foster & Andreasen Informational [Page 39] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[39ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
format" interchangeably in the following. Multiple formats may be indicated by either repeating the "fmtp" local connection option multiple times, such as:
以下で互換性を持って「フォーマットします」。 複数の書式が、以下などの"fmtp"市内接続オプション倍数倍を繰り返すことによって、示されるかもしれません。
L:a:codec1;codec2, fmtp:"codec1 formatX", fmtp:"codec2 formatY"
L:a:codec1; fmtp: codec2、fmtp: "codec1 formatX"、"codec2 formatY"
or alternatively by having a single "fmtp" keyword followed by a colon, and a semi-colon separated list of quoted strings for each media format parameter, as in:
または、あるいはまた、コロン、およびそれぞれのための引用文字列のセミコロンの切り離されたリストにただ一つの"fmtp"キーワードのあとに続かせることによって、メディアはパラメタをフォーマットします、以下のように
L:a:codec1;codec2, fmtp:"codec1 formatX";"codec2 formatY"
L: : codec1; fmtp: codec2、"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"
L:a:codec1; fmtp: codec1、"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.:
しかしながら、コーデックの1番目か2番目の発生にfmtpパラメタがことであった適用されるかどうかは明確でないでしょう。すなわち、注文されるそのコーデックに関する問題が重要であり(すなわち、コーデックは都合のよいオーダーに記載されています)、上の構文が"formatX"が好まれるかどうかを示す方法を提供しない、(すなわち、1番目に関連する、「codec1"、)、(すなわち、2番目に関連する、「codec1")、」 "fmtp"書式の記号列のコーデック名が同じコーデックが複数の形式で要求されているとき、このジレンマを決議するためにコロンと<オーダー>によって従われている、すなわち:(そこでは、1〜Nまで<オーダー>がコーデックリストにおける、同じコーデックのN発生の数です)。
L:a:codec1;codec1, fmtp:"codec1:2 formatX"
L: ; fmtp: : codec1、codec1、「codec1: 2formatX」
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"が2番目の例に関連しているのを示す、「中のcodec1"、「a: codec1; codec1"リスト、」 --(例えば、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値が認識されないか、または支持されないなら、関連コーデックは「支持されていない」と考えられます。
Foster & Andreasen Informational [Page 40] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[40ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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: 電話出来事、fmtp:、「電話イベント0-15、3235インチ、」 …
A: a:PCMU;G729, fmtp:"PCMU foo";"PCMU bar", fmtp:"G729 foobar",...
A: : PCMU; fmtp: G729、"PCMU foo"; fmtp: 「PCMUバー」、"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つの例がメディア形式に関連した「電話出来事」というメディア形式パラメタLCOを使用します、RFC2833[33]で定義されるように。 メディア形式「電話出来事」が"fmtp"メディアなしで使用されるなら、パラメタをフォーマットしてください、DTMFケタ。(電話出来事0-15はRFC2833[33])から想定されます--、しかしながら、そのような習慣はがっかりしています。 他方では、メディアはパラメタLCO MAYをフォーマットします。使用されて、RFC2833[33]を通して要求されている正確なセットの出来事を指定してください。 例:
L: a:PCMU;telephone-event,fmtp:"telephone-event 16"
L: ; fmtp: : PCMU、電話出来事、「電話イベント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.
別の場合では、Callエージェントは、いくつかの形式パラメタが「必要であること」を示すかもしれませんが、他のものは任意です。 以下の例では、電話出来事0-15は“must"ですが、電話出来事16、70、および71は任意です。
L: a:PCMU;telephone-event, o-fmtp:"telephone-event 16,70,71",
fmtp:"telephone-event 0-15"
L: a: PCMU; o-fmtp: 電話出来事、「電話出来事16、70(71インチ)はfmtpする」という電話出来事、015インチ
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を支持しますSHOULDが、示す。
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:
終点の能力を監査するのを要求をして、終点が出来事に伴う「電話出来事」メディア形式を支持する、「016インチ、次に、監査は以下を含んでいるでしょう:、」
A: a:telephone-event, fmtp: "telephone-event 0-16"
A: a: 電話出来事、fmtp: 「電話出来事、016インチ、」
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:
別の例はRFC2198[32]がある冗長の使用です。 一方、fmtpストリングの形式は文字通りのストリング(この場合「赤い」)がペイロードタイプよりむしろ使用されるのを除いて、SDPで使用されるそれと同様です:
L: a:G729;pcmu;red,fmtp:"red pcmu/g729"
L: fmtp: : G729; pcmu; 赤、「赤のpcmu/g729」
Foster & Andreasen Informational [Page 41] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[41ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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
オーディオの12345RTP/AVP98 18 0m=a=rtpmap: 98赤/8000/1a=fmtp: 98、0/18
If we combine both telephone events and redundancy, an example local connection option might look as follows (carriage return added for formatting reasons here):
私たちが電話出来事と冗長の両方を結合するなら、例の市内接続オプションは以下の通りに見えるかもしれません(復帰はここの形式理由で加えました):
L: a:G729;pcmu;red;telephone-event,fmtp:"red pcmu/g729",
fmtp: "telephone-event 16"
L: ; pcmu; 赤; fmtp: : G729、電話出来事、「赤のpcmu/g729」fmtp: 「電話イベント16インチ」
Note that we again specify the literal string for the encoding method rather than its payload type. This is a general principle that should be used with this LocalConnectionOption.
私たちが再びペイロードタイプよりむしろコード化方法に文字通りのストリングを指定することに注意してください。 これはこのLocalConnectionOptionと共に使用されるべきである一般的な原則です。
The corresponding SDP might appear as follows:
対応するSDPは以下の通りに見えるかもしれません:
m=audio 12345 RTP/AVP 97 98 18 0
a=rtpmap:97 red/8000/1
a=fmtp:97 0/18
a=rtpmap:98 telephone event
a=fmtp:98 16
mがオーディオの12345RTP/AVPと等しい、97 98 18、0a=rtpmap、: 97赤/8000/1a=fmtp: 0/18a=rtpmap: 98がイベントa=fmtp: 98 16に電話をする97
Note that the fmtp LCO may be used in any situation where the corresponding SDP attribute may be used. An example of a local connection option that involves a media type other than audio and a "foobar" fmtp parameter:
fmtp LCOがどんな状況においても対応するSDP属性が使用されるかもしれないところで使用されるかもしれないことに注意してください。 オーディオ以外のメディアタイプと"foobar"fmtpパラメタにかかわる市内接続オプションに関する例:
L: a:image/tiff, fmtp:"tiff foobar"
L: fmtp: : イメージ/いさかい、「いさかい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.
これらの2LocalConnectionOptionsがIANAに登録されました。
Foster & Andreasen Informational [Page 42] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[42ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
2.10. RTP Package
2.10. RTPパッケージ
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 | |
-------------------------------------------------------------
------------------------------------------------------------- | シンボル| 定義| R| S持続時間| |-------------------------------------------------------------| | co1| 連続トーン(シングル| C| 3秒のC | | | または、トーンを返してください。) | | | | co2| 連続テスト(調子を変えに行ってください。| C| 3秒のC | | | 二元的なトーン手順で) | | | | iu、()。 | ICMP手が届きません。| C| | | | 受信します。| | | | ji、()。 | ジターバッファサイズは変化しました。| C| | | ma| メディアは始まります。| C| | | oc| 操作完全です。| x| | | of| 操作失敗| x| | | pl、()。 | 損失が超えていたパケット| C| | | qa| 上質の警戒| C| | | rto、()。 | RTP/RTCPタイムアウト| C| | | sr| 標本抽出率は変化しました。| C| | | uc| 中古のコーデックは変化しました。| 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".
新しい出来事は以前にunversionedされたパッケージからこのパッケージに加えました: "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"信号パラメタによってこのパッケージで定義されたどんな外のTime信号のためにもCallエージェントによってくつがえされるかもしれないことに注意してください。 このドキュメントのセクション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 」)を示します」。 出来事は、すべての既存の接続のためにconnectionIDに[1]で説明されるように「*」ワイルドカードを使用することで要求されているかもしれません。
Foster & Andreasen Informational [Page 43] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[43ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
Example:
例:
R: r/uc@* (request to detect uc on all connections) or
R: または r/uc@* (すべての接続にucを検出するという要求)。
R: r/uc@connectionID (request to detect uc only on a specific
connection)
R: r/uc@connectionID (特定の接続だけにucを検出するという要求)
An event detected on a connection will include the connectionID, e.g.:
接続に検出された出来事は例えばconnectionIDを含むでしょう:
O: r/uc@connectionID(15)
O: r/uc@connectionID (15)
Continuity tones (co1 and co2):
These are the same as the events defined in the Trunk package,
except in this case, they are only played over a network
connection and the connectionID MUST be supplied (e.g., "s:
r/co1@connectionID"). They can be used in conjunction with the
Network LoopBack (netwloop) or Network Continuity Test (netwtest)
modes to test the continuity of an RTP circuit. However, in the
case of testing IP continuity, a one-tone test is sufficient i.e.,
generating and detecting "co1" at one end, with connection mode in
network loopback mode at the other end. Note that the test can
also be done using telephone events rather than tones, i.e., event
167 in RFC 2833 [33] corresponds to "co1". In this case,
connection requests are made with local connection options such
as:
連続は(co1とco2)に調子を変えさせます: これらはこの場合それらを除いて、Trunkパッケージで定義された出来事とネットワーク接続の上でプレーされていただけである状態で同じです、そして、(例えば、「s: r/co1@connectionID 」)をconnectionIDに供給しなければなりません。 RTPサーキットの連続をテストするのにNetwork LoopBack(netwloop)かNetwork Continuity Test(最もnetwtest)モードに関連してそれらを使用できます。 しかしながら、テストIPの連続の場合では、1トーンのテストは十分です。すなわち、「もう一方の端のネットワークループバックモードによる接続モードがある片端のco1"」を発生して、検出すること。 また、テストがトーンよりむしろ電話出来事を使用し終わることができて、すなわち、RFC2833[33]の出来事167が"co1""に対応することに注意してください。 この場合、以下などの市内接続オプションで接続要求をします。
L: a:PCMU;telephone-event,fmtp:"telephone-event 167"
L: ; fmtp: : PCMU、電話出来事、「電話イベント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): この出来事は、何らかの数のICMPの手の届かないパケット[19]がこの出来事を要求しながらRQNTを受け取ったのでこの接続のために受け取られたのを示します。 この通知は、ゲートウェイによってこの接続に送られたパケットがそれらの目的地に到着しなかったか、または受け入れられなかったのを示します(例えばポートは閉じられました)。 この出来事が要求されているとき、1〜255までの10進数があるただ一つのパラメタは、出来事が通知される前に起こらなければならないICMPの手の届かないパケットの数を示すために含まれるかもしれません。 どんなパラメタにも要求を提供しないなら、3のデフォルト値を想定します。 出来事がいったん起こると、さらなる要求が勘定を再開始するのに必要であるので、これは1回限りの出来事です。
Foster & Andreasen Informational [Page 44] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[44ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
The observed event is parameterized with two parameters:
観測された出来事は2つのパラメタでparameterizedされます:
* 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に含まれていた同じ値要求された出来事がparameterizedされなかったなら
* The second parameter is the error code indicated in the ICMP
unreachable packet, e.g.:
* 2番目のパラメタは例えばICMPの手の届かないパケットで示されたエラーコードです:
0 = net unreachable;
0 =ネット手の届かない。
1 = host unreachable;
1 =ホスト手の届かない。
2 = protocol unreachable;
2 =プロトコル手の届かない。
3 = port unreachable;
3 =ポート手の届かない。
4 = fragmentation needed and DF set;
4 断片化が必要とした=とDFはセットしました。
5 = source route failed.
5 = 送信元経路は失敗しました。
etc.
など
An example of a request might be as follows:
要求の例は以下の通りであるかもしれません:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: r/iu@364823(N)(5)
RQNT2001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0R: 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.
この場合、aに通知します。このゲートウェイから接続ID364823との関係に送られる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)
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0O: 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".
最初のパラメタは、5つのICMPの手の届かないパケットがこの要求があるRQNTを送ったので受け取られたのを示します。 2番目のパラメタ、(「3インチ) 理由を指定する、どれ、この場合、「ポート手が届きませんか」、」
Foster & Andreasen Informational [Page 45] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[45ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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まで####、は10進数です。
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.
メディアは(ma)を始めます: 接続のときに接続のときに最初の有効なRTPメディア向けの資料セットを受け取るとき、メディアスタートイベントは起こります。 ローカルの信号を同期させるのにこの出来事を使用できます、例えば、ringback、相手からのメディアの到着で。
The event is detected on a connection. If no connection is
specified, the event applies to all connections for the endpoint,
regardless of when the connections are created (i.e., if a
connection is not specified, the event will occur when the first
valid RTP packet arrives on any one of the connections on that
endpoint).
出来事は接続に検出されます。 接続が全く指定されないなら、出来事は終点のためのすべての接続に適用されます、接続が創造される(すなわち、最初の有効なRTPパケットがその終点における接続のどれかのときに到着して、接続が指定されないと、出来事は起こるでしょう)時にかかわらず。
Operation complete (oc):
This is the standard definition of operation complete [1].
操作の完全な(oc): これは操作完全な[1]の標準定義です。
Operation failure (of):
This is the standard definition of operation failure [1].
操作失敗(of): これは操作失敗[1]の標準定義です。
Packet Loss Exceeded (pl):
Packet loss rate exceeds the threshold of the specified decimal
number (with a range of 1 to 100,000) of packets per 100,000
packets, where the packet loss number is indicated in parenthesis.
For example, PL(10) is a drop rate of 10 in 100,000 packets. This
event is requested with a parameter indicating at what packet loss
rate the Call Agent wishes to be reported. If the packet loss
exceeds that value, the event is reported with that same
parameter. The event is only reported once when the packet loss
threshold is exceeded. Once reported, a following request will
re-initiate packet loss measurements and report when the threshold
is exceeded again.
パケット損失は(pl)を超えていました: パケット損失率は10万のパケットあたりのパケットの指定された10進数(1つの範囲の1〜10万がある)の敷居を超えています。そこで、パケット損失番号は挿入句で示されます。 例えば、PL(10)は10万のパケットの10の低下率です。 パラメタが、Callエージェントをどんなパケット損失率で報告されたいかを示していて、この出来事は要求されています。 パケット損失がその値を超えているなら、出来事はその同じパラメタで報告されます。 パケット損失敷居が超えられているときだけ、出来事は一度報告されます。 いったん報告されると、敷居が再び超えられているとき、次の要求は、パケット損失測定値を再開始して、報告するでしょう。
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): 上質の敷居を超えている遅れとジターのパケット損失率か組み合わせ。 遅れ、ジター、およびパケット損失率のための上質の敷居は食糧を供給された値です。
Foster & Andreasen Informational [Page 46] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[46ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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、(<タイムアウト>、第=<開始時刻>)、: この出来事は、RTPもRTCPパケットもしばらくこの接続のときに<タイムアウト>価値(秒の)と等しい状態で受け取られていないのを示します。 要求をするとき、10進数としてパラメタで1〜65535までタイムアウト値を供給できます。 出来事を報告するとき、ObservedEventsで<タイムアウト>パラメタを提供するでしょう--そして、それは単に使用される値を繰り返します。 タイマが期限が切れる前にRTPかRTCPパケットが受け取られているなら、タイマは、リセットされて、再開されます。 タイマが指定された接続のときに指定された期間の間に届くRTPもRTCPパケットなしで期限が切れる場合にだけ、出来事は発生するでしょう。 出来事が<タイムアウト>パラメタなしで要求されるなら60秒のデフォルトタイムアウトが想定されることに注意してください。 それでも、<タイムアウト>価値はObservedEventsで報告されるでしょう、タイムアウト値が全く要求で示されなかったとしても(デフォルト値はその場合示されるでしょう)。 出来事がいったん起こると、さらなる要求がタイマを再初期化するのに必要であるので、これは1回限りの出来事です。
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:
また、別の任意の<開始時刻>パラメタは含まれるかもしれません。 これは、タイマがいつ始動するかを示すのに使用されます。 それは以下の値の1つを持つことができます:
* "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.
* もう一方の端からタイマがRTCPパケットの後にだけ始動するはずであるのを示す"ra"を受け取りました(要求をした後に最初の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.
<タイムアウト>か<開始時刻>のどちらかが要求に含まれるかもしれませんが、<タイムアウト>価値だけがレポートに含まれていることに注意してください。
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)
RQNT2001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0R: r/rto@364823 (N)(120、第等しさ、不-、)
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.
この場合、aに通知します。どんなRTPもRTCPパケットも接続364823のときに120秒間受け取られていない期間があると、起こるでしょう。
Foster & Andreasen Informational [Page 47] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[47ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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)
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0O: 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)を変えました: この出来事は、このパッケージの旧バージョンとの互換性を維持するためにここに含まれているだけです。 この出来事は、packetizationの期間がSR(20)のように挿入句に同封されたミリセカンドで何らかの10進数に変化したのを示します。
Used Codec Changed (uc):
This event is only included here to maintain compatibility with
the previous version of this package. This event is requested
without a parameter, but when reported, the hexadecimal payload
type is enclosed in parenthesis, as in UC(8), to indicate the
codec was changed to PCM A-law. Codec Numbers are specified in
RFC 3551 [26], or in a new definition of the audio profiles for
RTP that replaces this RFC.
中古のコーデックは(uc)を変えました: この出来事は、このパッケージの旧バージョンとの互換性を維持するためにここに含まれているだけです。 この出来事はパラメタなしで要求されていますが、報告されると、16進ペイロードタイプは、コーデックがPCM A-法に変わったのを示すためにUC(8)のように挿入句に同封されます。 コーデック民数記はRFC3551[26]、またはこのRFCを取り替えるRTPのためのオーディオプロフィールの新しい定義で指定されます。
2.11. Resource Reservation Package
2.11. 資源予約パッケージ
Package Name: RES Version: 0
名前をパッケージしてください: RESバージョン: 0
2.11.1. Description
2.11.1. 記述
The "RES" package provides local connection option support for resource reservations as well as an event to indicate reservation loss.
出来事と同様に資源予約が予約の損失を示すように、「RES」パッケージはオプションサポートを市内接続に提供します。
A number of LocalConnectionOption parameters are used in doing resource reservations: "reservation request", "reservation direction", "reservation confirmation" and "resource sharing".
多くのLocalConnectionOptionパラメタが資源予約をする際に使用されます: 「予約の要請」、「予約指示」、「予約確認」、および「リソース・シェアリング。」
Reservation Request LocalConnectionOption: The gateways can be instructed to perform a reservation on a given connection using RSVP. When a reservation is needed, the Call Agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service". The absence of reservation can be indicated by asking for the "best effort" service, which is the default value for this parameter.
予約の要請LocalConnectionOption: ゲートウェイがRSVPを使用することで与えられた接続の予約を実行するよう命令できます。 予約が必要であるときに、Callエージェントは使用されるべきであり、「制御負荷」か「保証されたサービス」のどちらかである予約プロフィールを指定するでしょう。 「ベストエフォート型」のサービスを求めることによって、予約の欠如を示すことができます。(サービスはこのパラメタのためのデフォルト値です)。
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
RSVPをするかどうかが予約の要請LocalConnectionOptionパラメタがこの接続(「制御負荷」か「保証されたサービス」のどちらかが示されている)を求める接続要求に含まれているかどうかに依存しています。 aであるなら、接続を変更してください。
Foster & Andreasen Informational [Page 48] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[48ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
(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.
(MDCX)要求は予約における変化を必要とします、そして、「予約の要請」パラメタは、LocalConnectionOptionsに含まれていませんでしたが、その接続を求める前の接続要求のためのLocalConnectionOptionsに含まれていました、そして、次に、それのための以前に救われた値への「予約の要請」値のデフォルトは接続です。 aであるなら、(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".
* 予約指示LocalConnectionOptionsパラメタが指定したならRSVP「経路」メッセージを放ち始めてください、「発信してください、単に」、「発信、-受信してください、」
* 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).
* 中に接続があるなら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の予約のための別のLocalConnectionOptionパラメタは予約確認パラメタです。(それは、資源予約が何をあらかじめ条件とさせるかを決定します)。([1])がうまくいっている接続要求を承諾するものであることを確実にしてください:
Foster & Andreasen Informational [Page 49] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[49ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
* 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.
* 「予約確認」パラメタが設定される、「発信、-単に、」、PATHが通信するとき、ゲートウェイ意志の"Ack"を送って、中でうまくいっている予約について簡単に述べるために対応するRESVを受け取る、指示を送ってください。
* If the "reservation confirmation" parameter is set to
"receive-only", the gateway will "Ack" when reservation
confirm for a reservation has been received.
* 予約であるときに、「予約確認」パラメタが「受信専用である」状態で設定されるなら、ゲートウェイ意志の"Ack"は、aのために予約が受けられたと確認します。
* If the reservation confirmation parameter is set to "send-
receive", the gateway will "Ack" only after the PATH message
has been sent and the corresponding RESV has been received
for send direction, and reservation confirm has been
received for the receive direction.
* 予約確認パラメタが設定される、「発信してください、受信、」、PATHメッセージを送って、RESVが受け取られている対応が発信した後にだけゲートウェイ意志の"Ack"が受け取られた、指示、および予約が、確認する指示を受け取ってください。
Note that:
以下のことに注意してください。
Values "receive-only" and "send-receive" are triggers for the
gateway to request reservation confirm (RESVCONF) when it sends
out the RESV.
そして、「受信専用」を評価する、「発信、-受信してください、」 ゲートウェイへの引き金は、予約が、それがいつRESVから発信するかを確認するよう(RESVCONF)要求することになっていますか?
Pre-conditions SHOULD only be added for the direction(s) for which
resource reservations have been requested. If a direction is
added as a pre-condition, and that direction was not requested in
the resource reservation, the direction MUST simply be ignored as
a pre-condition.
プレ状態SHOULD、資源予約が要求されている指示のために単に加えられてください。 指示がプレ状態として加えられて、その指示が資源予約に基づき要求されなかったなら、プレ状態として単に指示を無視しなければなりません。
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
暫定的な応答SHOULD、正常な再試行タイマの外に起こると確認を予想して、事実上、予約確認パラメタに値があるなら暫定的な応答を前提としなければならないなら提供してください、「発信、-受信してください、」、(暫定的な応答がなければ、SDP情報を返すことができません。
Foster & Andreasen Informational [Page 50] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[50ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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]).
予約まで起こらない最終的な"Ack"は完全です。 通常、もう一方の端まで中に通過するべき必要性がもう片方の指示のRSVP PATHメッセージを開始するために注文されるというSDP情報以来の行き詰まりにおけるこの缶の結果) 暫定的な応答と最終的な応答の両方にSDP情報とconnectionIDを含まなければなりません。 無くなっている最終的な応答の急速な検出を確実にして、承認されていて、最終的な暫定的な応答が取引のために次々とSHALLを発行して、すなわち、それらがSHALLであることは最終的な応答に空の"ResponseAck"パラメタを含んでいます。注意、([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(トランザクションタイムアウト)SHOULDが返されるのを確実にしてください。
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ウェイ呼ぶシナリオでは、共有は可能ではありません。 Callエージェントだけが、呼び出されている特徴によって、何が可能であるかもしれないかを知っています。
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:
Callエージェントが、共有が可能であることを示すのを許容するために、リソース・シェアリングLocalConnectionOptionパラメタは紹介されます。 このパラメタは以下の値の1つを持つことができます:
* A value "$" can be specified where $ refers to "this
connection". This value is used when doing a create
connection and indicates the intent to share resources with
this connection.
* $が「この接続」について言及するところで値の「$」を指定できます。 するaがシェアリソースに接続を創造して、意図を示すとき、この値はこの接続と共に使用されています。
* 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を持っている接続とリソースを共有するという要求であることを示します)(複数の接続が示される接続とリソースを共有するのを許容して)。
Foster & Andreasen Informational [Page 51] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[51ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
* 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リソースプロフィールは接続の帯域幅とpacketizationの期間から推論されるでしょう。
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がService[35]のPacketCable Dynamic Qualityと共に使用されるならNCS[36]のパラメタが予約方向、確認、および予約の代わりにここで説明されたパラメタを共有しながら使用されることに注意してください。
2.11.2. Parameter Encoding
2.11.2. パラメタコード化
The Local Connection Options for the "RES" package consist of the following:
「RES」パッケージのためのLocal Connection Optionsは以下から成ります:
* The resource reservation parameter, encoded as the keyword "r",
followed by a colon and the value "g" (guaranteed service),
"cl" (controlled load) or "be" (best effort).
* コロンと値「g」(アフターサービスを保証します)か、「Cl」(制御負荷)か「いる」(ベストエフォート型)でキーワード「r」としてコード化された資源予約パラメタは従いました。
* The reservation direction parameter, encoded as the keyword
"r-dir" followed by a colon and the value "sendonly",
"recvonly" or "sendrecv".
* キーワード"r-dir"がコロンと値の"sendonly"か、"recvonly"か"sendrecv"で続いてコード化された予約方向パラメタ。
* The reservation confirmation parameter, encoded as the keyword
"r-cnf" followed by a colon and the value "none", "sendonly",
"recvonly" or "sendrecv".
* キーワード"r-cnf"が値のコロンと「なにも」か、"sendonly"か、"recvonly"か"sendrecv"で続いてコード化された予約確認パラメタ。
* The resource sharing parameter, encoded as the keyword "r-sh"
followed by a colon and either:
* キーワード"r-sh"がコロンとどちらかで続いてコード化されたリソース・シェアリングパラメタ:
* The wild-card character "$" indicating this connection,
indicating future plans to share resources with this
connection, or
* または未来を示して、この接続を示すワイルドカードキャラクタ「$」が、この接続とリソースを共有するのを計画している。
* A connection ID, indicating a request to share resources
with the connection having the specified connection ID
(and all other connections sharing resources with that
connection), or
* または指定された接続ID(そして、その接続とリソースを共有している他のすべての接続)を持っている接続とリソースを共有するという要求を示す接続ID。
Foster & Andreasen Informational [Page 52] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[52ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
* 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」パッケージに関するケースに含まれていません。
2.11.3. Events
2.11.3. イベント
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 | |
------------------------------------------------------
------------------------------------------------------ | シンボル| 定義| R| S持続時間| |------------------------------------------------------| | re| リソース誤り| C| | | rl| リソースは失われました。| 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番目のパラメタとして引用文字列の形に上では、含まれるかもしれません。
Foster & Andreasen Informational [Page 53] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[53ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
Example report might include:
例のレポートは以下を含むかもしれません。
O: res/rl@0A3F58(resverr)
O: res/rl@0A3F58 (resverr)
or
または
O: res/rl@0A3F58(resverr, "some additional commentary")
O: res/rl@0A3F58 (resverr、「何らかの追加論評」)
Note that this event will not be reported if an error occurs while
a resource reservation is initially being set up (i.e., the event
was only reported as a result of an error that occurred after the
reservation was set up).
資源予約が初めはセットアップされている間(すなわち、イベントは予約がセットアップされた後に発生した誤りの結果、報告されただけです)、誤りが発生するとこのイベントが報告されないことに注意してください。
Resource Lost (rl):
Loss of reservation during the life of a connection can be
reported by using the "rl" event. This event is not requested
with a parameter, but is reported with a parameter (see below for
possible values). If requested on an endpoint (without specifying
the connection ID), the request refers to all present and future
connections on that endpoint.
リソースは(rl)を失いました: "rl"イベントを使用することによって、接続の寿命の間の予約の損失を報告できます。 このイベントは、パラメタで要求されていませんが、パラメタで報告されます(可能な値に関して以下を見てください)。 終点(接続IDを指定することのない)で要求されるなら、要求はその終点ですべての現在の、そして、今後の接続について言及します。
When reported, the connectionID is always supplied along with a
reason for the loss indicated as a parameter. One of the
following possible reasons for loss MUST be supplied as the
parameter when the event is reported:
報告すると、パラメタとして示された損失の理由と共にconnectionIDをいつも供給します。 イベントを報告するとき、パラメタとして損失の以下の可能な理由の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)
O: res/rl@0A3F58 (ResvTear)
or
または
O: res/rl@0A3F58(ResvTear, "some other commentary")
O: res/rl@0A3F58 (ResvTear、「ある他の論評」)
Foster & Andreasen Informational [Page 54] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[54ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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).
資源予約が初めはセットアップされている間(それが初めはセットアップされた後に予約が失われた場合にだけ、すなわち、イベントは報告されます)、誤りが発生するとこのイベントが報告されないことに注意してください。
2.12. Announcement Server Package
2.12. 発表サーバパッケージ
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 | |
---------------------------------------------------------------
--------------------------------------------------------------- | シンボル| 定義| R| S持続時間| |---------------------------------------------------------------| | ann(url)| 発表をプレーしてください。| | TO、C変数| | oc| 操作完全です。| x| | | of| 操作失敗| x| | ---------------------------------------------------------------
Changes from the previous version: change to conform to standard reporting of operation failure and operation complete events.
旧バージョンからの変化: 操作失敗と操作の完全なイベントの標準の報告に従うには、変化してください。
The announcement signal is qualified by a URL name:
発表信号はURL名によって資格があります:
S: ann(http://scripts.example.net/all-lines-busy.au)
S: 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:
ゲートウェイSHOULDは、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をファイルしてください。(RFC1738[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、(RFC2326[29])のセクション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復帰コードは失敗の場合で適用されます。 失敗したイベントの名前の後にコメントとして引用文字列の形で失敗のさらなるしるしを操作失敗イベントに提供します。
Foster & Andreasen Informational [Page 55] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[55ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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/(/ann、「ファイルが見つからない」)
The "operation complete" event will be detected when the announcement is played out.
発表が使い果たされるとき、「操作完全な」イベントは検出されるでしょう。
O: a/oc(a/ann)
O: /oc(/ann)
2.13. Script Package
2.13. スクリプトパッケージ
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 |
-----------------------------------------------------------------
----------------------------------------------------------------- | シンボル| 定義| R| S| 持続時間| |-----------------------------------------------------------------| | 不-、()。 | 中間的Results/Req| x| Br| | | java(url、…) | 負荷とRun javaスクリプト| | to| 変数| | oc| 操作完全です。| x| | | | of| 操作失敗| x| | | | パール(url、…) | 負荷とRunパールスクリプト| | to| 変数| | tcl(url、…) | 負荷とRun TCLスクリプト| | to| 変数| | vxml(url、…) | 負荷とRun VXML doc。 | | to| 変数| | xml(url、…) | 負荷とRun XMLスクリプト| | to| 変数| -----------------------------------------------------------------
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ドキュメントをロードして、実行するための言語形式として加えられました。 変化して、操作失敗と操作の完全なイベントの標準の報告に従ってください。 追加、「不-、」 イベント。
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がスクリプトの位置を示していて、スクリプト言語を指定する「信号」はparameterizedされます。 議論のコンマで切り離されたリストはスクリプトを実行する際に使用する初期値パラメタとして任意にURLパラメタのあとに続くかもしれません。 RFC2396[30]によると、URL体系はファイルftp、または構文があるhttp体系を含むかもしれません。 例として:
S: script/vxml(ftp://ftp.example.net/credit-card.vxml,arg1,arg2,
...,argn)
S: スクリプト/vxml( ftp://ftp.example.net/credit-card.vxml 、arg1、arg2、…、argn)
Foster & Andreasen Informational [Page 56] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[56ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
The argument list "arg1,arg2,...,argn" is passed to the script/document as a list of initial parameters.
アーギュメントの並び、「arg1、arg2」…「argn、」 初期値パラメタのリストとしてスクリプト/ドキュメントに通過されます。
The pre-condition for a successful response (return code of "200") is correct syntax and capability (support is available for this request). Standard MGCP return codes apply in the case of failure. Some further (non-application/script specific) failure indications MAY be provided in the operation failure event as a comment in the form of a quoted string following the name of the failed event.
うまくいっている応答(「200」の復帰コード)のためのプレ状態は、正しい構文と能力(サポートはこの要求に利用可能である)です。 標準のMGCP復帰コードは失敗の場合で適用されます。 コメントとして失敗したイベントの名前に従う引用文字列の形でさらなるいくつかの(非アプリケーション/スクリプト特有)の失敗指摘を操作失敗イベントに提供するかもしれません。
Example
例
O: script/of(script/vxml,"file not found")
O: /に原稿を書きます。(スクリプト/vxml、「ファイルが見つからない」)
The script produces an output, which consists of one or several text strings, separated by commas. This provides the return-status of the script as well as return parameters (if there are any)
スクリプトは出力かコンマによって分離された数個のテキスト文字列を作り出します。(出力は1から成ります)。 これはリターンパラメタと同様にスクリプトのリターン状態を提供します。(いずれかあれば)
O: script/oc(script/vxml,return-status=<status>,
name1=value1,name2=value2,...)
O: スクリプト/oc(スクリプト/vxml、リターン状態は<状態>、name1=value1、name2=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.
<状態>が値「成功」か「失敗」の1つを持つことができるところ。 そして、名前価値のコンマで切り離されたリストが対にされるとき、出力パラメタはこれのあとに続いています。
Intermediate Result/Request (ir(<params>)):
This provides a way for:
中間結果/要求、(不-、(<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).
* 中間結果(例えば、それが操作の前にCallエージェントに完全な状態で知らせるタイミング関心のために重要であるケース)についてCallエージェントに知らせるスクリプト。
* The script to request some information from the Call Agent.
* Callエージェントから何らかの情報を要求するスクリプト。
* 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).
* 何らかのイベントのスクリプトを知らせるCallエージェントかスクリプトの操作に、重要であるかもしれない情報、(この場合、「不-、」、信号として使用される、)
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,..)").
パラメタ、(すなわち、<が名前価値のコンマで切り離されたリストが組であったなら>) SHOULDをparamsする、例えば、不-、(name1=value1、name2=value2。) このイベントを要求するとき、Callエージェントはイベントパラメタを入れるかもしれません、その場合、MGCP構文要件が動作が指定されるのを(例えば、「R: 不-(N)(nam1=value1、name2=value2)」)必要とします。
If the Call Agent requests "ir" as a signal, at least one
parameter MUST be provided.
Callエージェント要求である、「不-、」 信号として、少なくとも1つのパラメタを提供しなければなりません。
Foster & Andreasen Informational [Page 57] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[57ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
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.
要求する、「不-、」 また、信号、Callエージェントはオリジナルのスクリプト信号を繰り返さなければなりません。 これは、MGCPのTO信号の意味論と一致していること(すなわち、オリジナルの「スクリプト」信号が含まれていないと、信号/スクリプトは止められる)です。 これに関する唯一の問題が発信するというどのa要求に可能な競合条件があるかということである、「不-、」 ちょうどスクリプトが止まったように信号は発生できました。 この混乱を避けるために、↓これはRECOMMENDEDです: スクリプト信号がいつで含まれているか、「不-、」 合図してください、そして、パラメタ(スクリプト信号の)を含めて、これがスクリプトの新しいインスタンスでないことを示してくださいといって、すなわち、現在で実行して、スクリプトが全くなければ、新しいものを実行し始めないでください。
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).
「不-、」 信号は実行スクリプトに関連しているだけです。 イベント/信号に関する要求をするとき、なにも稼働していないかどうか、または次に、新しいスクリプト要求が要求で含まれていないかどうか、「不-、」 信号/イベントは実行されないでしょう。(すなわち、「不-、」 パラメタがあるイベントは、構文解析と実行のための既存のスクリプトに通過されて、関係があるとしてMGCPと同じくらい遠い不透明なものであると考えられます。 何かそのようなスクリプトが存在していないと、スクリプトが実行でないことを示して、応答コード「800」は返されるでしょう。).
The following response code is associated with this package:
以下の応答コードはこのパッケージに関連しています:
Code Text Explanation
コードテキスト説明
800 Script not Request for "ir" signal or event
Executing but no script is executing at the
time the request was received.
800がどんなRequestにも原稿を書かない、「不-、」 要求を受け取ったとき、信号かイベントExecutingにもかかわらず、どんなスクリプトも実行ではありません。
Note that package specific error codes include the package name
following the error code. For example, if error code 800 occurs
in response to a request with a transaction ID of 1001, it would
be sent as:
エラーコードに従って、特定の誤りがコード化するパッケージがパッケージ名を含んでいることに注意してください。 例えば、エラーコード800が1001年のトランザクションIDとの要求に対応して起こるなら、以下としてそれを送るでしょう。
800 1001 /SCRIPT
800 1001/スクリプト
Foster & Andreasen Informational [Page 58] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[58ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
3. IANA Considerations
3. IANA問題
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
パッケージタイトル名前バージョン------------- ---- ------- 1DTMF D1ケタ地図拡大DM1 0メディア形式FM0ジェネリックG1受話器H1がSST0がリストSL0トランクT1に合図するL1RTP R1資源予約RES0スクリプトスクリプト1の補っているトーンを裏打ちするという発表
The following extension digit map letter has been registered with IANA:
以下の拡大ケタ地図手紙はIANAに登録されました:
Package Letter
------- ------
DM1 P
パッケージ手紙------- ------ DM1P
The following Local Connections have been registered with IANA:
以下のLocalコネクションズをIANAに登録してあります:
Field Name
------- -----
Media Format fmtp
Reservation Confirmation r-cnf
Reservation Direction r-dir
Resource Sharing r-sh
フィールド名------- ----- メディアFormat fmtp予約Confirmation r-cnf予約Direction r-dir Resource Sharing r-sh
4. Security Considerations
4. セキュリティ問題
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]で示されたものを超えたどんなさらなるセキュリティ問題も必要としません。
5. Acknowledgements
5. 承認
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.
特別な感謝はオリジナルのMGCP1.0仕様の作者のためです: マウリシオArango、アンドリュー・デュガン、イサク・エリオット、クリスチャンHuitema、およびスコットはピケを張ります。
Foster & Andreasen Informational [Page 59] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[59ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
Thanks also to the reviewers of this document, including but not limited to: Jerry Kamitses, Sonus Networks; Dave Auerbach, Dan Wing, Cisco Systems; Ed Guy, EMC Software; Martin Wakley, Nortel Networks.
また、他を含んでいて、このドキュメントの評論家をありがとうございます: ジェリーKamitses、Sonusネットワーク。 デーヴ・アウアーバック、ダンWing、シスコシステムズ。 エド・ガイ、EMCソフトウェア。 マーチン・ワクリー、ノーテルネットワーク。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[1] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。
[2] Bellcore, "LSSGR: Switching System Generic Requirements for Call
Control Using the Integrated Services Digital Network User Part
(ISDNUP)", GR-317-CORE, Issue 2, December 1997.
[2] Bellcore、「LSSGR:」 「サービス統合ディジタル網ユーザを使用する呼び出しコントロールのための交換システムジェネリック要件は(ISDNUP)を分けます」、GR317コア、問題2、1997年12月。
[3] ITU-T, "Telephone User Part Signaling Procedures", ITU-T Q.724,
November 1988.
[3] ITU-T、「電話ユーザ部分シグナリング手順」、ITU-T Q.724、1988年11月。
[4] ANSI, "OAM&P - Terminating Test Line Access and Capabilities",
T1.207-2000.
[4] ANSI、「OAM&P--テストを終えて、アクセスと能力を裏打ちしてください」、T1.207-2000。
[5] Bellcore, "Notes on the Network", Special Report SR-2275, Issue
3, December 1997.
[5] Bellcore、「ネットワークに関する注」(特別なレポートSR-2275)は3、1997年12月を発行します。
[6] Bellcore, "Call Processing" GR-505-CORE, Issue 1, December 1997.
[6] Bellcore、「呼び出し処理」GR505コアは1、1997年12月を発行します。
[7] Bellcore, "LSSGR: Signaling for Analog Interfaces", GR-506-CORE,
Issue 1, June 1996.
[7] Bellcore、「LSSGR:」 「アナログのために合図するのは連結する」GR506コアが1、1996年6月を発行します。
[8] ITU-T, "Technical Characteristics of Tones for the Telephone
Service", ITU-T E.180, March 1998.
[8] ITU-T、「電話サービスのためのトーンの技術的な特性」、ITU-T E.180、1998年3月。
[9] ITU-T, "Various Tones Used in National Networks", ITU-T E.180,
Supplement 2, January 1994.
[9] ITU-T、「全国的なネットワークに使用される様々なトーン」、ITU-T E.180、補足2、1994年1月。
[10] ITU-T, "Applications of Tones and Recorded Announcements in
Telephone Services", ITU-T E.182, March 1998.
[10] ITU-T、「電話サービスにおけるトーンと記録された発表の応用」、ITU-T E.182、1998年3月。
[11] Bellcore, "Call Forwarding Sub-Features FSD-01-02-1450, GR-586,
Issue 1, June 2000.
[11] Bellcore、「2000年6月に推進サブの特徴FSD-01-02-1450、GR-586を問題1と呼んでください。」
[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:」 「視覚通話待ち指示器ジェネリック要件(FSD01-02-2000)」(GR-1401)は01、2000年6月を発行します。
Foster & Andreasen Informational [Page 60] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[60ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
[14] Bellcore, "LSSGR Voiceband Data Transmission Interface", Section
6.6, GR-30-CORE, Issue 02, December 1998.
[14] Bellcore、「LSSGR Voicebandデータ伝送インタフェース」、セクション6.6、GR30コアは02、1998年12月を発行します。
[15] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[15] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[16] Bellcore, "LSSGR: Call Waiting, FSD 01-02-1201", GR-571, Issue
01, June 2000.
[16] Bellcore、「LSSGR:」 「キャッチホン、FSD01-02-1201」、GR-571、01、6月2000日を発行してください。
[17] Bellcore, "LSSGR: Verification Connections FSD 25-05-0903", GR-
531-CORE, Issue 1, June 2000.
[17] Bellcore、「LSSGR:」 「検証コネクションズFSD25-05-0903」(GRの531コア)は1、2000年6月を発行します。
[18] Bellcore, " LSSGR: CLASS Feature: Calling Identity Delivery on
Call Waiting, FSD 01-02-1090, GR-575, Issue 01, June 2000.
[18] Bellcore、「LSSGR:」 クラス機能: キャッチホンにアイデンティティを配送と呼んで、FSD01-02-1090(GR-575)は01、2000年6月を発行します。
[19] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[19] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[20] Bellcore, "Class Feature: Screen Editing (FSD 30-28-0000)", GR-
220, Issue 2, April 2002.
[20] Bellcore、「クラスは以下を特集します」。 「(FSD30-28-0000)を編集するスクリーン」、GR220は2、2002年4月を発行します。
[21] ITU-T, "Procedure for document facsimile transmission in the
general switched telephone network", ITU-T T.30, April 1999.
[21] ITU-T、「一般的な切り換えられた電話網におけるドキュメントファクシミリ伝送のための手順」、ITU-T T.30、1999年4月。
[22] ITU-T, "300 bits per second duplex modem standardized for use in
the general switched telephone network", ITU-T V.21, November
1988.
[22] ITU-T、「複式のモデムが司令官における使用のために標準化した300のbpsが電話網を切り換えました」、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技術、「2002年12月にシステム数の7インチ、GR246コア、問題7に合図するTelcordia技術仕様。」
[24] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Name
Delivery Generic Requirements (FSD 01-02-1070)", GR-1188, Issue
02, December 2000.
[24] Telcordia技術、「LSSGR:」 クラス機能: 「名前配送をジェネリック要件(FSD01-02-1070)と呼びます」、GR-1188は02、2000年12月を発行します。
[25] Telcordia Technologies, "LSSGR: CLASS Feature: Calling Number
Delivery (FSD 01-02-1051)", GR-31, Issue 01, June 2000.
[25] Telcordia技術、「LSSGR:」 クラス機能: 「配送(FSD01-02-1051)に数に電話をします」、GR-31は01、2000年6月を発行します。
[26] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[26]SchulzrinneとH.とS.Casner、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC3551、2003年7月。
[27] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[27] ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[28] Berners-Lee, T., Masinter, L. and M. McCahill, Eds., "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[28] バーナーズ・リーとT.とMasinterとL.とM.McCahill、Eds、「Uniform Resource Locator(URL)」、RFC1738、12月1994日
Foster & Andreasen Informational [Page 61] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[61ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
[29] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[29]SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。
[30] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[30]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[31] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[31] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[32] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[32] パーキンスとC.とKouvelasとI.とホドソンとO.とハードマンとV.とハンドレーとM.とBolotとJ.C.、ベガ-ガルシアとA.とS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」RFC2198(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有効搭載量」、RFC2833)は2000がそうするかもしれません。
[34] Foster, B., "MGCP CAS Packages", RFC 3064, February 2001.
[34] フォスター、B.、「MGCP CASパッケージ」、RFC3064、2001年2月。
[35] PacketCableTM, Dynamic Quality if Service Specification,
http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07-
030815.pdf
[35]PacketCableTM、ダイナミックな品質、サービス仕様、 http://www.packetcable.com/downloads/specs/PKT-SP-DQOS-I07- 030815.pdfです。
[36] PacketCableTM Network-Based Call Signaling Protocol
http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08-
030728.pdf
[36] PacketCableTMのネットワークベースの呼び出しシグナリングプロトコル http://www.packetcable.com/downloads/specs/PKT-SP-EC-MGCP-I08- 030728.pdf
[37] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Eds.,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[37] 木立とC.とPantaleoとM.とアンダーソンとT.とT.テイラー、Eds、「ゲートウェイ制御プロトコルバージョン1インチ、RFC3525、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.とデュガン、A.、エリオット、I.とHuitemaとC.とS.ピケット、「メディアゲートウェイコントロールは(MGCP)についてバージョン1インチ議定書の中で述べます、RFC2705、1999年10月。」
Foster & Andreasen Informational [Page 62] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[62ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
7. Authors' Addresses
7. 作者のアドレス
Bill Foster Cisco Systems
ビルフォスターシスコシステムズ
Phone: +1 250 758 9418 EMail: bfoster@cisco.com
以下に電話をしてください。 +1 9418年の250 758メール: bfoster@cisco.com
Flemming Andreasen Cisco Systems Edison, NJ 08837
フレミングAndreasenシスコシステムズのエディソン、ニュージャージー 08837
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
Foster & Andreasen Informational [Page 63] RFC 3660 Basic MGCP Packages December 2003
フォスターとAndreasen情報[63ページ]のRFC3660の基本的なMGCPは2003年12月をパッケージします。
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Foster & Andreasen Informational [Page 64]
フォスターとAndreasen情報です。[64ページ]
一覧
スポンサーリンク
