RFC3064 日本語訳
3064 MGCP CAS Packages. B. Foster. February 2001. (Format: TXT=116818 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Foster Request for Comments: 3064 Cisco Systems Category: Informational February 2001
コメントを求めるワーキンググループB.フォスターの要求をネットワークでつないでください: 3064年のシスコシステムズカテゴリ: 情報の2001年2月
MGCP CAS Packages
MGCP CASパッケージ
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. Included are six packages. The "MS" package covers MF single stage dialing trunks. This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3]. The "DT "package covers immediate start and basic DTMF and dial-pulse trunks and the "BL" package covers the interface to a basic PBX (digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These include EAIN and EANA which is covered by the enclosed "MD" package and the Operator Service Signaling protocol which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package.
このドキュメントはR1 CASのためのメディアゲートウェイChannel Associated Signaling(CAS)パッケージの収集を含んでいます、北米のCAS、基本的なFXOサポートと同様にCAS PBX内部連絡。 含まれているのは、6個のパッケージです。 「さん」パッケージはトランクスにダイヤルするmf単段をカバーしています。 これは、プロトコル[3]を終えながら、基本的なR1とFeature Group D(FGD)と同様にウインク始めと即座のスタートPBX DID/DODトランクスを含んでいます。 「DT、「パッケージは即座の始め、基本的なDTMF、およびダイヤル・パルストランクスをカバーしています、そして、"BL"パッケージは基本的なPBXにインタフェースを覆DigitalかFXSが(連結します)であっています」。 Terminatingプロトコルに加えて、[3]で説明された他の3つのFGDプロトコルがあります。 これらはEAIN、同封の「MD」パッケージで覆われているEANA、および「MO」パッケージによって扱われるオペレータサービスシグナリングプロトコルを含んでいます。 基本的なFXOが内部連絡するので、「してください」というパッケージはサポートを提供します。
Conventions used in this document
本書では使用されるコンベンション
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 RFC-2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119で説明されるように本書では解釈されることであるべきですか?
IESG Note:
IESGは以下に注意します。
This document is being published for the information of the community. It describes a protocol that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16 who are currently working on a potential successor to this protocol.
このドキュメントは共同体の情報のために発表されています。 それは現在多くの製品の中に配備されているプロトコルについて説明します。 Implementersは現在このプロトコルの潜在的後継者に働いているIETF Megaco作業部会とITU SG16で開発を意識しているべきです。
Foster Informational [Page 1] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[1ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Table of Contents
目次
1.0.Introduction ................................................ 3
1.1. Functional Partitioning .................................... 3
1.2. CAS Trunk Types ............................................ 4
1.2.1. "MS" Package ............................................. 5
1.2.2. "DT" Package ............................................. 5
1.2.3. "BL" Package ............................................. 6
1.2.4. "DO" Package ............................................. 6
1.2.5. "MD" Package ............................................. 6
1.2.6. "MO" Package ............................................. 7
2.0. Event Packages ............................................. 7
2.1. Events and Signals for the "MS" package .................... 9
2.2. Events and Signals for the "DT" package .................... 10
2.3. Events and Signals for the "BL" package (Basic PBX) ........ 10
2.4. Events and Signals for the "DO" package .................... 11
2.5. Events and Signals for the "MD" package .................... 12
2.6. Events and Signals for the "MO" package .................... 13
2.7. Event and Signal Descriptions .............................. 13
3.0. Hook-State Signals and Events .............................. 23
3.1. Overview of Approach ....................................... 23
3.2. Suspend/Resume Processing .................................. 23
3.3. Control over Disconnect for E911 ........................... 24
3.3. Release and Release Complete ............................... 24
3.4. Blocking CAS Trunks ........................................ 26
3.5. Summary of Hook-State Events ............................... 26
4.0. Glare Handling ............................................. 27
4.1. Glare on MF Bi-directional Wink-start Trunks ............... 27
4.2. Glare Handling - Basic PBX Trunks .......................... 27
5.0. Example Call Flows ......................................... 28
5.1. PBX to PBX ("MS", "DT, and "BL" packages)................... 28
5.1.1. Call Setup Flows ......................................... 28
5.1.2. Call Tear-Down ........................................... 34
5.1.2.1. Origination End Initiates the Release .................. 35
5.1.2.2. Termination End Initiates the Release .................. 38
5.2. Example Call Flows - "DO" package .......................... 40
5.2.1. Call Setup Flows ......................................... 40
5.2.2. Call Tear-Down ........................................... 42
5.3. Example Call Setup - "MD" Package .......................... 44
5.4. Example Call Setup - "MO" Package .......................... 51
Acknowledgements ................................................ 54
References ...................................................... 55
Author's Address ................................................ 55
Full Copyright Statement ........................................ 56
1.0. 序論… 3 1.1. 機能の分割… 3 1.2. CASトランクはタイプされます… 4 1.2.1. 「MS」パッケージ… 5 1.2.2. "DT"パッケージ… 5 1.2.3. "BL"パッケージ… 6 1.2.4. 「してください」というパッケージ… 6 1.2.5. 「MD」パッケージ… 6 1.2.6. 「MO」パッケージ… 7 2.0. イベントパッケージ… 7 2.1. 「さん」パッケージのための出来事とSignals… 9 2.2. "DT"パッケージのための出来事とSignals… 10 2.3. "BL"のための出来事とSignalsは(基本的なPBX)をパッケージします… 10 2.4. 「してください」というパッケージのための出来事とSignals… 11 2.5. 「MD」パッケージのための出来事とSignals… 12 2.6. 「MO」パッケージのための出来事とSignals… 13 2.7. 出来事と信号記述… 13 3.0. 信号と出来事をフックで述べてください… 23 3.1. アプローチの概観… 23 3.2. 処理するのを中断するか、または再開してください… 23 3.3. 911Eのための分離の上で制御してください… 24 3.3. リリースとリリース完全… 24 3.4. CASトランクスを妨げます… 26 3.5. フック州のイベントの概要… 26 4.0. 取り扱いをにらみつけてください… 27 4.1. mfの双方向のウインクスタートトランクスの上ににらみつけてください… 27 4.2. 取り扱いをにらみつけてください--基本的なPBXトランクス。 27 5.0. 例の呼び出しは流れます… 28 5.1. PBXへのPBX、(「さん」、「DT、および"BL"パッケージ、)、」、… 28 5.1.1. 呼び出しセットアップは流れます… 28 5.1.2. 分解に電話をしてください… 34 5.1.2.1. 創作終わりはリリースを開始します… 35 5.1.2.2. 終了終わりはリリースを開始します… 38 5.2. 例のCall Flows--「してください」というパッケージ… 40 5.2.1. 呼び出しセットアップは流れます… 40 5.2.2. 分解に電話をしてください… 42 5.3. 例の呼び出しセットアップ--「MD」パッケージ… 44 5.4. 例の呼び出しセットアップ--「MO」パッケージ… 51の承認… 54の参照箇所… 55作者のアドレス… 55 完全な著作権宣言文… 56
Foster Informational [Page 2] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[2ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
1.0.Introduction
1.0. 序論
1.1. Functional Partitioning
1.1. 機能の分割
There are a number of different possible approaches for partitioning the functional responsibility between the Call Agent and the Media Gateway:
Callエージェントとメディアゲートウェイの間には、職能的責任を仕切るための多くの異なった可能なアプローチがあります:
* The Call Agent takes all of the responsibility for the CAS state
machine giving the media gateway detailed commands
* Callエージェントは、詳細なコマンドをメディアゲートウェイに与えながら、CAS州のマシンへの責任のすべてを取ります。
* The media gateway contains the CAS state machine and provides an
abstract interface to the Call Agent
* メディアゲートウェイは、CAS州のマシンを含んでいて、抽象的なインタフェースをCallエージェントに提供します。
Timing requirements of CAS protocols often involve reacting within time intervals measured in tens of milliseconds which makes direct control of timing impossible. The approach used here is to allow the media gateway to handle low level CAS protocol and timing details where at all possible and have the Call Agent involved only whenever higher level processing is required.
CASプロトコルのタイミング要件は、しばしばタイミングの直轄を不可能にする何十ミリセカンドでも測定された時間間隔以内に反応することを伴います。 ここで使用されたアプローチは、可能であるところにメディアゲートウェイがCASが議定書の中で述べる低レベルとタイミングの詳細を扱うのを許容して、より高い平らな処理が必要であるときはいつもだけ、Callエージェントをかかわらせることです。
Taking this approach, the ideal situation would be to allow the Call Agent to treat as many CAS protocols in a similar way, leaving the details to the media gateway. Example: for an incoming MF trunk that involves a single incoming digit string, the Call Agent should not care whether this is a wink start trunk or an immediate start trunk (media gateway should not have to provide the wink-start signal).
このアプローチを取って、理想的な状況はCallエージェントが同様の方法で同じくらい多くのCASプロトコルを扱うのを許容するだろうことです、メディアゲートウェイに詳細を残して。 例: ただ一つの入って来るケタストリングにかかわる入って来るMFトランクについてCallエージェントは、これがウインクスタートトランクかそれとも即座のスタートトランク(メディアゲートウェイはウインクスタート信号を提供するはずである必要はない)であるかを気にかけるべきではありません。
Some goals in partitioning responsibility between the media gateway and media gateway:
メディアゲートウェイとメディアゲートウェイの間の仕切りの責任におけるいくつかの目標:
* Minimize the number of interactions between the Call Agent and the
media gateway.
* Callエージェントとメディアゲートウェイとの相互作用の数を最小にしてください。
* The media gateway should not have to do digit analysis (e.g., to
determine that the incoming digits contain carrier access
information). This is a Call Agent's responsibility.
* メディアゲートウェイはデジタル分析(例えば入って来るケタがキャリヤーアクセス情報を含むことを決定する)をするはずである必要はありません。 これはCallエージェントの責任です。
* Provide some reasonable level of abstraction for the Call Agent so
that it can reuse call flows when possible (e.g., Call Agent
should not have to differentiate between wink start and immediate
start interfaces when only one digit string is involved).
* 可能であるときに、呼び出し流れを再利用できる(例えば、Callエージェントは、ウインク始めと即座のスタートインタフェースの間で1個のケタストリングだけがいつかかわるかを微分する必要はないはずである)ように、Callエージェントのための何らかの妥当な水準の抽象化を提供してください。
* The media gateway should take care of the CAS protocol (and
timeouts) where possible with the Call Agent taking over
responsibility where the media gateway leaves off.
* メディアゲートウェイはCallエージェントがメディアゲートウェイがやめられるところに責任を引き継いでいて可能であるところでCASプロトコル(そして、タイムアウト)の世話をするはずです。
Foster Informational [Page 3] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[3ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Use of Embedded Notifications: Rather than depending on the use of embedded notifications, signals and events were defined that had the specific semantics required. There are two reasons for this:
埋め込まれた通知の使用: 埋め込まれた通知の使用によるよりむしろ、特定の意味論を必要とした信号と出来事は定義されました。 この2つの理由があります:
a) It allows an abstract interface for the Call Agent so that for example, the same incoming call-setup event can be used in the case of MF wink start and MF immediate start trunks, presenting a common interface to the Call Agent even though the semantics at the CAS state-machine level are slightly different (i.e., in the MF wink start case, a wink-start signal is provided reflexively as a result of an incoming seizure, where as in the immediate start case, this is not required).
a) それは例えば、MFウインク始めとMFの即座のスタートトランクスの場合に同じ入って来る呼び出しセットアップイベントを使用できるようにCallエージェントのための抽象的なインタフェースを許容します、CAS州マシンレベルにおける意味論がわずかに異なっていますが(入って来る捕獲の結果、すなわち、MFウインクスタート場合では、ウインクスタート信号を反動的に提供します、これは即座のスタートケースのように必要でないところで)、Callエージェントに一般的なインタフェースを提示して。
b) Potential events that might trigger an embedded notification (e.g., the incoming seizure mentioned above) typically needed to be visible to the Call Agent for billing anyway.
b) 埋め込まれた通知(例えば、前記のように入って来る捕獲)の引き金となるかもしれない潜在的出来事は、通常支払いのためにCallエージェントにとってとにかく目に見える必要がありました。
This does not say that embedded notifications cannot be used. It simply does not necessitate their use.
これは、埋め込まれた通知を使用できないと言いません。 それは彼らの使用を絶対に必要としません。
Out-pulsing Approach: In order to provide the semantics for outpulsing, special higher level signals (e.g., "sup" for call set-up and "inf" for information) are included that contain the necessary semantics.
出かけている脈打つアプローチ: 意味論を提供するために、「外-律動的に送」り、より高いレベルが含まれているのを(例えば、呼び出しセットアップのための「一口」と情報のための"inf")に示している特別番組に関してそれは必要な意味論を含んでいます。
Off-hook and On-hook Signals and Events: A higher level view of off- hook and on-hook events is taken in order to make the interface Q.931-like. This provides the advantage that:
オフフック、フックの上の信号、および出来事: インタフェースをQ.931のようにするようにオフフックとフックにおける出来事の、より高い平らな意見を取ります。 これはそれを利点に提供します:
* Similar call flows result when dealing with Q.931-based interfaces
(e.g., PRI)
* Q.931ベースのインタフェースに対処するとき、同様の呼び出し流れは結果として生じます。(例えば、PRI)
* It's more evident (for ease in debug) when looking at message as
to exactly what is going on without having to refer to previous
events
* まさに前の出来事について言及する必要はなくて起こっていることに関してメッセージを見るとき、それは、より明白です(デバッグにおける容易さのための)。
1.2. CAS Trunk Types
1.2. CASトランクタイプ
The following describes the types of trunks supported by the various packages. Configuration of the specific trunk type (e.g., wink start versus immediate start) is done within the Media Gateway (MG) via provisioning facilities outside the scope of MGCP. The Call Agent's responsibility is to support the particular package (i.e., in general the Call Agent does not have to differentiate between wink start and immediate start, since those differences are taken care of by the MG). However, the Call Agent needs to know which trunks are incoming, outgoing or bi-directional.
以下は様々なパッケージによって支えられたトランクスのタイプについて説明します。 MGCPの範囲の外で施設に食糧を供給することを通してメディアゲートウェイ(MG)の中で特定のトランクタイプ(例えば、ウインク始め対即座の始め)の構成をします。 Callエージェントの責任は特定のパッケージを支える(一般に、すなわち、Callエージェントがウインク始めと即座の始めを区別する必要はありません、それらの違いがMGによって世話をされるので)ことです。 しかしながら、Callエージェントは、どのトランクスが入って来る、外向的であるかまたは双方向であるかを知る必要があります。
Foster Informational [Page 4] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[4ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
1.2.1. "MS" Package
1.2.1. 「MS」パッケージ
The "MS" package is used for PBX DID/DOD trunks as indicated in the following table. It is also used for incoming or outgoing MF wink start trunks (R1 and FGD Terminating protocol [6]).
PBXが以下のテーブルにみられるように/DODトランクスをしたので、「さん」パッケージは使用されています。 また、それは入って来るか出発しているMFウインクスタートトランクスに使用されます。(R1とFGD Terminatingプロトコル[6])。
Table 1 MF PBX Trunks
テーブル1 mf PBXトランクス
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|MF, wink start |Incoming - originate from PBX |
| |(the same as FGD terminating |
| | protocol) |
|MF, wink start |Outgoing - terminate on PBX |
|MF, wink start |Bi-directional |
|MF, Immediate |Incoming (originate from PBX) |
| start | |
|MF, Immediate |Outgoing (terminate on PBX) |
| start | |
--------------------------------------------------
-------------------------------------------------- | トランクタイプ| 指示(w. r. t. ゲートウェイ)| -------------------------------------------------- |MF、ウインク始め|入来--PBXから、発してください。| | |(|終えるFGDと同じくらい| | プロトコル) | |MF、ウインク始め|外向的である、--PBXで終わってください| |MF、ウインク始め|双方向| |mfで、即座です。|入来(PBXから、発します)| | 始め| | |mfで、即座です。|外向的である、(PBXでは、終えます)| | 始め| | --------------------------------------------------
1.2.2. "DT" Package
1.2.2. "DT"パッケージ
DTMF and dial-pulse (DP) trunks (except basic PBX) are covered by the "DT" package along with the DTMF "D" package:
DTMFとダイヤル・パルス(DP)トランクス(基本的なPBXを除いた)はDTMF「D」パッケージに伴う"DT"パッケージで覆われています:
Table 2 DTMF and DP Wink Start and Immediate Start Trunks
テーブル2 DTMF、DPウインク始め、および即座のスタートトランクス
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|DTMF, Immediate |Incoming (originate from PBX) |
| start, wink | |
| start | |
|DTMF, Immediate |Outgoing (terminate on PBX) |
| start, wink | |
| start | |
--------------------------------------------------
-------------------------------------------------- | トランクタイプ| 指示(w. r. t. ゲートウェイ)| -------------------------------------------------- |DTMFで、即座です。|入来(PBXから、発します)| | 始め、ウインク| | | 始め| | |DTMFで、即座です。|外向的である、(PBXでは、終えます)| | 始め、ウインク| | | 始め| | --------------------------------------------------
Foster Informational [Page 5] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[5ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
1.2.3. "BL" Package
1.2.3. "BL"パッケージ
DTMF and dial-pulse (DP) basic PBX trunks are covered by the "BL" package - along with the DTMF "D" package (essentially this is like a "basic line with no features") - either digital or FXS trunk interface:
DTMFとダイヤル・パルス(DP)の基本的なPBXトランクスはDTMF「D」パッケージに伴う"BL"パッケージで覆われています(本質的にはこれは「特徴のない基線」に似ています)--DigitalかFXSトランクのどちらかが連結します:
Table 3 Basic FXS Interface
テーブル3 基本的なFXSは連結します。
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|Basic, DTMF and |Bi-directional |
|DP, Loop Start | |
|Basic, DTMF and |Bi-directional |
|DP, Ground Start| |
--------------------------------------
-------------------------------------- | トランクタイプ| 指示| | | (w. r. t. ゲートウェイ) | -------------------------------------- |そして基礎、DTMF。|双方向| |DP、輪の始め| | |そして基礎、DTMF。|双方向| |DP、地面始め| | --------------------------------------
1.2.4. "DO" Package
1.2.4. 「してください」というパッケージ
The "DO" package is used for analog FXO loop-start and ground-start analog trunks as indicated in the following table.
「してください」というパッケージは以下のテーブルにみられるようにアナログのFXO輪始めと地面スタートのアナログのトランクスに使用されます。
Table 4 FXO analog PBX Trunks
テーブル4 FXOアナログPBX Trunks
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|FXO, loop-start|Bi-directional |
|FXO, ground- |Bi-directional |
| start | |
--------------------------------------
-------------------------------------- | トランクタイプ| 指示| | | (w. r. t. ゲートウェイ) | -------------------------------------- |FXO、輪始め|双方向| |FXO、地面|双方向| | 始め| | --------------------------------------
1.2.5. "MD" Package
1.2.5. 「MD」パッケージ
The MD package provides support for North American MF Feature Group D EANA and EAIN [3], allowing the Media Gateway to be at either the end office, the carrier or the tandem side of the circuit. The CAS Signaling Type column of the following tables is intended to indicate signaling differences that are of common interest to both the Call Agent and Media Gateway. Configuration information that is only of interest to the Media Gateway is not identified.
MDパッケージは北米のMF Feature Group D EANAとEAIN[3]のサポートを提供します、メディアゲートウェイが端局、キャリヤーかサーキットの2人乗り自転車端のどちらかにあるのを許容して。 以下のテーブルに関するCAS Signaling TypeコラムがCallエージェントとメディアゲートウェイの両方への共通の利益のものであるシグナリング差を示すことを意図します。 メディアゲートウェイだけに興味がある設定情報は特定されません。
Foster Informational [Page 6] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[6ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Table 4 Feature Group D MF Trunks Supported
テーブル4 mfトランクスが支持した特徴グループD
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|FGD, EANA |Outgoing (End Office to Carrier) |
|FGD, EANA |Incoming (Carrier to End Office) |
|FGD, EAIN |Outgoing (End Office to Carrier) |
|FGD, EAIN |Incoming (Carrier to End Office) |
--------------------------------------------------
-------------------------------------------------- | トランクタイプ| 指示(w. r. t. ゲートウェイ)| -------------------------------------------------- |FGD、EANA|外向的です(キャリヤーへの端局)。| |FGD、EANA|入来(端局へのキャリヤー)| |FGD、EAIN|外向的です(キャリヤーへの端局)。| |FGD、EAIN|入来(端局へのキャリヤー)| --------------------------------------------------
Note that EANA and EAIN signaling may be requested on the same trunk on a call-by-call basis.
EANAとEAINシグナリングが同じトランクの上に呼び出しごとのベースで要求されているかもしれないことに注意してください。
1.2.6. "MO" Package
1.2.6. 「MO」パッケージ
The "MO" package is used for FGD Operator Services Signaling, outgoing trunks only. Feature Group C can also be supported by the same interface.
「MO」パッケージはFGDオペレータサービスシグナリング、一方向中継局だけに使用されます。 また、同じインタフェースは特徴Group Cを支持できます。
2.0. Event Packages
2.0. イベントパッケージ
This section defines the event packages. The terms "signal" and
"event" are used to differentiate a command from a Call Agent to a
Media Gateway ("signal") from an "event" that is detected by the
Media Gateway and then is "Notified" to the Call Agent.
このセクションはイベントパッケージを定義します。 用語「信号」と「出来事」は、メディアゲートウェイによって検出されて、次に「通知される」「出来事」からCallエージェントまでCallエージェントからメディアゲートウェイ(「信号」)までのコマンドを微分するのに使用されます。
Each package definition includes a package name, plus the event name codes and the definitions for each of the events in the package. In the tables of events/signals for each package, there are five columns:
それぞれのパッケージ定義はパッケージにおける、それぞれの出来事のためにパッケージ名、イベントネーム・コード、および定義を含んでいます。 各パッケージのための出来事/信号のテーブルに、5つのコラムがあります:
* Code The package unique event code used for the
event/signal.
* ユニークなイベントコードが出来事/信号に使用したパッケージをコード化してください。
* Description A short description of the event/signal.
* 出来事/信号の記述のA短い記述。
* Event 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「x」は出来事がCallエージェントによるRequestedであるかもしれないならこのコラムに現れます。 あるいはまた、以下のシンボルの1つ以上は現れるかもしれません:
- "P" indicating that the event is persistent,
- 出来事がしつこいのを示す「P」
- "S" indicating that the event is an event-state that may be
audited,
- 出来事が監査されるかもしれないイベント状態であることを示す「S」
Foster Informational [Page 7] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[7ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
- "C" indicating that the event/signal may be detected/applied
on a connection. If "C" is associated with an event, this
refers to an event that can occur on the media stream.
However, "C" may also be associated with a signal (in the
signal column), the signal can be requested to sent over a
connection.
- 出来事/信号が接続のときに検出されるか、または適用されるかもしれないのを示す「C。」 「C」が出来事に関連しているなら、これはメディアの流れのときに起こることができる出来事を示します。 しかしながら、また、「C」も信号(信号コラムの)に関連しているかもしれない、接続の上に送られるのに信号を要求できます。
Note that the intent of being able to audit state ("S") in an event
in the following packages is to answer one of the two questions:
以下のパッケージにおける出来事で状態(「S」)を監査できる意図が2つの質問の1つに答えることであることに注意してください:
1. Has a call been initiated on this line/trunk? For example in
the packages that follow, call setup initiation is indicated by
either a "sup" event or an "hd" (FXS - "BL" packages) or in the
case of the "DO" package below (FXO), by the "rg" event so that
those events have an "S" in the event column indicating that they
are auditable.
1. 呼び出しはこの線/トランクの上に開始されましたか? 例えば、従うパッケージの中では、呼び出しセットアップ開始は「一口」出来事か"hd"(FXS--"BL"パッケージ)のどちらかか(FXO)の下の「してください」というパッケージの場合で示されます、"rg"出来事でそれらの出来事には、それらが監査可能であることを示すイベントコラムの「S」があります。
2. The other question of interest is to know whether the telephony
leg of the call is in the idle state so that a new call can be
initiated. This is indicate by the "rlc" (release complete)
event-state for packages that have that event.
2. 興味があるもう片方の質問は呼び出しの電話行程が新しい呼び出しを開始できるように活動していない状態にあるかを知ることです。 これはその出来事を持っているパッケージのために"rlc"で(リリース完全)のイベント状態を示すことです。
* Signal If nothing appears in this column then this event
cannot be signaled on request by the Call Agent.
Otherwise, one of the following symbols is provided
to identify the type of signal:
* Callエージェントは要求に応じて、何も次に、このコラムのこの出来事に現れないという信号Ifに合図できません。 さもなければ、信号のタイプを特定するために以下のシンボルの1つを提供します:
- "OO" On/Off signal. The signal is turned on until commanded
by the Call Agent to turn it off, and vice versa.
- "TO" Timeout signal. The signal lasts for a given duration
unless it is superseded by a new signal or terminated on
detection of an event. Default time-out values are
supplied. A value of zero indicates that the time-out
period is infinite. The provisioning process may alter
these default values.
- "BR" Brief signal. The signal has a short, known duration.
- "OO"On/オフな信号。 それをオフにするとCallエージェントによって命令されるまで、信号はつけられています、そして、逆もまた同様です。 - "TO"Timeoutは合図します。 それが新しい信号によって取って代わられるか、または出来事の検出のときに終えられない場合、信号は与えられた持続時間のためにもちます。 デフォルトタイムアウト値を供給します。 ゼロの値は、タイムアウトの期間が無限であることを示します。 食糧を供給することの過程はこれらのデフォルト値を変更するかもしれません。 - "BR"Briefは合図します。 信号には、短くて、知られている持続時間があります。
* Additional info Provides additional information about the
event/signal, e.g., the default duration of TO signals.
* 出来事/信号に関する追加インフォメーションProvides追加情報、例えば、TO信号のデフォルト持続時間。
Unless otherwise stated, all of the events/signals are detected/applied on endpoints and audio generated by them is not forwarded on any connection the endpoint may have. Audio generated by events/signals that are detected/applied on a connection will however be forwarded on the associated connection irrespective of the connection mode.
別の方法で述べられない場合、出来事/信号のすべてが、終点で検出されるか、または適用されます、そして、それらによって発生したオーディオは終点にはあるどんな接続のときにも進められません。 しかしながら、関連接続のときに接続モードの如何にかかわらず接続のときに検出されるか、または適用される出来事/信号で発生するオーディオを進めるでしょう。
Foster Informational [Page 8] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[8ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
2.1. Events and Signals for the "MS" package:
2.1. 「さん」パッケージのための出来事とSignals:
The following codes are used to identify events and signals for the "MS" package:
以下のコードは「さん」パッケージのための出来事と信号を特定するのに使用されます:
Table 5 "MS" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
| bl |Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
|inf |Information Digits| x | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signal completes |
| | | | |out-pulsing |
|sus |Suspend call | P | BR | |
---------------------------------------------------------------------
テーブル5「MS」パッケージ出来事と信号--------------------------------------------------------------------- |コード|記述|出来事|信号|追加インフォメーション| |---------------------------------------------------------------------| |ans|呼び出し答え| P| Br| | | bl|ブロック| S| Br| | | bz|話中音| - | to|30秒のタイムアウト=| |inf|情報ケタ| x| - | | | oc|操作完全です。| x| - | | | of|操作は失敗します。| x| - | | |rel|リリース呼び出し| P| Br| | |res|履歴書呼び出し| P| Br| | |rlc|リリース完全です。| P、S| Br| | | ro|追加注文トーン| - | to|30秒のタイムアウト=| | rt|Ringbackトーン| - | to|180秒のタイムアウト=| |一口|セットアップに電話をしてください。| P、S| to|タイムアウト、信号が完成するいつ| | | | | |出かけている脈打つこと| |sus|呼び出しを中断させてください。| P| Br| | ---------------------------------------------------------------------
Foster Informational [Page 9] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[9ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
2.2. Events and Signals for the "DT" package:
2.2. "DT"パッケージのための出来事とSignals:
The following codes are used to identify events and signals for the "DT" package:
以下のコードは"DT"パッケージのための出来事と信号を特定するのに使用されます:
Table 6 "DT" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
| bl |Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
| dl |Dial tone | - | TO |Time-out = 16 seconds |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signals completed|
| | | | |out-pulsing |
|sus |Suspend call | P | BR | |
---------------------------------------------------------------------
テーブル6"DT"パッケージ出来事と信号--------------------------------------------------------------------- |コード|記述|出来事|信号|追加インフォメーション| |---------------------------------------------------------------------| |ans|呼び出し答え| P| Br| | | bl|ブロック| S| Br| | | bz|話中音| - | to|30秒のタイムアウト=| | dl|ダイヤルトーン| - | to|16秒のタイムアウト=| | oc|操作完全です。| x| - | | | of|操作は失敗します。| x| - | | |rel|リリース呼び出し| P| Br| | |res|履歴書呼び出し| P| Br| | |rlc|リリース完全です。| P、S| Br| | | ro|追加注文トーン| - | to|30秒のタイムアウト=| | rt|Ringbackトーン| - | to|180秒のタイムアウト=| |一口|セットアップに電話をしてください。| P、S| to|タイムアウト、完成されて、いつが合図するか。| | | | | |出かけている脈打つこと| |sus|呼び出しを中断させてください。| P| Br| | ---------------------------------------------------------------------
2.3. Events and Signals for the "BL" package (Basic PBX)
2.3. "BL"パッケージのための出来事とSignals(基本的なPBX)
The following codes are used to identify events and signals for the "BL" package. This package looks very much like a simplified line package:
以下のコードは、"BL"パッケージのための出来事と信号を特定するのに使用されます。 このパッケージは簡易型の線パッケージにたいへん似ています:
Table 7 "BL" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
| bz |Busy tone | - | TO |Time-out = 30 seconds |
| dl |Dial tone | - | TO |Time-out = 16 seconds |
| hd |Off-hook | P,S | - | |
| hf |Flash hook | P | - | |
| hu |On-hook | P,S | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
| rel|Release | - | BR | |
| rg |Ringing | - | TO |Time-out = 180 seconds |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | C,TO |Time-out = 180 seconds |
---------------------------------------------------------------------
テーブル7"BL"パッケージ出来事と信号--------------------------------------------------------------------- |コード|記述|出来事|信号|追加インフォメーション| |---------------------------------------------------------------------| | bz|話中音| - | to|30秒のタイムアウト=| | dl|ダイヤルトーン| - | to|16秒のタイムアウト=| | hd|オフフック| P、S| - | | | hf|フラッシュフック| P| - | | | hu|フック| P、S| - | | | oc|操作完全です。| x| - | | | of|操作は失敗します。| x| - | | | rel|リリース| - | Br| | | rg|鳴ります。| - | to|180秒のタイムアウト=| | ro|追加注文トーン| - | to|30秒のタイムアウト=| | rt|Ringbackトーン| - | C|180秒のタイムアウト=| ---------------------------------------------------------------------
Foster Informational [Page 10] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[10ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
2.4. Events and Signals for the "DO" package:
2.4. 「してください」というパッケージのための出来事とSignals:
The following codes are used to identify events and signals for the "DO" package:
以下のコードは「してください」というパッケージのための出来事と信号を特定するのに使用されます:
Table 8 "DO" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
| ci |Caller id | x | - | |
| hd |Offhook | - | BR | |
| hf |Hook flash | - | BR | |
| hu |Onhook | - | BR | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release call | P | - | |
| rg |Ringing | P,S | - | |
|rlc |Release complete | P,S | - | |
|sup |Call Setup | - | TO |Time-out when signal completes |
| | | | | out-pulsing |
---------------------------------------------------------------------
「してください」というテーブル8は出来事と信号をパッケージします。--------------------------------------------------------------------- |コード|記述|出来事|信号|追加インフォメーション| |---------------------------------------------------------------------| | ci|訪問者イド| x| - | | | hd|オフフック| - | Br| | | hf|フックフラッシュ| - | Br| | | hu|Onhook| - | Br| | | oc|操作完全です。| x| - | | | of|操作は失敗します。| x| - | | |rel|リリース呼び出し| P| - | | | rg|鳴ります。| P、S| - | | |rlc|リリース完全です。| P、S| - | | |一口|セットアップに電話をしてください。| - | to|タイムアウト、信号が完成するいつ| | | | | | 出かけている脈打つこと| ---------------------------------------------------------------------
Foster Informational [Page 11] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[11ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
2.5. Events and Signals for the "MD" package:
2.5. 「MD」パッケージのための出来事とSignals:
The following codes are used to identify events and signals for the "MD" package.
以下のコードは、「MD」パッケージのための出来事と信号を特定するのに使用されます。
Table 9 "MD" Package Events and Signals
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer | P | BR | |
|awk |Acknowledge wink | P | BR | |
| bl |Call Block | S | BR | |
| bz |Busy tone | - | TO |Time-out = 30 seconds |
|cwk |Continue Wink | - | BR | |
|inf |Information Digits| x | TO |Time-out when signals completed|
| | | | | out-pulsing |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|rel |Release Call | P | BR | |
|res |Resume call | P | BR | |
|rlc |Release complete | P,S | BR | |
| ro |Reorder tone | - | TO |Time-out = 30 seconds |
| rt |Ringback tone | - | TO |Time-out = 180 seconds |
|sup |Call Setup | P,S | TO |Time-out when signals completed|
| | | | | out-pulsing |
|sus |Suspend call | P | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------
テーブル9「MD」パッケージ出来事と信号--------------------------------------------------------------------- |コード|記述|出来事|信号|追加インフォメーション| |---------------------------------------------------------------------| |ans|呼び出し答え| P| Br| | |awk|ウインクを承諾してください。| P| Br| | | bl|コール・ブロック| S| Br| | | bz|話中音| - | to|30秒のタイムアウト=| |cwk|ウインクを続けてください。| - | Br| | |inf|情報ケタ| x| to|タイムアウト、完成されて、いつが合図するか。| | | | | | 出かけている脈打つこと| | oc|操作完全です。| x| - | | | of|操作は失敗します。| x| - | | |rel|リリース呼び出し| P| Br| | |res|履歴書呼び出し| P| Br| | |rlc|リリース完全です。| P、S| Br| | | ro|追加注文トーン| - | to|30秒のタイムアウト=| | rt|Ringbackトーン| - | to|180秒のタイムアウト=| |一口|セットアップに電話をしてください。| P、S| to|タイムアウト、完成されて、いつが合図するか。| | | | | | 出かけている脈打つこと| |sus|呼び出しを中断させてください。| P| Br| | |swk|スタートウインク| x| - | | ---------------------------------------------------------------------
Foster Informational [Page 12] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[12ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
2.6. Events and Signals for the "MO" package:
2.6. 「MO」パッケージのための出来事とSignals:
The following codes are used to identify events and signals for the "MO" package.
以下のコードは、「MO」パッケージのための出来事と信号を特定するのに使用されます。
Table 10 "MO" Package Events and Signals
テーブル10「MO」パッケージ出来事と信号
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer !Note | P | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|orbk|Operator Ringback | x | - | |
|rbz |Reverse make busy | P,S | - | |
|rcl |Operator Recall | - | BR | |
|rel |Release Call | P | BR | |
|res |Resume Call | - | BR | |
|rlc |Release complete | P,S | BR | |
|sup |Call Setup | - | TO | |
|sus |Suspend Call | - | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------
!Note: There is no indication that the operator answered the call.
The "ans" event is an indication that off-hook was received
from the far end which simply indicates that the destination
address was received properly and the calling number is in the
process of being outpulsed.
--------------------------------------------------------------------- |コード|記述|出来事|信号|追加インフォメーション| |---------------------------------------------------------------------| |ans|呼び出し答え!注意| P| - | | | oc|操作完全です。| x| - | | | of|操作は失敗します。| x| - | | |orbk|オペレータRingback| x| - | | |rbz|忙しい状態で造を逆にしてください。| P、S| - | | |rcl|オペレータリコール| - | Br| | |rel|リリース呼び出し| P| Br| | |res|履歴書呼び出し| - | Br| | |rlc|リリース完全です。| P、S| Br| | |一口|セットアップに電話をしてください。| - | to| | |sus|呼び出しを中断させてください。| - | Br| | |swk|スタートウインク| x| - | | --------------------------------------------------------------------- 以下に注意してください。 オペレータが電話口に出たという指示が全くありません。 "ans"出来事は送付先アドレスが適切に受け取られたのを単に示す遠端と数の途中にある「外-律動的に送」られる呼ぶのからオフフックを受け取ったという指示です。
2.7. Event and Signal Descriptions
2.7. 出来事と信号記述
The following provides a list of the event and signal descriptions.
以下は出来事と信号記述のリストを提供します。
The event/signal name appears in parenthesis followed by the corresponding Event + Signal attribute code plus a list of the packages in which the event/signal occurs.
出来事/信号名は対応するEvent+信号属性コードと出来事/信号が発生するパッケージのリストがあとに続いた挿入句に載っています。
Call answer (ans; P + BR; DT,MD,MS,MO): Off-hook signal normally indicates that the call has been answered and that cut-through has been established. The exception is the "MO" package where it simply indicates that off-hook was received and the calling number is in the process of being sent (i.e., there is no event available to indicate that the operator answered the call for operator services signaling).
答え(ans; P+BR; DT、MD(MS)(MO))に電話をしてください: 通常、オフフック信号は、呼び出しが答えられて、深く切られたそれが設立されたのを示します。 例外は、それが、オフフックが受け取られたのを単に示す「MO」パッケージと数の途中にある送られる呼ぶことです(すなわち、オペレータのための呼び出しに答えたオペレータがシグナリングを修理するのを示すために利用可能などんな出来事もありません)。
Acknowledgement Wink (awk; P + BR; MD): This event is only applicable to the "md" package. It provides an indication that all digits have been received correctly. In an outgoing trunk, the event is requested and when received indicates that the connecting switch
承認ウインク(awk; P+Br; MD): この出来事は単に「Md」パッケージに適切です。 それは正しくすべてのケタを受け取ったという指示を提供します。 一方向中継局では、出来事は要求されています、そして、受け取られたいつが接続が切り替わるのを示すか。
Foster Informational [Page 13] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[13ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
received all of the addressing information. On an originating trunk, this signal is sent to inform the other end that all addressing information has been received. If the Call Agent is providing a transit application for example, in which incoming and outgoing trunks are both EANA trunks, then after acknowledgement wink is received from the terminating trunk, it is passed to the originating side so that the originating side knows that addressing has passed to the destination switch.
アドレス指定情報のすべてを受けました。 由来しているトランクに、すべてのアドレス指定情報を受け取ったもう一方の端のときに知らせるためにこの信号を送ります。 Callエージェントが例えば送受信のトランクスが両方のEANAトランクスであるトランジット利用を提供しているなら終わりトランクから承認ウインクを受けた後に由来側にそれを向かわせるので、由来側は、アドレシングが目的地スイッチに終わったのを知っています。
Call Block (bl; S + BR; DT,MS,MD): A steady off-hook signal applied to one-way incoming trunks to indicate that no further calls will be accepted. When "bl" is used as a signal then the "rel" signal is used to release the blocking condition.
ブロック(bl; S+Br; DT、MS(MD))に電話をしてください: しっかりとしているオフフック信号は、さらなる呼び出しが全く受け入れられないのを示すのに片道着信トランクに当てはまりました。 "bl"がその時信号として使用されるとき、"rel"信号は、ブロッキング状態をリリースするのに使用されます。
A Call Agent should only request the "bl" event in a case where it
knows that this is a one-way outgoing trunk, and it should never see
an incoming call-setup request ("sup" event). As such if "bl" is
requested as an event, then "sup" is suppressed as a persistent
event.
Callエージェントはそれがこれが片道一方向中継局であることを知っている場合で"bl"出来事を要求するだけであるべきです、そして、それは入って来る呼び出しセットアップが(「一口」出来事)を要求するのを決して見るべきではありません。 そういうものとして、"bl"が出来事として要求されるなら、「一口」はしつこい出来事として抑圧されます。
Busy tone (bz ; - + TO; BL,DT,MD,MS): Refer to ITU E.180. The definition of the tone is defined by the national characteristics and may be established via provisioning. Station Busy is defined in GR- 506-CORE - LSSGR, SIGNALING, Section 17.2.6. as 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.
話中音(bz; --+ TO;BL、DT、MD、MS): ITU E.180を参照してください。 トーンの定義は、民族的特徴によって定義されて、食糧を供給することを通して確立されるかもしれません。 駅のBusyはGR506-COREで定義されます--LSSGR、SIGNALING、セクション17.2.6、2の組み合わせとして、西暦は、-21dBmの結合したレベルを与えるために480と620の頻度でそれぞれ-24dBmのHertzとレベルに調子を変えさせます。 繰り返して、駅のBusy利根へのリズムは0.5秒までに以下でオフさ0.5秒です。
Caller Id (ci(time, number, name); x + -; DO): See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031. Each of the three fields are optional, however each of the commas will always be included.
訪問者Id、(ci(時間、数、名前);、x+、-、;、してください )、: TR-NWT-001188、GR30コア、およびTR-NWT-000031を見てください。 それぞれの3つの分野が任意である、しかしながら、それぞれのコンマはいつも含まれるでしょう。
The time parameter is coded as "MM/DD/HH/MM", where MM is a two-
digit value for Month between 01 and 12, DD is a two-digit value
for Day between 1 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.
時間パラメタは、「mm/DD/HH/mm」(mmは01と12の間の月のための2ケタ価値であり、DDは1〜31日目のための2ケタの値であり、時間と分は現地時間の軍、例えば、00に従ってコード化された2ケタの値である)が真夜中であり、01が午前1時であり、13が午後1時ので、コード化されます。
The number parameter is coded as an ASCII character string of
decimal digits that identify the calling line number. White
spaces are permitted if the string is quoted, however they
will be ignored.
数のパラメタは呼ぶ行番号を特定する10進数字のASCII文字列としてコード化されます。 ストリングが引用されるなら、余白は受入れられて、しかしながら、それらは無視されるでしょう。
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.
呼ぶことを特定する一連のASCII文字が名前を裏打ちするとき、名前パラメタはコード化されます。 ストリングが引用されるなら、余白は受入れられます。
Foster Informational [Page 14] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[14ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
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. The following example illustrates the use of the caller-id event:
数か名前欄の「P」は個人的な数か名前を示すのに使用されます、そして、「O」は、入手できない数か名前を示すのに使用されます。 以下の例は訪問者イドイベントの使用を例証します:
O: ci(10/14/17/26, "555 1212", somename)
O: ci(10/14/17/26、「555、1212、インチsomename)
Continue Wink (cwk ; - + BR; MD): This signal is only applicable to the "md" package. It provides an indication that digits sent have been accepted, and further digits must be sent in order to process the call. For example, when using FGD EAIN signaling, this would correspond to sending a wink after the country access code had been received to indicate readiness to receive identification and address fields.
ウインク(cwk; --+ Br;MD)を続けてください: この信号は単に「Md」パッケージに適切です。 それは送られたケタを受け入れて、呼び出しを処理するためにさらなるケタを送らなければならないという指示を提供します。 FGD EAINシグナリングを使用するとき、例えば、これは識別とアドレス・フィールドを受ける準備を示すために国のアクセスコードを受け取った後にウインクを送ると対応しているでしょう。
Dial-tone (dl ; - + TO; BL,DT): Refer to ITU E.180. The definition of the tone is defined by the national characteristics and may be established via provisioning. In GR-506-CORE - LSSGR, SIGNALING, Section 17.2.1, sial Tone is defined as 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. It is considered an error to try and play dial-tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook).
ダイヤルトーン、(dl;、--、+、;、BL、DT)、: ITU E.180を参照してください。 トーンの定義は、民族的特徴によって定義されて、食糧を供給することを通して確立されるかもしれません。 中、GR-506-CORE--LSSGR、SIGNALING、セクション17.2.1、sial利根は-13dBmの440の350の頻度、Hertz、およびレベルで2つの連続した交流トーンの組み合わせと定義されて、それぞれ-10dBmの結合したレベルを与えます。 オンである電話の試みる誤りとプレーダイヤルトーンが掛けられると考えて、そのような試みをするとき(エラーコード402--フックの上の電話)、その結果、誤りを返すべきです。
Information Digits (inf(<inf-digits>); x + TO; MS,MD): On an outgoing
call ("md" package only) it is used as a signal to out-pulse the
address information when doing overlapped sending.
情報Digits(inf(<inf-ケタ>); x+TO; MS(MD)): 発信電話(「Md」パッケージ専用)のときに、それは、するのがいつ発信を重ね合わせたかというアドレス情報をアウトで律動的に送るのに信号として使用されます。
On an incoming call it is used as an event to indicate that an MF digit string has been received. In this case, <inf-digits> are all of the digits accumulated up to and including the digit delimiters ST, ST', ST'', ST'''. Multiple sequences of digits ending with one of the ST digits may be passed in a single "inf" event. (Note that K0 is the same as KP, K1 is sometimes referred to as KP' etc. Similarly S0 is the same as ST, S1 is the same as ST' and so on.
かかってきた電話のときに、それは、MFケタストリングが受け取られたのを示すのに出来事として使用されます。 「'この場合、ケタのすべてがケタデリミタSTを含めて蓄積したという<のinfケタの>によることです、ST'、ST」、ST、」、' STケタの1つで終わるケタの複数の系列が単一の"inf"出来事で通過されるかもしれません。 ('K0がKPと同じであるというメモ、K1は時々KPと呼ばれた'などSimilarly S0がSTと同じである、S1はSTと同じである'、などです。
The value of <inf-digits> is a comma separated list of MF digits: MF1, MF2, ..., MFn
<inf-ケタ>の値はMFケタのコンマの切り離されたリストです: MF1、MF2…, MFn
where each of MFi will be one of the following MF digit symbols:
それぞれのMFiが以下のMFケタシンボルの1つになるところ:
Foster Informational [Page 15] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[15ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Table 11 MF Digit Symbols
テーブル11 mfケタシンボル
-------------------------
| Symbol |MF digit |
| 0 | MF 0 |
| 1 | MF 1 |
| 2 | MF 2 |
| 3 | MF 3 |
| 4 | MF 4 |
| 5 | MF 5 |
| 6 | MF 6 |
| 7 | MF 7 |
| 8 | MF 8 |
| 9 | MF 9 |
| K0 | MF K0 or KP |
| K1 | MF K1 |
| K2 | MF K2 |
| S0 | MF S0 or ST |
| S1 | MF S1 or ST' |
| S2 | MF S2 or ST'' |
| S3 | MF S3 or ST'''|
--------------------------
------------------------- | シンボル|MFケタ| | 0 | mf0| | 1 | mf1| | 2 | mf2| | 3 | mf3| | 4 | mf4| | 5 | mf5| | 6 | mf6| | 7 | mf7| | 8 | mf8| | 9 | mf9| | K0| mf K0かKP| | K1| mf K1| | ケーツー| MFケーツー| | S0| 第またはmf S0。| | S1| または、mf'S1、第'| | S2| または、「mf S2、第」| | S3| または、'、「mf S3、第」、'| --------------------------
Thus, an example signal or event might look like:
したがって、例の信号か出来事に似るかもしれません:
inf(k0, 5,5,5,1,2,3,4, s0)
inf(k0、5、5、5、1、2、3、4、s0)
An example where the inter-digit timer expired after the 5,5,5 would appear as follows:
趾間部タイマが5、5、5時以降期限が切れた例は以下の通りに見えるでしょう:
inf(k0, 5,5,5)
inf(k0、5、5、5)
Operation Complete (oc ; x + -; all): The operation complete event is generated when the gateway was asked to apply one or several signals of type TO on the endpoint, and one or more of those signals completed without being stopped by the detection of a requested or persistent event such as setup. The completion report may carry as a parameter the name of the signal that came to the end of its live time, as in:
操作Complete、(oc、; x+、-、; すべて)、: ゲートウェイが終点のタイプTOに関する1かいくつかの信号を適用するように頼まれたとき、操作の完全な出来事は発生しました、そして、立ち寄られないで、それらの信号の1つ以上はセットアップなどの要求されたかしつこい出来事の検出を終了しました。 完成レポートはパラメタとして以下のようにライブ時間の終わりに来た信号の名前を載せるかもしれません。
O: ms/oc(ms/sup)
O: ms/oc(ms/一口)
or
または
O: bl/oc(bl/rg)
O: bl/oc(bl/rg)
When the operation complete event is requested, it cannot be parameterized with any event parameters.
操作の完全な出来事が要求されているとき、どんなイベントパラメタでもそれをparameterizedされることができません。
Foster Informational [Page 16] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[16ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Note that when requested at the same a signal for "sup" (out-pulsing - a TO event), the operation complete event will indicate when out- pulsing is complete.
同じa信号で要求されたら、「一口」(出かけている脈打つこと--TO出来事)ゆえそれに注意してください、と出かけている脈打つのが完全であるときに、操作の完全な出来事は示すでしょう。
Operation failure (of; x + -; all): In general, the operation failure event may be generated when the endpoint was asked to apply one or several signals of type TO on the endpoint, and one or more of those signals failed prior to timing out. The completion report may carry as a parameter the name of the signal that failed, as in:
操作失敗、(; x+、-、; すべて)、: 終点が終点のタイプTOに関する1かいくつかの信号を適用するように頼まれたとき、一般に、操作失敗出来事は発生したかもしれません、そして、それらの信号の1つ以上はタイミングの前に外で失敗しました。 完成レポートはパラメタとして以下のように失敗した信号の名前を載せるかもしれません。
O: ms/of(ms/sup)
O: /をmsします。(ms/一口)
or
または
O: bl/of(bl/rg)
O: /をblします。(bl/rg)
When the operation failure event is requested, it cannot be parameterized with any event parameters.
操作失敗出来事が要求されているとき、どんなイベントパラメタでもそれをparameterizedされることができません。
Operator ringback (orbk; x + -; MO): The description of the signaling
MF CAS signaling that results in this event is describe in the
appendix of TR-NPL-000258 [3]. In brief, it is normally a wink-on
signal which may or may not be followed by an MF tone. This event
will be generated when the operator service requests that the calling
party be alerted ("mo" package only).
オペレータringback、(orbk、; x+、-、;、MO)、: この出来事をもたらすシグナリングMF CASシグナリングの記述はTR-NPL-000258の付録で[3]について説明することです。 要するに、通常、それはMFトーンがいうことになるかもしれないウインクオン信号です。 オペレータサービスが、起呼側が警告されるよう(「折り」パッケージ専用)要求すると、この出来事は発生するでしょう。
Reverse make busy (rbz; P + -; MO): This event corresponds to a
"blocking" (off-hook) generated by the other end of the one-way
operator services trunk ("mo" package). It has the same semantics as
of the "bl" event in other packages.
忙しい状態で造を逆にしてください、(rbz、; P+、-、;、MO)、: この出来事は片道オペレータのもう一方の端までに発生する「ブロッキング」(オフフック)サービストランク(「折り」パッケージ)に対応しています。 それには、他のパッケージにおける"bl"出来事現在、同じ意味論があります。
Operator recall (rcl; - + BR; MO): This signal may be applied to invoke operator recall, e.g., due to customer hook-flash to bring the operator back.
オペレータリコール(rcl; --+ BR;MO): この信号は、例えば、オペレータを返す顧客フックフラッシュのためオペレータリコールを呼び出すために適用されるかもしれません。
Release call (rel; P,S + BR; BL,DT,MD,MO,MS,DO): A "rel" signal sent by the Call Agent to the Media Gateway is a request to release all of the resources associated with the telephony leg of the call. This may also result in an off-hook signal being sent when appropriate. As a result of an "rel" signal, the gateway will respond with an "rcl" event, whenever the resources have been released. Releasing resources associated with the telephony leg of the call does not affect existing connections (network legs). It's up to the Call Agent to send the appropriate delete connection commands in order to release any network connections to that endpoint.
要求(BL(DT、MD(MO)(MS))がするrel(P、S+BR))をリリースしてください: Callエージェントによってメディアゲートウェイに送られた"rel"信号は呼び出しの電話行程に関連しているリソースのすべてをリリースするという要求です。 また、これは適切であるときに送られるオフフック信号をもたらすかもしれません。 "rel"信号の結果、ゲートウェイは"rcl"出来事で応じるでしょう、リソースが発表されたときはいつも。 呼び出しの電話行程に関連しているリソースを発表するのは既存の接続(ネットワーク脚)に影響しません。 送るCallエージェントまで、適切がその終点にどんなネットワーク接続も釈放するために接続命令を削除するということです。
Foster Informational [Page 17] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[17ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
In the case of the FXS ("BL") package, the "rel" signal is used to
provide a tip-ground release for ground-start trunks. In the case of
loop-start trunks, requesting to play this signal has no effect.
FXS("BL")パッケージの場合では、"rel"信号は、チップ地面リリースを地面スタートトランクスに供給するのに使用されます。 輪スタートトランクスの場合では、この信号を使う要求は効き目がありません。
The Media Gateway generates a "release call" event whenever a call is released as a result of an on-hook event from an originating end of a call (normal release) or due to abnormal event that resulted in releasing the call. The event may be parameterized with one of the following cause codes indicating the reason for the release:
呼び出しが要求(通常のリリース)の由来している終わりか呼び出しをリリースするのに結果として生じた異常な出来事のためフックにおける出来事の結果、リリースされるときはいつも、メディアゲートウェイは「リリース呼び出し」出来事を発生させます。 以下の原因コードのひとりがリリースの理由を示していて、出来事はparameterizedされるかもしれません:
Table 12 Release Reason Codes
-----------------------------------------------------------------
|Cause Code |Reason |
|-----------------------------------------------------------------
| 0 |Normal release |
| 44 |Requested channel/circuit not available |
| |(glare or incoming seizure detected during call |
| | setup) |
| 111 |Protocol/signaling error, unspecified (e.g. timeout) |
-----------------------------------------------------------------
テーブル12 リリース理由コード----------------------------------------------------------------- |原因コード|理由| |----------------------------------------------------------------- | 0 |通常のリリース| | 44 |利用可能でない要求されたチャンネル/サーキット| | |(呼び出しの間に検出されたギラギラと眩しい光か入って来る捕獲| | | セットアップ) | | 111 |不特定(例えば、タイムアウト)のプロトコル/シグナリング誤り| -----------------------------------------------------------------
Note that a "rel" event with reason code "0" indicating normal release (due to an incoming on-hook) will only be "notified" by a gateway where a call origination occurred. This behavior follows the rule that when an originator releases the call, all resources may be released. The corresponding event for on-hook on the terminating end of a call is the "sus" event which only indicates hook-status and does not result in any resources being released. It is always up to the Call Agent to release the call (by sending the "rel" signal) for the terminating end of a call.
理由コードがある"rel"出来事その「通常のリリース(入って来るオンフックによる)が呼び出し創作が起こったゲートウェイによって「通知されるだけであること」を示す0インチ」に注意してください。 この振舞いは創始者が呼び出しをリリースするとき、すべてのリソースが発表されるかもしれないという規則に従います。 オンフックのための呼び出しの終わり終わりにおける対応する出来事はフック状態を示すだけであり、発表されるどんなリソースももたらさない"sus"出来事です。 それはいつも呼び出しの終わり終わりの要求("rel"信号を送るのによる)をリリースするCallエージェント次第です。
For FXO ground-start case ("DO" package), the Media Gateway generates
a "release call" event whenever a call is released as a result of a
tip-ground release event from the far end.
FXO地面スタートケース(「してください」というパッケージ)には、呼び出しが遠端からのチップ地面リリースイベントの結果、リリースされるときはいつも、メディアゲートウェイは「リリース呼び出し」出来事を発生させます。
Resume call (res ; P + BR; DT,MD,MS,MO): This indicates that the
called party resumed the call, i.e., the party went off-hook after a
previous suspend ("sus") but before the originating switch released
("rel") the trunk. The "sus" and "res" events/signals are used to
propagate on-hook and off-hook events without releasing the resources
associated with the call. In all but the operator services case
("MO" package), these events would normally be propagated from the
terminating to the originating end (i.e., requested as events from
the terminating end of the call and sent to the gateway as signals to
a gateway on the originating side of the call).
呼び出し(res; P+BR; DT、MD(MS)(MO))を再開してください: これは、被呼者が呼び出しを再開して、すなわち、パーティーが行ったのを示します。aの後に前のオフフックは、("sus")を中断させましたが、由来しているスイッチの前でトランクを解放しました("rel")。 "sus"と"res"出来事/信号は、呼び出しに関連しているリソースを発表しないでオンフックとオフフック出来事を伝播するのに使用されます。 サービスがケースに入れるオペレータ(「MO」パッケージ)を除いた皆では、通常、これらの出来事は終わりから由来している終わり(すなわち、出来事として呼び出しの終わり終わりから要求して、呼び出し由来側の上のゲートウェイへの信号としてゲートウェイに送る)まで伝播されるでしょう。
Foster Informational [Page 18] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[18ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
However, it is up to the Call Agent to decide whether it wants to do "suspend"/"resume" processing. If it doesn't, when it receives a "sup" event from the terminating end of the call it can simply go ahead and tear down the call immediately (send "rel" and delete connections to the endpoints on gateways at both originating and terminating end of the call).
しかしながら、処理するのを「中断する」か、またはそれが、「再開したがっているかどうか」決めるのは、Callエージェント次第です。 そうしないなら、すぐに呼び出しの終わり終わりからの「一口」出来事を受けるとき、それは、単に前に進んで、呼び出しを取りこわすことができます(呼び出しの終わりを溯源して、終えながら、両方のゲートウェイの上の終点に"rel"を送って、接続を削除します)。
In the case of operator services and 911, "sus" and "res" are used to pass off-hook and on-hook signals to the operator without releasing any of the resources associated with the call.
オペレータサービスと911の場合では、"sus"と"res"は、呼び出しに関連しているリソースのいずれも発表しないでオフフックとフックの上の信号をオペレータに渡すのに使用されます。
Ringing (rg; P,S + TO; BL,DO): This signal is used for outgoing basic
trunks ("bl" package). See GR-506-CORE - LSSGR: SIGNALING, Section
14. The provisioning process may define the ringing cadence. It is
considered an error to try and ring if the trunk indicates off hook
and an error should consequently be returned when such attempts are
made (error code 401 - phone off hook).
鳴る、(; rg、P、S+、;、BL、してください )、: この信号は出発している基本的なトランクス("bl"パッケージ)に使用されます。 GR506コアを見てください--、LSSGR: シグナリング、セクション14。 食糧を供給することの過程は鳴るリズムを定義するかもしれません。 トランクがオフフックを示すなら鳴ってみるように誤りであるとそれを考えます、そして、そのような試みをするとき(エラーコード401--フックの電話)、その結果、誤りを返すべきです。
In the case of the "DO" package, "rg" is defined as an event used to indicate detection of ringing.
「してください」というパッケージの場合では、"rg"は鳴ることの検出を示すのに使用される出来事と定義されます。
Release complete (rlc;P,S + BR; DO,DT,MD,MO,MS): The endpoint and
Call Agent use the release complete event/signal to confirm the call
has been released and the trunk is available for another call. For
FXO ground-start ("DO" package), this represents the release of the
tip-ground event from the PBX after the gateway goes on-hook.
リリース完全(rlc; P、S+BR;はして、DT、MDはMO(MS)です): 終点とCallエージェントは、呼び出しがリリースされて、トランクが別の呼び出しに利用可能であると確認するのにリリースの完全な出来事/信号を使用します。 FXO地面始め(「してください」というパッケージ)に、ゲートウェイがフックに行った後にこれはPBXからチップ地面出来事のリリースを表します。
Reorder tone (ro; - + TO; BL,DT,MD,MS): 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. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.
追加注文トーン(ro; --+ TO;BL、DT、MD、MS): 追加注文トーンは、-21dBmの結合したレベルを与えるためには480と620Hertzの頻度とそれぞれ-24dBmのレベルがある2つの交流トーンの組み合わせです。 絶え間なく繰り返して、追加注文トーンのためのリズムは0.25秒までに以下でオフさ0.25秒です。 GR506コアを見てください--、LSSGR: シグナリング、セクション17.2.7。
Ring back tone (rt; - + TO; BL,DT,MD,MS): Audible Ring 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. In the US the cadence for Audible Ring Tone is defined to be 2 seconds on followed by 4 seconds off. The definition of the tone is defined by the national characteristics of the Ring-back Tone, and MAY be established via provisioning. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5.
トーン(rt; --+ TO;BL、DT、MD、MS)の電話をかけ直してください: 聞きとれるRing利根は、-16dBmの結合したレベルを与えるためには440と480Hertzの頻度とそれぞれ-19dBmのレベルがある2つの交流トーンの組み合わせです。 米国では、Audible Ring利根へのリズムが、4秒までに以下でオフさ2秒であるために定義されます。 トーンの定義は、Ring逆利根の民族的特徴によって定義されて、食糧を供給することを通して確立されるかもしれません。 GR506コアを見てください--、LSSGR: シグナリング、セクション17.2.5。
Call Setup (sup ; P,S + TO; DO,DT,MD,MS,MO): The event/signal is used both for outgoing and incoming call setups. Each will be described separately in the following.
セットアップに電話をしてください、(; 一口、P、S+、; してください、DT、MD(MS)(MO))、: 出来事/信号はともに送受信の呼び出しセットアップに使用されます。 それぞれが別々に以下で説明されるでしょう。
Foster Informational [Page 19] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[19ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Outgoing call setup:
発信電話セットアップ:
On an outgoing trunk, the "sup" signal is used to seize a trunk and
out-pulse digits. The "sup" signal is parameterized with up to four
parameters sup(<ct>, <ca>, <id>, <addr>), depending on the package.
The order of these parameters does not matter. The following table
indicates which ones are mandatory ("M"), optional ("O") or forbidden
("F") for the various packages.
一方向中継局の上では、「一口」信号は、トランクと出ているパルス・ディジットを捕らえるのに使用されます。 パッケージによって、「一口」信号は最大4でparameterizedされて、パラメタにすすられるという(<ct>、<ca>、<イド>、<addr>)ことです。 これらのパラメタの注文は重要ではありません。 以下のテーブルは、様々なパッケージに、どれが義務的(「M」)か、任意(「O」)かまたは禁制であるかを(「F」)示します。
Table 13 "sup" parameters.
テーブル13はパラメタを「すすります」。
------------------------------------
| Parameter | MS | DT | MO | MD | DO |
|------------------------------------|
| <ct> | F | F | F | M | F |
| <ca> | F | F | F | O | F |
| <id> | F | F | M | M | F |
| <addr> | M | M | M | O | M |
------------------------------------
------------------------------------ | パラメタ| さん| DT| MO| MD| してください。| |------------------------------------| | <ct>。| F| F| F| M| F| | <ca>。| F| F| F| O| F| | <イド>。| F| F| M| M| F| | <addr>。| M| M| M| O| M| ------------------------------------
The <ct> parameter is of the format ct(<ct-value>) where <ct-value> indicates the CAS signaling type and can have one of two values "nda" (North American Direct Access) for EANA and "nta" (North American Tandem Access) for EAIN. The reason this parameter is needed in the case of trunks that handle the "MD" packages is because the same trunk can be used for both. The <addr> field contains the destination number and when present will be on the form
<ct>パラメタは形式ctでは、<ct価値の>が、CASシグナリングがタイプして、2の1つを持つことができるのを示す(<ct価値の>)がEANAのための"nda"(北米のDirect Access)とEAINのための"nta"(北米のTandem Access)を評価するということです。 「MD」がパッケージするハンドルがトランクスに関するケースですが、このパラメタが両方に同じトランクを使用できるので必要である理由。 <addr>分野は目的地番号を含んでいます、そして、存在しているとき、フォームの上にあるでしょう。
addr(dig1, dig2, ..., dign)
addr(dig1、dig2、…、dign)
The <id> field contains the identification of the caller and when present will be of the form:
<イド>分野はプレゼントがいつ訪問者とフォームのものになるかに関する識別を含んでいます:
id(dig1, dig2, ..., dign)
イド(dig1、dig2、…、dign)
The <ca> field contains the country address information and when present will be of the form:
<ca>分野は国のアドレス情報を含んでいます、そして、存在しているとき、フォームがあるでしょう:
ca(dig1, dig2, ..., dign)
ca(dig1、dig2、…、dign)
When present, the <addr> field contains the destination number and will be of the form
存在しているとき、<addr>分野は、目的地番号を含んでいて、フォームのものになるでしょう。
addr(dig1, dig2, ..., dign)
addr(dig1、dig2、…、dign)
where digi is an MF symbol as defined in table 11 in the case of "MS", "MO", and "MD" packages and digi is a DTMF symbol (0-9, *,#,A,B,C,D) in the case of the "DT" and "DO" packages.
digiが「さん」、「MO」、および「MD」パッケージの場合でテーブル11で定義されるようにMFシンボルであり、digiがaであるところでは、DTMFは"DT"の場合で(0-9、*、#、A、B、C、D)を象徴して、「します」。
Foster Informational [Page 20] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[20ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
The following table shows some interactions between the Media Gateway
(MG) and the Switched Circuit Network (SCN) for single stage
outpulsing applications ("DT", "MS" and "DO" packages):
以下のテーブルはメディアゲートウェイ(MG)とSwitched Circuit Network(SCN)とのいくつかの相互作用をアプリケーションを「外-律動的に送」る単段に案内しています(「さん」と「してください」は、"DT"とパッケージします):
Table 14 SCN Sequencing during Call Setup (single stage outpulsing)
テーブル14 呼び出しセットアップの間のSCN配列(単段の「外-律動的に送」り)
------------------------------------------------------------------
|Interface Type |Setup | Interactions |
|------------------------------------------------------------------|
|wink start |sup(add(<addrvalue>)) |MG| off-hook -> |SCN|
| | |MG| <- wink |SCN|
| | |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
|Immediate Start|(sup(addr(<addrvalue>)) |MG| off-hook -> |SCN|
| or FXO) | |MG| <addrvalue> -> |SCN|
------------------------------------------------------------------
------------------------------------------------------------------ |インターフェース型|セットアップ| 相互作用| |------------------------------------------------------------------| |ウインク始め|すすってください((<addrvalue>)を加えてください)。|mg| オフフック->。|SCN| | | |mg| <。 ウインク|SCN| | | |mg| <addrvalue>->。|SCN| |------------------------------------------------------------------| |即座の始め|((addr(<addrvalue>))をすすってください| MG| オフフック->| SCN| | FXO) | |mg| <addrvalue>->。|SCN| ------------------------------------------------------------------
Call setup signal example for this case (MF signaling):
このような場合(MFシグナリング)信号の例にセットアップに電話をしてください:
sup(addr(s0,5,5,5,1,2,3,4,k0))
一口(addr(s0、5、5、5、1、2、3、4、k0))
The "MO" and "MD" packages involve multi-stage signaling and multiple parameters. In the case of the "MD" package the following table shows some of the interactions:
「MO」と「MD」パッケージはマルチステージシグナリングと複数のパラメタにかかわります。 「MD」パッケージの場合では、以下のテーブルは相互作用のいくつかを示しています:
Table 15 SCN Sequencing during Call Setup (EANA and EAIN)
テーブル15 呼び出しセットアップの間のSCN配列(EANAとEAIN)
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| addr(<addrvalue>), id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------
------------------------------------------------------------------ |セットアップ| 相互作用| |------------------------------------------------------------------| | (| MG| オフフック->| SCN| | ct(nda)、addr(<addrvalue>)、イド(<idvalue>))をすすってください。|mg| <。 ウインク|SCN| | |mg| <idvalue>->。|SCN| | |mg| <addrvalue>->。|SCN| |------------------------------------------------------------------| | (ct(nta)、ca(<cavalue>)、| MG| オフフック->| SCN| | addr(<addrvalue>)、イド(<idvalue>))をすすってください。|mg| <。 ウインク|SCN| | |mg| <cavalue>->。|SCN| | |mg| <。 ウインク|SCN| | |mg| <idvalue>->。|SCN| | |mg| <addrvalue>->。|SCN| |------------------------------------------------------------------| | (| MG| オフフック->| SCN| | ct(nta)、ca(<cavalue>)、イド(<idvalue>))をすすってください。|mg| <。 ウインク|SCN| | |mg| <cavalue>->。|SCN| | |mg| <。 ウインク|SCN| | |mg| <idvalue>->。|SCN| ------------------------------------------------------------------
Foster Informational [Page 21] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[21ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
The last example is an overlapped sending example where the address value would be sent later using the "inf" signal.
最後の例はアドレス値は後で"inf"信号を使用させられる重ね合わせられた送付の例です。
An example setup:
例のセットアップ:
sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,0,5,5,5,1,2,3,4,s0))
一口(ct(nta)、ca(k0、1、3、8、9、9、0、0、1、0、s0)、イド(k0、0、5、5、5、1、2、3、4、s0))
In all of the above cases, the "ans" event is an indication of off- hook from the far end (the other end answered). However, in the case of the operator service signaling (OSS) protocol of Feature Group D - shown in the following table, off-hook from the operator is part of the protocol (a request for the calling number) so that "ans" in this case does not indicate that the operator answered (only that off- hook/request for calling number was received).
上の場合では、"ans"出来事は全部で、遠端からのオフフックのしるし(もう一方の端に答えた)です。 しかしながら、Feature Group D--以下のテーブルで目立つオペレータサービスシグナリング(OSS)プロトコルの場合では、オペレータからのオフフックがプロトコル(呼ぶ番号を求める要求)の一部であるので、この場合、"ans"は、オペレータが答えたのを示しません(数と呼ぶのを求めるそのオフフック/要求だけを受け取りました)。
Table 16 SCN Sequencing during Call Setup OSS Protocol ("MO" Package)
テーブル16 呼び出しセットアップOSSの間にプロトコルを配列するSCN(「MO」パッケージ)
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <- off-hook |SCN|
| |MG| <addrvalue> -> |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------
------------------------------------------------------------------ |セットアップ| 相互作用| |------------------------------------------------------------------| | (| MG| オフフック->| SCN| | ct(nda)、addr(<addrvalue>)、イド(<idvalue>))をすすってください。|mg| <。 ウインク|SCN| | |mg| <。 オフフック|SCN| | |mg| <addrvalue>->。|SCN| | |mg| <idvalue>->。|SCN| ------------------------------------------------------------------
Incoming Call Setup: A "sup" event is used to indicate when an incoming call arrives (corresponding to the incoming off-hook event). The event is provided without parameters.
かかってきた電話セットアップ: 「一口」出来事は、かかってきた電話がいつ到着するかを(入って来るオフフック出来事に対応する)示すのに使用されます。 パラメタなしで出来事を供給します。
Suspend call (sus; P + BR; DT,MD,MS,MO): Suspend ("sus") is an on-
hook event that is an indication that the called party went on-hook.
呼び出し(sus; P+BR; DT、MD(MS)(MO))を中断させてください: 中断、("sus")がそうである、オンである、被呼者がフックに行ったという指示である出来事を掛けてください。
An on-hook event will be "notified" to a Call Agent as a "sus" event for interfaces that use the "MS", "DT" and "MD" packages from an endpoint at a terminating end of a call (as compared to a "rel" event from the originating side). The "sus" event from the terminating endpoint gives the Call Agent the option of doing "suspend/resume" processing or to simply release the call.
フックにおける出来事は「さん」(要求(由来側からの"rel"出来事と比べて)の終わり終わりの終点からの"DT"と「MD」パッケージ)を使用するインタフェースへの"sus"出来事としてCallエージェントに「通知されるでしょう」。 終わり終点からの"sus"出来事は「中断するか、または再開してください」という処理か単にリリースへ呼び出しするオプションをCallエージェントに与えます。
The "sus" signal may be used to send an on-hook to the originating party without releasing the resources associated with the telephony leg of the call. The "rel" signal on the other hand would send an on-hook and release the resources associated with the call.
"sus"信号は、呼び出しの由来しているパーティーへのフックの電話に関連しているリソースを発表しないで行程を送るのに使用されるかもしれません。 他方では、"rel"信号は進行中のフックとリソースが呼び出しに関連づけたリリースを送るでしょう。
Foster Informational [Page 22] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[22ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Because of this "sus" can be followed by "res" (off-hook) and allow the call to resume, while "rel" cannot be followed by "res" because the call no longer exists.
この"sus"のために、"res"(オフフック)によって続かれていて、再開するという要求を許すことができます、呼び出しがもう存在していないので、"res"は"rel"に続くことができませんが。
For E911 ("MO" package), the operator is normally in control of
releasing the call so that, "sus" (on-hook), "res" (off-hook) and
"rcl" (flash-hook) can be used to pass user hook events to the
operator without releasing the call.
911E(「MO」パッケージ)、オペレータは通常、呼び出しをリリースしないで"sus"(フックの)、"res"(オフフック)、および"rcl"(フラッシュフック)をオペレータへのパスユーザフック出来事に使用できるように呼び出しをリリースするコントロール中です。
Start Wink (swk; x + - MD,MO):. An Call Agent can optionally request
the MG to notify it when the wink start signal occurs. Note that
wink start ("swk") cannot be applied by the Call Agent as a signal.
The occurrence of wink-start on an incoming trunk is a reflexive
action that does not require Call Agent involvement.
スタートWink(swk; x+--MD(MO)): . ウインクスタート信号が現れると、Callエージェントは、それに通知するようMGに任意に要求できます。 Callエージェントが信号としてウインク始め("swk")を適用できないことに注意してください。 着信トランクにおけるウインク始めの発生はCallエージェントかかわり合いを必要としない再帰の動作です。
3.0. Hook-State Signals and Events
3.0. フック州の信号と出来事
3.1. Overview of Approach
3.1. アプローチの概観
As mentioned in the introduction, a higher level view is taken for on-hook and off-hook events for many of the CAS packages to make the interface Q.931-like. This provides the advantage that:
序論で言及されるように、CASパッケージの多くでインタフェースがQ.931のようになるように、オンフックとオフフック出来事により高い平らな意見を取ります。 これはそれを利点に提供します:
* Similar call flows result as when dealing with Q.931-based
interfaces (e.g., PRI)
* It's more evident (for ease in debug) when looking at message as
to exactly what is going on without having to refer to previous
flows.
* 同様の呼び出し流れはまさに前の流れについて言及する必要はなくて起こっていることに関してメッセージを見る*Q.931ベースのインタフェース(例えば、PRI)に対処して、それが、より明白である(デバッグにおける容易さのための)時として結果として生じます。
This does require that media gateways maintain some state but this is a relatively small price to pay.
これは、支払うためにメディアゲートウェイが何らかの状態を維持しますが、これが比較的わずかな価格であることを必要とします。
One example of this is the "sup" signal which involves sending off- hook followed by digits as a high level signal. The "ans" event is also used to represent off-hook but from the terminating end at the point where the call is answered.
この1つの例がケタが高い平らな信号としてあとに続いた退場フックにかかわる「一口」信号です。 "ans"出来事が呼び出しが答えられるポイントにオフフックを表すのに使用されますが、終わり終わりからもあります。
3.2. Suspend/Resume Processing
3.2. 処理するのを中断するか、または再開してください。
Other signals and events "sus" for suspend, "res" for resume and "rel" for release are based on the concept that one end (the originator) is in control of the call. If the controlling end goes on-hook a "rel" is notified to the Call Agent, and results in a the call being released. However, if the non-controlling (terminating) end goes on-hook, a "sus" event occurs (instead of the "rel" event). This gives the Call Agent the option of doing suspend/resume processing.
リリースは、信号と出来事が"susする"であるもう一方のために履歴書のために「resに」中断して、"relする"です。片端(創始者)が呼び出しのコントロール中である概念に基づいています。 制御側終端がフックであることへ去るなら、"rel"はCallエージェントに通知されます、そして、リリースされる呼び出しはaの結果が通知されます。 しかしながら、非制御(終わり)終わりがフックであることへ去るなら、"sus"出来事は起こります("rel"出来事の代わりに)。 これはするオプションが停止するか、または再開するCallエージェントに処理を与えます。
Foster Informational [Page 23] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[23ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
If the Call Agent decides not to do suspend/resume processing, it can simply send "rel" and delete connection commands to the endpoints after it receives "sus" from the non-controlling (terminating) end of the call.
Callエージェントが、処理するのを中断するか、または再開しないと決めるなら、呼び出しの非制御(終わり)終わりから"sus"を受けた後に、それは、単に"rel"を送って、接続命令を終点に削除できます。
On the other hand, if it decides to do suspend/resume processing, it
can start a timeout when it receives the "sus" event from the non-
controlling (terminating) end of the call and continue the call if it
receives a "res" (off-hook) event. It also has the option of
propagating the "sus" and "res" as signals back to the ingress
gateway and allow it an opportunity to release the call ("rel" event)
or not. In any case the use of "sus" and "res" signals give another
level of control over the "rel" signal which will not only send on-
hook but also release the resources associated with the telephony leg
of the call.
他方では、処理するのを中断するか、または再開すると決めるなら、"res"(オフフック)出来事を受けるなら、それは、それが呼び出しの非制御(終わり)終わりからの"sus"出来事を受けるとき、タイムアウトを始めて、呼び出しを続けることができます。 また、それには、信号が要求("rel"出来事)をリリースする機会であるか否かに関係なく、イングレスゲートウェイに支持して、それを許容するように"sus"と"res"を伝播するオプションがあります。 どのような場合でも、"sus"と"res"信号の使用は発信するだけではない"rel"信号の上の別の管理水準をオンに与えます。掛けますが、呼び出しの電話行程に関連しているリソースをまた発表してください。
3.3. Control over Disconnect for E911
3.3. 911Eのための分離のコントロール
Note that for E911 (the "MO" package) is a special case in that the operator (terminating end) is always the controlling end. The "sus" and "res" signals are used to pass user hook state forward to the operator. The "rel" event is passed back as a notify to the Call Agent when on-hook is received from the operator indicating that the Call should be released. If the "rel" is not received the call should continue to stay up.
911E(「MO」パッケージ)のものがいつもオペレータ(終わりを終える)が制御側終端であるので特別なそうであることに注意してください。 "sus"と"res"信号は、ユーザフック状態をオペレータに前方へパスするのに使用されます。 Callがリリースされるべきであるのを示すオペレータからオンフックを受け取るとき、aがCallエージェントに通知するとき、"rel"出来事は戻されます。 "rel"が受け取られていないなら、呼び出しは、寝ずに起きてい続けるべきです。
3.3. Release and Release Complete
3.3. リリースとリリース完全です。
The "rel" signal/event generally means on-hook but more that that it also indicates "release of resources" for the telephony leg of the call. If a Call Agent sends a "rel" signal instead of "sus" it is requesting the call to be abandoned (i.e., "rel" cannot be followed by "res").
一般に、"rel"信号/出来事はフックにもかかわらず、より多くに意味します。電話のための「リソースのリリース」が急いで歩くそれも、示す呼び出しのもの。 Callエージェントが"sus"の代わりに"rel"信号を送るなら、それは、捨てられるよう呼び出しに要求しています("res"はすなわち、"rel"に続くことができません)。
The "rel" signal does not also imply that connections should be deleted so that to completely release the call including connections would require a DLCX in addition to (or conjunction with) the signal "rel".
に加えてまた、"rel"信号が、接続を含む呼び出しを完全にリリースするのがDLCXを必要とするように接続が削除されるべきであるのを含意しない、(接続詞、)、信号"rel"。
In addition to being a signal, "rel" can also be an event triggered by either:
信号であることに加えて、また、"rel"はどちらかによって引き起こされた出来事であるかもしれません:
* An on-hook from the controlling end of the call, or
* または呼び出しの制御からのフックの終わり。
* Some abnormal event within the media gateway such that the
telephony leg of the call can no longer be maintained.
* メディアゲートウェイの中のいくつかの異常な出来事、維持されています。
Foster Informational [Page 24] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[24ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
In any case, "rel" (release) is generally followed by an "rlc" (release complete). The release complete signal/event indicates that the trunk resources are now completely released and available for another call. This is also an event state that can be audited as indicated by the "S" in the column for that event (allowing the Call Agent to check to see if that trunk is released and available).
どのような場合でも、一般に、"rel"(リリース)は(リリース完全)で"rlc"によって続かれています。 リリースの完全な信号/イベントは、トランクリソースが現在、完全にリリースされていて別の呼び出しに利用可能であることを示します。 また、これはその出来事(呼び出しエージェントがそのトランクがリリースされていて利用可能であるかどうか確認するためにチェックするのを許容する)のためのコラムの「S」によって示されるように監査できるイベント状態です。
Examples of the use of "rel" and "rlc":
"rel"と"rlc"の使用に関する例:
* Call Agent sends a "rel" to release a trunk, resulting in an
outgoing off-hook being sent for that trunk. When the media
gateway receives the on-hook from the other end, it returns an
"rlc" event indicating that the trunk is released and available.
* The media gateway receives a on-hook from the trunk at the
controlling end of the call, resulting in a "rel" event being sent
to the Call Agent. The Call Agent then sends an "rlc" to the
media gateway, resulting in on-hook being sent in the opposite
direction.
* An "rel" event is sent to the Call Agent in the event of some
abnormal condition in which the media gateway is unable to sustain
the telephony leg of the call (e.g., glare condition). The Call
Agent sends an "rlc" to the gateway to complete the release of the
call. (note that "rlc may not correspond to on-hook but is
generally sent anyway in response to a "rel".)
* The Call Agent can send a "rel" (instead of "sus") signal to the
controlling (originating) end of the call to abandon the call.
The gateway will return with "rlc" when an off-hook has been
received from the other end and all the resources have been
released.
* A "rel" can be sent on one-way incoming trunk to release a block
("bl") sent earlier.
* そのトランクのために送られる出発しているオフフックをもたらして、呼び出しエージェントは、トランクを解放するために"rel"を送ります。 ゲートウェイがオンフックを受けるメディアであるときに、他は終わって、それはトランクがリリースされていて利用可能であることを示す"rlc"出来事を返します。 * メディアゲートウェイは呼び出しの制御側終端のトランクからオンフックを受けます、Callエージェントに送られる"rel"出来事をもたらして。 フックにおける逆方向に送られた存在をもたらして、そしてCallエージェントは"rlc"をメディアゲートウェイに送ります。 * 何らかの異常な状態の場合、メディアゲートウェイが要求(例えば、ギラギラと眩しい光状態)の電話行程を支えることができない"rel"出来事をCallエージェントに送ります。 Callエージェントは、呼び出しのリリースを終了するために"rlc"をゲートウェイに送ります。 (それに注意してください、「rlcをオンフックに対応しないかもしれませんが、一般に、とにかく"rel"に対応して送る、)、」 * Callエージェントは"rel"("sus"の代わりに)信号を呼び出しを捨てるという要求の制御(由来)終わりに送ることができます。 もう一方の端からオフフックを受け取って、すべてのリソースを発表したとき、ゲートウェイは"rlc"とともに帰るでしょう。 * "rel"は、より早く送られたブロック("bl")を発表する転送された片道着信トランクであるかもしれません。
The "BL" (FXS) package is a simple line package, so does not have these events (uses "hd", "hf", and "hu" as the only hook state events).
"BL"(FXS)パッケージには、簡単な線パッケージであるので、これらの出来事がありません(唯一のフック州のイベントとして"hd"、"hf"、および"hu"を使用します)。
The "DO" (FXO) package, however, does have "rel" and "rlc" because in the ground-start case there is the ability to "release" the call as result of a tip-ground release. The signal "rel" is used if the PBX releases the call first (followed by S: hu from the call Agent to complete the release). Alternatively, the Call Agent can send the S: hu to initiate the release - followed by an "rlc" event from the media gateway to Call Agent when the PBX does the tip ground release. Although the loop-start trunks would not normally have this behavior (only applies to ground-start), the media gateway should emulate the behavior in the case of loop-start in order to allow the Call Agent a common interface.
地面スタート場合には、チップ地面リリースの結果として呼び出しを「リリースする」能力があるので、「してください」(FXO)パッケージでは、しかしながら、"rel"と"rlc"があります。 PBXが最初に(リリースを終了するためにS: huによって呼び出しエージェントから続かれている)呼び出しをリリースするなら、信号"rel"は使用されています。 あるいはまた、CallエージェントはSを送ることができます: リリースを開始するhu--PBXがチップをするとCallエージェントへのメディアゲートウェイからの"rlc"出来事があとに続いているのがリリースを研摩しました。 輪スタートトランクスには、この振舞い(地面始めに適用するだけである)が通常ないでしょうが、メディアゲートウェイは、Callエージェントに一般的なインタフェースを許容するために輪始めの場合で振舞いを見習うはずです。
Foster Informational [Page 25] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[25ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
3.4. Blocking CAS Trunks
3.4. CASトランクスを妨げます。
In addition to the above signals and events, there is the "bl" signal/event which is used for blocking one-way trunks (does not work for two way trunks) by providing a continuous off-hook.
上記の信号と出来事に加えて、連続したオフフックを提供することによって片道トランクス(ツーウェイトランクスのために、働いていない)を妨げるのに使用される"bl"信号/出来事があります。
3.5. Summary of Hook-State Events
3.5. フック州のイベントの概要
The following summarizes the use of the various events that involve off-hook and on-hook from call establishment to tear-down. This applies mainly to "MS", "DT", "MD" and to a lesser extent the "DO" package.
以下はオフフックと呼び出しからのフックの設立に分解にかかわる様々な出来事の使用をまとめます。 これは主に「さん」、"DT"、「MD」、およびある程度「してください」というパッケージに適用されます。
* The "sup" event represents off-hook origination.
* The "sup" signal with parameters provides off-hook with digit
outpulsing on the terminating side.
* Once outpulsing is completed, an "ans" event indicates off-hook
from the termination side (the called party has answered).
* The call agent can then send an "ans" signal (off-hook) to the
originating end to indicate to the caller that the called party
has answered.
* The Call Agent can send a "rel" to either end at any time to tear
down the call (e.g., to abort the call).
* The media gateway can send "rel" to indicate abnormal termination
of the call (with a reason as a parameter).
* However, under normal operation once a call is established, the
Call Agent can expect a "sus" (suspend) event from the termination
end to indicate that the caller went on-hook and a "res" if the
called party goes off-hook again before the Call Agent tears down
the call. The Call Agent can send these same signals to the
originating end to indicate off-hook and on-hook to the calling
party without tearing down the call.
* During normal operation, once the call is established, on-hook
from the calling party (origination side) would result in a "rel"
signal. The Call Agent would then normally send the "rel" signal
to the terminating end to terminate the call. "rel is normally
followed by "rlc" (e.g., media gateway indicates calling party on-
hook with "rel" and the Call Agent responds with "rlc", which
sends on on-hook back to the calling party to indicated release
complete.
* 「一口」出来事はオフフック創作を表します。 * パラメタがある「一口」信号は終わり側の上のケタの「外-律動的に送」りがあるオフフックを提供します。 * 「外-律動的に送」りがいったん完成するようになると、"ans"出来事は終了側からオフフックを示します(被呼者は答えました)。 * そして、呼び出しエージェントは、被呼者が答えたのを訪問者に示すために、"ans"信号(オフフック)を由来している終わりに送ることができます。 * Callエージェントは、いつでも、要求(例えば呼び出しを中止する)を取りこわすために"rel"をどちらの終わりにも送ることができます。 * メディアゲートウェイは、要求(パラメタとしての理由がある)の異常終了を示すために"rel"を送ることができます。 * しかしながら、Callエージェントが呼び出しを取りこわす前に被呼者が再びフックに行くなら、呼び出しがいったん確立されると通常の操作で、Callエージェントは訪問者がフックに行ったのを示す終了終わりと"res"からの"sus"(中断する)出来事を予想できます。 Callエージェントは、呼び出しを取りこわさないでオフフックと呼ぶことへのフックのパーティーを示すためにこれらの同じ信号を由来している終わりに送ることができます。 * 通常の操作の間、呼び出しがいったん確立されると呼ぶのからのフックのパーティー(創作側)は"rel"信号をもたらすでしょう。 そして、通常、Callエージェントは、呼び出しを終えるために"rel"信号を終わり終わりに送るでしょう。 "rlc"によって続かれて、通常、relはそうです。「(例えば、メディアゲートウェイは、パーティーが進行中であると言って、「」 Callエージェントが呼ぶことへのフックのパーティーを示されたリリースに完全な状態で転送する"rlc"で反応させるrel」で掛けるように示します。
The "MO" package is a bit different in that normally only the
terminating side (the operator) can release the call ("rel" event).
The "sus" and "res" are forward signals to the operator indicating
user hook-status.
「MO」パッケージは通常、終わり側(オペレータ)だけが要求("rel"出来事)をリリースできるという点において少し異なっています。 "sus"と"res"はユーザフック状態を示すオペレータへの前進の信号です。
Foster Informational [Page 26] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[26ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
4.0. Glare Handling
4.0. ギラギラと眩しい光取り扱い
4.1. Glare on MF Bi-directional Wink-start Trunks
4.1. mfの双方向のウインクスタートトランクスの上ににらみつけてください。
Gateways may have a configurable glare bit on a per-DS0 basis that can be set to indicate whether the gateway is the controlling or non-controlling "switch". However, in general, PBXs are either pre- configured or can be configured to behave as non-controlling switches. In this case if they see an off-hook that exceeds allowable wink length, they will attach a receiver, go on-hook, and await digits for a new call. Meanwhile the PBX will retry its original call on another trunk.
ゲートウェイはゲートウェイが制御か非制御「スイッチ」であるかどうかと示すように設定できる1DS0あたり1個のベースに構成可能なギラギラと眩しい光ビットを持っているかもしれません。 しかしながら、一般に、PBXsは、非制御が切り替わっている間、振る舞うためにあらかじめ構成するか、または構成できます。 この場合、許容できるウインクの長さを超えているオフフックを見ると、彼らは、受信機を取り付けて、フックに行って、新しい呼び出しのためにケタを待つでしょう。 その間、PBXは別のトランクの上にオリジナルの呼び出しを再試行するでしょう。
If the gateway behaves like a controlling switch, when glare is detected, the gateway will wait for up to some timeout value (default value of 4 seconds) until the incoming off-hook changes to an on-hook state at which time it will start out-pulsing in the normal manner. If the timeout occurs before the state change to on-hook occurs, the gateway will send a release event to the Call Agent (a "rel(44)" event - cause code indicating glare).
ギラギラと眩しい光が検出されるとき、ゲートウェイが制御スイッチのように振る舞うなら、入って来るオフフックが、それがいつ出かけている脈打つことを始めるかをフックの状態に正常な方法で変えるまで、ゲートウェイは何らかのタイムアウト価値(4秒のデフォルト値)まで待っています。 オンフックへの州の変化が起こる前にタイムアウトが起こると、ゲートウェイはCallエージェント("rel(44)"出来事--ギラギラと眩しい光を示す原因コード)にリリースイベントを送るでしょう。
When "rel(44)" is sent by the gateway, that is an indication to the Call Agent that the call is in the process of being released and that the Call Agent should give up on that trunk. However, the gateway may not actually want to send the on-hook at that time in order to avoid the possibility that the other end takes the on-hook as a wink. Instead, it may start a second timer and wait some longer period of time (e.g., 16 seconds or so) before releasing the trunk. If it receives an on-hook prior the timeout, it completes the release by going on-hook. If, on the other hand, the timer expires before the other end goes on-hook, it will simply go on-hook and wait for the other end to go on-hook. In any case, once both ends have returned to the on-hook state, an "rlc" event is sent to the Call Agent.
ゲートウェイで"rel(44)"を送るとき、それはCallエージェントへのリリースされることの途中に呼び出しがあって、Callエージェントがそのトランクに見切りをつけるべきであるという指示です。 しかしながら、ゲートウェイは、その時、もう一方の端がウインクとしてオンフックをみなす可能性を避けるために実際にオンフックを送りたがっていないかもしれません。 代わりに、それは、2番目のタイマを始動して、トランクを解放する(例えば、およそ16秒)前のいくつかの、より長い期間を待つかもしれません。 オンフックを優先的に受けるなら、タイムアウトであり、それは、フックに行くことによって、リリースを終了します。 他方では、もう一方の端がフックに行く前にタイマが期限が切れると、それは、単にフックに行って、もう一方の端がフックに行くのを待つでしょう。 どのような場合でも、両端がいったんフックの状態に戻ると、"rlc"出来事をCallエージェントに送ります。
4.2. Glare Handling - Basic PBX Trunks
4.2. ギラギラと眩しい光取り扱い--基本的なPBXトランクス
In order to reduce the chances of glare, the gateway should try a ringing pre-trip test prior to sending ringing on a basic ground start trunk. If glare is detected on an outgoing seizure of a basic PBX trunk, the request for ringing should be "Nacked" (error code 401 - phone off-hook) to the Call Agent.
ギラギラと眩しい光の可能性を小さくするために、ゲートウェイは基本的な地面スタートトランクの上に鳴りながら発信する前に、あらかじめつまずいている鳴るテストを試みるはずです。 ギラギラと眩しい光が基本的なPBXトランクの外向的な捕獲に検出されるなら、Callエージェントにとって鳴るのを求める要求は"Nacked"であるべきです(エラーコード401--オフフックに電話をしてください)。
Foster Informational [Page 27] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[27ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
5.0. Example Call Flows
5.0. 例の呼び出し流れ
5.1. PBX to PBX ("MS", "DT, and "BL" packages).
5.1. PBXへのPBX、(「さん」、「DT、および"BL"パッケージ、)、」
The following call flows involve a single Call Agent that handles both sides of the call (i.e., the inter-Call-Agent signaling is ignored). The components involved in the call are:
以下の呼び出し流れは呼び出しの両側を扱う独身のCallエージェントにかかわります(すなわち、相互Callエージェントシグナリングは無視されます)。 呼び出しにかかわるコンポーネントは以下の通りです。
* The Call Agent (CA)
* 呼び出しエージェント(カリフォルニア)
* The originating Media Gateway (GW-o) and
* そして由来しているメディアゲートウェイ(GW-o)。
* The terminating Media Gateway (GW-t)
* 終わっているメディアゲートウェイ(GW-t)
5.1.1. Call Setup Flows
5.1.1. 呼び出しセットアップは流れます。
The following describes some PBX to PBX call. The table gives an overview of the initial part of the call flow with details to follow.
以下はいくらかのPBXについてPBX呼び出しに説明します。 テーブルは、続くように詳細がある呼び出し流動の初期の部分の概観を与えます。
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[seizure] -> |
| A2 | <- Ack |
| A3 | <- RQNT[request digits] |
| A4 | Ack -> |
| A5 | NTFY[digits] -> |
| A6 | <- Ack |
| B1 | <- CRCX [M:recvonly, LCO] |
| B2 | Ack[SDP1] -> |
| B3 | CRCX [M:sendrecv, LCO, SDP1] -> |
| B4 | <- Ack [SDP2] |
| B5 | <- MDCX [recvonly,SDP2] |
| B6 | Ack -> |
---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[捕獲]->。| | A2| <。 Ack| | A3| <。 RQNT[ケタを要求します]| | A4| Ack->。| | A5| NTFY[ケタ]->。| | A6| <。 Ack| | B1| <。 CRCX[M: recvonly、LCO]| | B2| Ack[SDP1]->。| | B3| CRCX[M: sendrecv、LCO、SDP1]->。| | B4| <。 Ack[SDP2]| | B5| <。 MDCX[recvonly、SDP2]| | B6| Ack->。| ---------------------------------------------------------------------
Step A1 PBX seizure results in a notify to the Call Agent indicating the start of a call setup:
aのステップA1 PBX捕獲結果は呼び出しセットアップの始まりを示すCallエージェントに通知します:
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: ms/sup (or dt/sup)
NTFY3001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789AF O: ms/一口(または、dt/一口)
Foster Informational [Page 28] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[28ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
In the case of the "BL" package (basic PBX) the interface looks
like a simplified line interface with the standard "hd" event for
off-hook:
"BL"パッケージ(基本的なPBX)の場合では、インタフェースはオフフックのための一般的な"hd"出来事を伴う簡易型のラインインターフェースに似ています:
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: bl/hd
NTFY3001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789AF O: bl/hd
Another alternative would have been to use an embedded request in the RQNT that resulted in this notify and combine that request with step A3. Example - "ms" package:
別の代替手段はこれをもたらしたRQNTでの埋め込まれた要求を使用するのがその要求にステップA3に通知して、結合するということだったでしょう。 例--「ms」は以下をパッケージします。
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
R: ms/sup(E(R(ms/inf, ms/rel))
RQNT2001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789AF R: ms/一口、(E(R(ms/inf、ms/rel))
Step 3 could also be eliminated by the use of "loop" mode e.g.:
また、「輪」モードの使用でステップ3を根絶できるだろう、例えば:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
Q:loop
R: ms/sup, ms/inf, ms/rel
RQNT2001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789AF Q: 輪R: ms/一口、ms/inf、ms/rel
This would result in both notifies occurring without requiring the RQNT in step A3.
これは中にA3を踏みます両方の結果が、RQNTを必要とすることのない発生に通知する。
Step A2 The Call Agent sends an Ack:
ステップA2CallエージェントはAckを送ります:
200 3001 OK
3001が承認する200
Step A3 The Call Agent requests that digits be collected. The approach used here depends on the type of PBX interface. For an MF interface the Call Agent requests that information digits be collected as follows:
ステップA3Callエージェントは、ケタが集められるよう要求します。 ここで使用されたアプローチはPBXインタフェースのタイプに頼っています。 MFに関しては、情報ケタが以下の通り集められるというCallエージェント要求を連結してください:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: ms/inf, ms/rel
RQNT2001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0R: ms/inf、ms/rel
The Call Agent also asks to be told if the trunk gets released
for some reason ("rel" event) in the process of call setup
(release event may be due to some signaling error for example).
For DTMF trunks (wink-start, immediate start and Basic PBX), the
request is based on a digit map so looks a bit different:
また、Callエージェントは、トランクが呼び出しセットアップの途中にある理由で("rel"出来事)リリースされるかどうか(リリースイベントは例えば、何らかのシグナリング誤りのためであるかもしれません)言われるように頼みます。 したがって、トランクス(ウインク始め、即座の始め、およびBasic PBX)、要求に基づいているDTMFのためにケタ地図は少し異なるように見えます:
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: d/[0-9*#T](D), dt/rel (bl/hd in the case of Basic PBX)
RQNT2001 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0R: d/[0-9*#T](D)、dt/rel(Basic PBXの場合におけるbl/hd)
Foster Informational [Page 29] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[29ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
D: (xxxxxxx | x.[T#])
S: dt/dl
D: (xxxxxxx| x.[T#]) S: dt/dl
Note: the request to signal dial-tone may or may not be here
depending on PBX interface requirement - bl/dl required for
Basic PBX; dt/dl for some Immediate Start interfaces.
以下に注意してください。 PBXインターフェース要件によって、ダイヤルトーンに合図するという要求がここにあるかもしれません--bl/dlがBasic PBXに必要です。 いくらかのImmediate Startのためのdt/dlが連結します。
Step A4 The gateway responds with an ack:
ゲートウェイがackで反応させるA4を踏んでください:
200 2001 OK
2001が承認する200
Step A5 Once the digits are collected the gateway notifies the call agent. In the case of an MF interface, the resulting notify will look like the following
A5 Onceを踏んでください。ケタは集められて、ゲートウェイが呼び出しエージェントに通知するということです。 MFの場合では、以下に似ていますインタフェース、結果になるのが、意志に通知する。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: ms/inf(k0,5,5,5,1,2,3,4,s0)
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0O: ms/inf(k0、5、5、5、1、2、3、4、s0)
In the case of a DTMF interface (including Basic PBX), it will
look like the following:
DTMFインタフェース(Basic PBXを含んでいる)の場合では、以下に似るでしょう:
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: d/5,d/5,d/5,d/1,d/2,d/3,d/4
NTFY3002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 0123456789B0O: d/5、d/5、d/5、d/1、d/2、d/3、d/4
Step A6 The Call Agent responds with an ack:
ステップA6Callエージェントはackで応じます:
200 3002 OK
3002が承認する200
Step B1 The Call Agent now requests that a receive-only connection be made.
ステップB1Callエージェントは、現在、受信専用接続が作られているよう要求します。
CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
L: a:PCMU,s:off,e:on
M: recvonly
X: 0123456789B1
R: ms/rel (or dt/rel or bl/hu).
CRCX2002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0C: A7453949499L: : PCMU、s: オフである、e: Mに関して: recvonly X: 0123456789B1R: ms/rel(または、dt/relかbl/hu)。
Step B2 The Gateway acks with a connection ID and provides the SDP information:
接続IDと共にB2ゲートウェイacksを踏んで、SDP情報を提供します:
200 2002 OK
I: 23474FE
200 2002はIを承認します: 23474FE
Foster Informational [Page 30] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[30ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m= audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 128.96.41.1 s=cは0 0t=mのIN IP4 128.96.41.1=オーディオの3456RTP/AVP0と等しいです。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request:
ステップB3Callエージェントは接続要求の一部として終わりゲートウェイ(GW-t)にこのSDP情報を通過します:
CRCX 4001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
C: A7453949499
X: 45375840
L: a:PCMU,s:off,e:on
M: sendrecv
CRCX4001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0C: A7453949499X: 45375840、L: : PCMU、s: オフである、e: Mに関して: sendrecv
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 128.96.41.1 s=cは0 0t=mのIN IP4 128.96.41.1=オーディオの3456RTP/AVP0と等しいです。
Note that the call setup on the terminating trunk can be done with this CRCX, although in this call flow - it is shown later (step C1).
このCRCXと共に終わりトランクにおける呼び出しセットアップができることに注意してください、この呼び出し流動で--それは後で示されます(ステップC1)。
Step B4 The terminating gateway, responds with an ack and its SDP information:
B4を踏んでください、ゲートウェイを終えて、ackとそのSDP情報で以下を反応させます。
200 4001 OK
I: 34738A
200 4001はIを承認します: 34738A
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 47.123.34.33 s=cは0 0t=mのIN IP4 47.123.34.33=オーディオの3456RTP/AVP0と等しいです。
Step B5 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
B5 Callエージェントがaを送るステップは、終了ゲートウェイから接続モードが受信専用である状態で創作ゲートウェイに接続要求を変更して、選択されたプロフィールでSDP情報を含んでいます。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: recvonly
MDCX2003 ds/ds1-3/6@gw-o.whatever.net MGCP1.0C: A7453949499I: 34738A M: recvonly
Foster Informational [Page 31] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[31ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 47.123.34.33 s=cは0 0t=mのIN IP4 47.123.34.33=オーディオの3456RTP/AVP0と等しいです。
Step B6 The Gateway Acks the modify connection request
B6ゲートウェイAcksを踏んでください、接続要求を変更してください。
200 2003 OK
2003が承認する200
The following table shows the remainder of the call flow to set up the call except for Basic PBX (Basic PBX shown in) with details to follow.
以下のテーブルは、続くように詳細でBasic PBX(中の基本的なPBXが見せられていた状態で)以外の呼び出しをセットアップするために呼び出し流動の残りを示しています。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | C1 | RQNT [S: ms/sup, R: ms/oc, ms/rel, ms/ans] ->| | C2 | <- Ack | | C3 | <- NTFY [O:ms/oc(ms/sup)]| | C4 | Ack -> | | C5 | <- NTFY [O: ms/ans] | | C6 | Ack -> | | C7 | <- MDCX [M:sendrecv, S: ms/ans, R: ms/rel] | | C8 | Ack -> | | C9 | RQNT[R: ms/sus] -> | | C10 | <- Ack | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | C1| RQNT[S: ms/一口、R: ms/oc、ms/rel、ms/ans]、->|、| C2| <。 Ack| | C3| <。 NTFY[O: ms/oc(ms/一口)]| | C4| Ack->。| | C5| <。 NTFY[O: ms/ans]| | C6| Ack->。| | C7| <。 MDCX[M: sendrecv、S: ms/ans、R: ms/rel]| | C8| Ack->。| | C9| RQNT[R: ms/sus]->。| | C10| <。 Ack| ---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the terminating gateway The setup request for an MF PBX interface (wink start or immediate start) will be the following:
ステップC1CallエージェントはMF PBXインタフェース(ウインク始めか即座の始め)を求めるセットアップ要求が以下になるという終わりゲートウェイへのセットアップ要求をします:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: ms/sup(addr(ko,5,5,5,1,2,3,4,s0))
R: ms/oc, ms/rel, ms/ans
RQNT4002 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841、Q: 輪S: ms/一口(addr(ko、5、5、5、1、2、3、4、s0))R: ms/oc、ms/rel、ms/ans
Note that the result of the "sup" signal is the following
sequence on the interface to the PBX:
「一口」信号の結果がPBXへのインタフェースの以下の系列であることに注意してください:
* off-hook -> PBX
* wink -> PBX (for wink-start trunks; for immediate start this
part of the sequence does is not included)
* Digits sent to PBX
* PBXに送られたオフフック->PBX*ウインク->PBX(系列のこの部分がする即座の始めがウインクスタートトランクス含まれていないので)*ケタ
Foster Informational [Page 32] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[32ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
For DTMF PBX interface (except Basic PBX), the only difference is
that the MF start and end delimiters (k0 and s0) are not
included:
DTMF PBXインタフェース(Basic PBXを除いた)に関しては、唯一の違いはMFが始まって、終わりのデリミタ(k0とs0)が含まれていないということです:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: dt/sup(addr(5,5,5,1,2,3,4))
R: dt/oc, dt/rel, dt/ans
RQNT4002 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841、Q: 輪S: dt/一口(addr(5、5、5、1、2、3、4))R: dt/oc、dt/rel、dt/ans
Basic PBX requires ringing and ring-back instead i.e.:
基本的なPBXが代わりに鳴るのとリング後部を必要とする、すなわち:
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: bl/rg,bl/rt@34738A
R: bl/oc,bl/hd
RQNT4002 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841、Q: 輪S: bl/rg、 bl/rt@34738A R: bl/oc、bl/hd
In this case ringback will come from the gateway and will start
immediately with the signal request for rt@connectionID. It will
end as soon as an event occurs (off-hook representing answer
event) In the case of other PBX's, the ringback tone comes from
the PBX so does not have to be generated by the gateway.
この場合、ringbackはゲートウェイから来て、すぐに、 rt@connectionID のために信号要求から始まるでしょう。 出来事が他のPBXの場合で起こると(答え出来事を表すオフフック)すぐに、それが終わるので、トーンがPBXから来させるringbackはゲートウェイで発生する必要はありません。
Note that these requests could be done as easily at the same time
as the connection request (B3) saving some post-dial delay time.
容易に接続要求(B3)と同時にいくらかのポストダイヤル遅延時間を節約しながらこれらの要求ができたことに注意してください。
Step C2 The gateway responds with an ack:
ゲートウェイがackで反応させるC2を踏んでください:
200 4002 OK
4002が承認する200
Step C3 Except for the basic PBX, case (where digits are not outpulsed) when the digits have completed being sent out, the gateway will notify the fact by indicate that the operation is complete.
基本的なPBX、ケタが、出されるのを完了したときのケース(ケタが「外-律動的に送」られないところ)のためにC3 Exceptを踏んでください、意志が操作が完全であることを示すように事実に通知するゲートウェイ。
NTFY 1001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/oc(ms/sup) (or dt/oc(dt/sup))
NTFY1001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841○: ms/oc(ms/一口)(または、dt/oc(dt/一口))
Step C4 The Call Agent acks the notify
C4Callエージェントacksを踏んでください、通知
200 1001 OK
1001が承認する200
In the case of the BL package, steps C3 and C4 will not exist.
BLパッケージの場合では、ステップのC3とC4は存在しないでしょう。
Foster Informational [Page 33] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[33ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step C5 When an answer is obtained from the other end (off-hook from the PBX), the gateway sends a notify to indicate:
C5 Whenを踏んでください。答えは(PBXからのオフフック)、ゲートウェイが発信する他の終わりから得て、aに以下を示すように通知するということです。
NTFY 1002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/ans (or dt/ans or bl/hd)
NTFY1002 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841○: ms/ans(または、dt/ansかbl/hd)
Step C6 The Call Agent acks
ステップC6Callエージェントacks
200 1002 OK
1002が承認する200
Step C7 The Call Agent now sends a request to make the connection full duplex and indicates that the other end has answered the phone.
ステップC7Callエージェントは、現在、接続全二重を作るという要求を送って、もう一方の端が電話に出たのを示します。
MDCX 2004 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
X: 45375842
I: 34738A
M: sendrecv
S: ms/ans ( or dt/ans but S: not included in the case where the
originating gateway uses the BL package)
MDCX2004 ds/ds1-3/6@gw-o.whatever.net MGCP1.0C: A7453949499X: 45375842、私: 34738A M: sendrecv S: ms/ans(または、由来しているゲートウェイがBLパッケージを使用するところにケースに含まれていないdt/ansにもかかわらず、S)
Step C8 The Gateway acks the request
ステップC8ゲートウェイacksは要求です。
200 2004 OK
2004が承認する200
Step C9 The Call Agent sends a notification request to be told when the trunk to be released.
ステップC9Callエージェントは、リリースされるためにトランクであるときに言われる通知要求を送ります。
RQNT 4003 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
R: ms/rel,ms/sus (or R: dt/rel,dt/sus or R: bl/hu)
RQNT4003 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375842、R: ms/rel、ms/sus(R: R: または、dt/rel、dt/susまたはbl/hu)
Step C10 The gateway acks the request
C10を踏んでください、ゲートウェイは要求をacksします。
200 4003 OK
4003が承認する200
The call is now setup.
現在、呼び出しはセットアップです。
5.1.2. Call Tear-Down
5.1.2. 分解に電話をしてください。
Two cases are included here, one where the origination end initiates the release (section 5.1.2.1) and one where the termination end initiates the release (section 5.1.2.2).
2つのケースがここに含まれています、創作終わりがリリースを開始するもの、(終了終わりがリリースを開始するところで5.1に.2の.1と)1つを区分してください、(セクション5.1 .2 .2)。
Foster Informational [Page 34] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[34ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
5.1.2.1. Origination End Initiates the Release
5.1.2.1. 創作終わりはリリースを開始します。
The following call flow shows an example where the origination end initiates the release for the "MS" package (similar for "DT" Package).
以下の呼び出し流動は、創作終わりが「さん」パッケージ("DT"パッケージに、同様の)のためにどこでリリースを開始するかを例に示します。
--------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|-------------------------------------------------------------------- |
| A1 | NTFY[O: ms/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: ms/rel, R: ms/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: ms/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: ms/rlc, R: ms/sup] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: ms/sup]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
-------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |-------------------------------------------------------------------- | | A1| NTFY[O: ms/rel]->。| | A2| <。 Ack| | A3| RQNT[S: ms/rel、R: ms/rlc]->。| | A4| <。 Ack| | A5| <。 NTFY[O: ms/rlc]| | A6| Ack->。| | A7| <。 DLCX[S: ms/rlc、R: ms/一口]| | A8| Ack[perfインフォメーション]->。| | A9| DLCX[R: ms/一口]->。| | A10| <。 Ack[perfインフォメーション]| ---------------------------------------------------------------------
The same call flow for the "BL" package is shown below
"BL"パッケージのための同じ呼び出し流動は以下に示されます。
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: bl/hu] -> |
| A2 | <- Ack |
| A3 | RQNT [S: bl/dl, R: bl/hu] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: bl/hu] |
| A6 | Ack -> |
| A7 | <- DLCX [R: bl/hd] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: bl/hd]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[O: bl/hu]->。| | A2| <。 Ack| | A3| RQNT[S: bl/dl、R: bl/hu]->。| | A4| <。 Ack| | A5| <。 NTFY[O: bl/hu]| | A6| Ack->。| | A7| <。 DLCX[R: bl/hd]| | A8| Ack[perfインフォメーション]->。| | A9| DLCX[R: bl/hd]->。| | A10| <。 Ack[perfインフォメーション]| ---------------------------------------------------------------------
Step A1 The originating user goes on-hook resulting in a Notify from the gateway to indicate that the trunk is being released (reason indicating normal release)
トランクが解放されているのを示すためにゲートウェイからのNotifyとなって、由来しているユーザのステップA1はフックに行きます。(通常のリリースを示す理由)
NTFY 3005 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 45375842
O: ms/rel(0) (or dt/rel(0) or bl/hu)
NTFY3005 ds/ds1-3/6@gw-o.whatever.net MGCP1.0X: 45375842○: ms/rel(0)(または、dt/rel(0)かbl/hu)
Foster Informational [Page 35] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[35ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A2 The Call Agent Acks the Notify
A2呼び出しエージェントAcksを踏んでください、通知
200 3005 OK
3005が承認する200
Step A3 The Call Agent sends a request to release the trunk. (For all but Basic PBX.)
ステップA3Callエージェントはトランクを解放するという要求を送ります。 (Basic PBX以外のすべてのための。)
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: ms/rel (or dt/rel)
R: ms/rlc (or dt/rlc)
RQNT4004 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375843秒間: ms/rel(または、dt/rel)R: ms/rlc(または、dt/rlc)
For the Basic PBX ("BL" package), dial-tone is played
Basic PBX("BL"パッケージ)に関しては、ダイヤルトーンはプレーされます。
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: bl/dl
R: bl/hu
RQNT4004 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375843秒間: bl/dl R: bl/hu
Step A4 The Gateways acks the request
ステップA4Gateways acksは要求です。
200 4004 OK
4004が承認する200
Step A5 The other end releases the call by going on-hook and a Notify is sent to the Call Agent to indicate that release is complete.
他が終わらせるステップA5はフックに行くことによって、呼び出しをリリースします、そして、リリースが完全であることを示すためにCallエージェントにNotifyを送ります。
NTFY 1004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
O: ms/rlc (or dt/rlc)
NTFY1004 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375843○: ms/rlc(または、dt/rlc)
In the case of Basic PBX, this is:
Basic PBXの場合では、これは以下の通りです。
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375843
O: bl/hu
NTFY1004 ds/ds1-5/3@gw-o.whatever.net MGCP1.0X: 45375843○: bl/hu
Step A6 The Call Agent returns an Ack
ステップA6CallエージェントはAckを返します。
200 1004 OK
1004が承認する200
Foster Informational [Page 36] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[36ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A7 The Call Agent sends a delete connection to the originating gateway with a request to do a release complete (which results in sending on-hook to the PBX).
Callエージェントがaを送るステップA7は完全な状態でリリースをするという要求(PBXへのオンフックの発信におけるどの結果)で由来しているゲートウェイに接続を削除するか。
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
S: ms/rlc (or dt/rlc)
R: ms/sup (or dt/sup)
DLCX4005 ds/ds1-5/3@gw-o.whatever.net MGCP1.0X: 45375844、私: 34738A S: ms/rlc(または、dt/rlc)R: ms/一口(または、dt/一口)
Or in the case of Basic PBX ("BL" package):
または、Basic PBX("BL"パッケージ)の場合で:
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
R: bl/hd
DLCX4005 ds/ds1-5/3@gw-o.whatever.net MGCP1.0X: 45375844、私: 34738A R: bl/hd
Step A8 The Gateway Acks and provides performance information.
A8ゲートウェイAcksを踏んで、性能情報を提供します。
250 4005 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
250 4005はPを承認します: PS=1245、OS=62345、PR=0、または=0、PLが0、JI=0、LA=48と等しいです。
Step A9 The Call Agent sends a DLCX to the terminating gateway.
ステップA9Callエージェントは終わりゲートウェイにDLCXを送ります。
DLCX 2004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 0123456789B3
I: 23474FE
R: ms/sup (or dt/sup or bl/hd)
DLCX2004 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 0123456789B3I: 23474FE R: ms/一口(または、dt/一口かbl/hd)
Step A10 The gateway acks with performance information
ステップA10は性能情報があるゲートウェイacksです。
250 2004 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
250 2004はPを承認します: PS=1245、OS=62345、PR=0、または=0、PLが0、JI=0、LA=48と等しいです。
Foster Informational [Page 37] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[37ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
5.1.2.2. Termination End Initiates the Release
5.1.2.2. 終了終わりはリリースを開始します。
The following call flow gives an example of the terminating end
releasing a call for all but Basic PBX ("MS" package - "DT" package
is similar).
以下の呼び出し流動は終わり終わりのすべてのための呼び出しをリリースしますが、Basic PBXを作例を示します。(「さん」パッケージ--"DT"パッケージは同様です)。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | <- NTFY[O: ms/sus] | | A2 | Ack -> | | A3 | <- RQNT [S: ms/sus, R: ms/rel ] | | A4 | Ack -> | | A5 | RQNT [R: ms/res] -> | | A6 | <- Ack | | A7 | NTFY [O: ms/rel] -> | | A8 | <- Ack | | A9 | DLCX [S: ms/rel, R: ms/rlc] -> | | A10 | <- Ack [perf info] | | A11 | <- Notify [O: ms/rlc] | | A12 | Ack -> | | A13 | <- DLCX [S: ms/rlc, R: ms/sup ] | | A14 | Ack [perf info] -> | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| <。 NTFY[O: ms/sus]| | A2| Ack->。| | A3| <。 RQNT[S: ms/sus、R: ms/rel]| | A4| Ack->。| | A5| RQNT[R: ms/res]->。| | A6| <。 Ack| | A7| NTFY[O: ms/rel]->。| | A8| <。 Ack| | A9| DLCX[S: ms/rel、R: ms/rlc]->。| | A10| <。 Ack[perfインフォメーション]| | A11| <。 通知してください[O: ms/rlc]。| | A12| Ack->。| | A13| <。 DLCX[S: ms/rlc、R: ms/一口]| | A14| Ack[perfインフォメーション]->。| ---------------------------------------------------------------------
The following shows the same call flow but for Basic PBX. There is no equivalent to steps A3-A6 and A11-A12 - so these are not included.
同じ呼び出し流動にもかかわらず、Basic PBXのための以下のショー。 これらが含まれていなくて、ステップのA3-A6とA11-A12と同等物が全くありません。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | <- NTFY[O: bl/hu] | | A2 | Ack -> | | A7 | NTFY [O: bl/hu] -> | | A8 | <- Ack | | A9 | DLCX [R: bl/hd] -> | | A10 | <- Ack [perf info] | | A13 | <- DLCX [bl/hd] | | A14 | Ack [perf info] -> | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| <。 NTFY[O: bl/hu]| | A2| Ack->。| | A7| NTFY[O: bl/hu]->。| | A8| <。 Ack| | A9| DLCX[R: bl/hd]->。| | A10| <。 Ack[perfインフォメーション]| | A13| <。 DLCX[bl/hd]| | A14| Ack[perfインフォメーション]->。| ---------------------------------------------------------------------
Step A1 An on-hook is received from the PBX. In the case of all but the "BL" package, this results in a notify with event "sus" for suspend.
フックの上にPBXからステップA1 Anを受け取ります。 "BL"パッケージ、中のこの結果以外のaがイベント"sus"で通知するすべてに関するケース、中断します。
Foster Informational [Page 38] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[38ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A2 The Call Agent returns an acknowledge
ステップA2Callエージェントが戻る、承認
The Call Agent starts a timer at this point (typically 10
seconds). If an off-hook is received from the PBX connected to
GW-t before the origination side releases, the call is continued
(this would appear as a "res" event or "hd" in the case of Basic
PBX interface). If the origination side goes on-hook or the
timer expires, then the call is torn down.
Callエージェントはここ(通常10秒)にタイマを始動します。 創作サイドリリースの前にGW-tに接続されたPBXからオフフックを受け取るなら、呼び出しを続けています(これは"res"出来事か"hd"としてBasic PBXインタフェースの場合に現れるでしょう)。 創作側がフックに行くか、またはタイマが期限が切れるなら、呼び出しを取りこわします。
Note that for Basic PBX (the "BL" package), steps A3 - A6 are
missing (these steps do not exist for basic PBX).
Basic PBX("BL"パッケージ)のためにA3を踏む注意--A6はなくなっています(これらのステップは基本的なPBXのために存在していません)。
Step A3 A "sus" signal is sent to the originating side resulting in a on-hook being sent to the originating PBX.
フックにおける由来しているPBXに送られた存在をもたらす由来側にステップA3A"sus"信号を送ります。
Step A4 GW-o acks the request.
A4 GW-o acksを踏んでください。要求。
Step A5 The Call Agent sends a request to see off-hook or resume
("res") events.
ステップA5Callエージェントはオフフックを見るか、または("res")出来事を再開するという要求を送ります。
Note: this depends on whether the Call Agent wants to do suspend/resume processing. If not, the Call Agent may simply send "rel" along with DLCX to both ends.
以下に注意してください。 これはCallエージェントが、処理するのを中断したいか、または再開したがっているかどうかによります。 そうでなければ、Callエージェントは単にDLCXに伴う"rel"を両端に送るかもしれません。
Step A6 GW-t acks the request.
A6 GW-t acksを踏んでください。要求。
Step A7 An on-hook is received from the originating PBX resulting
in a notify from GW-o with event "rel" ("hu" for Basic PBX
interface).
フックの上にaをもたらすとイベント"rel"(Basic PBXインタフェースへの"hu")でGW-oから通知される由来しているPBXからステップA7 Anを受け取ります。
Step A8 The Call Agent "acks"
ステップA8呼び出しエージェント"acks"
Step A9 A delete connection is sent to the terminating gateway with signal "rel" which results in on-hook being sent to the terminating PBX (except for basic PBX - where there is no such signal)
ステップA9Aが削除する、フックにおける終わりに送られた存在をもたらす"rel"という信号PBXと共に終わりゲートウェイに接続を送ります。(どんなそのような信号もないところの基本的なPBXを除いた)
Step A10 GW-t acks the DLCX and provides performance information
ステップ、A10 GW-tは、DLCXをacksして、性能情報を提供します。
Steps A11 and A12 do not exist for the basic PBX case.
ステップのA11とA12は基本的なPBXケースのために存在していません。
Step A11 GW-t returns an "rlc" event
A11 GW-tが"rlc"出来事を返すステップ
Step A12 The Call Agent "acks" the notify
A12Callエージェント"acks"を踏んでください、通知
Step A13 A delete connection is sent to the originating side (with signal "rlc" except in the case of the "BL" package).
ステップA13Aは接続を削除します。由来側("BL"パッケージに関するケースを除いた信号"rlc"がある)に送ります。
Step A14 GW-o returns an "ack" with performance information.
ステップA14 GW-oは性能情報がある"ack"を返します。
Foster Informational [Page 39] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[39ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
5.2. Example Call Flows - "DO" package
5.2. 例のCall Flows--「してください」というパッケージ
5.2.1. Call Setup Flows
5.2.1. 呼び出しセットアップは流れます。
The following describes some PBX to PBX call. The table gives an overview of the initial part of the call flow with details to follow.
以下はいくらかのPBXについてPBX呼び出しに説明します。 テーブルは、続くように詳細がある呼び出し流動の初期の部分の概観を与えます。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | NTFY[O: do/rg] -> | | A2 | <- Ack | | B1 | <- CRCX [S: do/hd, R: do/rel, M:recvonly, LCO] | | B2 | Ack[SDP1] -> | | B3 | CRCX [M:sendrecv, LCO, SDP1] -> | | B4 | <- Ack [SDP2] | | B5 | <- MDCX [recvonly,SDP2] | | B6 | Ack -> | | C1 | RQNT [S: do/sup, R: do/oc] -> | | C2 | <- Ack | | C3 | <- NTFY [O:do/oc(do/sup)]| | C4 | Ack -> | | C5 | <- MDCX [M:sendrecv, R: do/rel] | | C6 | Ack -> | | C7 | RQNT[R: do/rel] -> | | C8 | <- Ack | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[O: /rgをする]->。| | A2| <。 Ack| | B1| <。 CRCX[S: /hd、Rをしてください: /rel、M: recvonly、LCOをしてください]| | B2| Ack[SDP1]->。| | B3| CRCX[M: sendrecv、LCO、SDP1]->。| | B4| <。 Ack[SDP2]| | B5| <。 MDCX[recvonly、SDP2]| | B6| Ack->。| | C1| RQNT[S: R、するか、またはすすってください: /ocをする]->。| | C2| <。 Ack| | C3| <。 NTFY[O: /ocをしてください(するか、またはすすってください)]| | C4| Ack->。| | C5| <。 MDCX[M: sendrecv、R: /relをしてください]| | C6| Ack->。| | C7| RQNT[R: /relをする]->。| | C8| <。 Ack| ---------------------------------------------------------------------
Step A1 PBX rings results in a notify to the Call Agent indicating the start of a call setup:
aの結果が呼び出しセットアップの始まりを示すCallエージェントに通知するA1 PBXリングを踏んでください:
NTFY 3001 aaln/0@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: do/rg
NTFY3001 aaln/0@gw-o.whatever.net MGCP1.0X: 0123456789AF O: /rgをしてください。
Step A2 The Call Agent sends an Ack:
ステップA2CallエージェントはAckを送ります:
Step B1 The Call Agent now requests that a receive-only connection be made.
ステップB1Callエージェントは、現在、受信専用接続が作られているよう要求します。
If the endpoint is running FXO ground-start, the call would also
request detection of disconnect supervision from the PBX (R:
do/rel) and should send an off-hook (S: do/hd) in response to
ringing.
終点がFXO地面始めを走らせているなら、呼び出しは、また、PBXから分離指揮の検出を要求して(R: /relをしてください)、鳴ることに対応してオフフックを送るべきです(S: /hdをしてください)。
Step B2 The Gateway acks with a connection ID and provides the SDP information.
接続IDと共にB2ゲートウェイacksを踏んで、SDP情報を提供します。
Foster Informational [Page 40] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[40ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
ステップB3Callエージェントは接続要求の一部として終わりゲートウェイ(GW-t)にこのSDP情報を通過します。
Step B4 The terminating gateway, responds with an ack and its SDP information.
B4を踏んでください、ゲートウェイを終えて、ackとそのSDPと共に情報を反応させます。
Step B5 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
B5 Callエージェントがaを送るステップは、終了ゲートウェイから接続モードが受信専用である状態で創作ゲートウェイに接続要求を変更して、選択されたプロフィールでSDP情報を含んでいます。
Step B6 The Gateway Acks the modify connection request
B6ゲートウェイAcksを踏んでください、接続要求を変更してください。
Step C1 The Call Agent does a setup request to the terminating gateway The setup request will be the following:
CallエージェントがセットアップをするステップC1は、セットアップ要求が以下になるよう終わりゲートウェイに要求します:
RQNT 4002 aaln/0@gw-t.whatever.net MGCP 1.0
X: 45375841
S: do/sup(addr(5,5,5,1,2,3,4))
R: do/oc
RQNT4002 aaln/0@gw-t.whatever.net MGCP1.0X: 45375841秒間: (addr(5、5、5、1、2、3、4))Rをするか、またはすすってください: /ocをしてください。
Note that the result of the "sup" signal is the following
sequence on the interface to the PBX:
「一口」信号の結果がPBXへのインタフェースの以下の系列であることに注意してください:
* off-hook -> PBX
* tip-ground <- PBX (for loop-start this step does not apply)
* digits sent to PBX
* PBXに送られたオフフック->PBX*チップ地面<PBX(輪始めに、このステップは適用されない)*ケタ
Step C2 The gateway responds with an ack:
ゲートウェイがackで反応させるC2を踏んでください:
200 4002 OK
4002が承認する200
Step C3 When the digits have been completely sent out, the gateway will notify the fact by indicate that the operation is complete.
アウト、ゲートウェイは、ケタが完全に送られたステップC3 Whenが、操作が完全であることを示すように事実に通知するでしょう。
NTFY 1001 aaln/0@gw-t.whatever.net MGCP 1.0
X: 45375841
O: do/oc(do/sup)
NTFY1001 aaln/0@gw-t.whatever.net MGCP1.0X: 45375841○: /ocをしてください。(するか、またはすすります)
Step C4 The Call Agent acks the notify
C4Callエージェントacksを踏んでください、通知
200 1001 OK
1001が承認する200
Foster Informational [Page 41] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[41ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step C5 The Call Agent now sends a request to make the connection full duplex and indicates that the other end has answered the phone.
ステップC5Callエージェントは、現在、接続全二重を作るという要求を送って、もう一方の端が電話に出たのを示します。
If the endpoint is running FXO ground-start, the call would also
requests detection of disconnect supervision from the PBX
(R:do/rel)
また、終点がそうなら、FXO地面始め、呼び出しがそうする走行はPBXから分離指揮の検出を要求します。(R: /relをしてください)
Step C6 The Gateway acks the request
ステップC6ゲートウェイacksは要求です。
Step C7 If the endpoint is running FXO ground-start, the Call Agent sends a notification request to be told when the trunk to be released (R: do/rel). This step and step C8 are not needed if the endpoint is running FXO loop-start.
C7 Ifを踏んでください。終点はFXO地面始めを走らせていて、Callエージェントは、リリースされるためにトランクであるときに言われる通知要求を送ります(R: /relをしてください)。 終点がFXO輪始めを走らせているなら、このステップとステップC8は必要ではありません。
Step C8 The gateway acks the request and the call is now setup.
ゲートウェイがacksするC8を踏んでください。現在、要求と呼び出しはセットアップです。
5.2.2. Call Tear-Down
5.2.2. 分解に電話をしてください。
If the endpoint is running FXO loop-start, the PBX cannot initiate call release. In this case, call release is always initiated by the Media Gateway by going onhook. Disconnect supervision from the PBX is provided only for FXO ground-start. However, it does not matter whether the origination end or the termination end initiates the release. The call flows for either case are the same. Therefore, only the case where the origination end initiates the release is illustrated in this section.
終点がFXO輪始めを走らせているなら、PBXは呼び出しリリースを開始できません。 この場合、呼び出しリリースはいつも行っているonhookによってメディアゲートウェイによって開始されます。 PBXからの分離指揮をFXO地面始めだけに提供します。 しかしながら、創作終わりか終了終わりがリリースを開始するかどうかは重要ではありません。 どちらかのケースのための呼び出し流れは同じです。 創作終わりがリリースを開始するケースだけがこのセクションで例証されます。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | NTFY[O: do/rel] -> | | A2 | <- Ack | | A3 | RQNT [S: do/hu, R: do/rlc] -> | | A4 | <- Ack | | A5 | <- NTFY [O: do/rlc] | | A6 | Ack -> | | A7 | <- DLCX [S: hu, R: rg] | | A8 | Ack [perf info] -> | | A9 | DLCX [R: do/rg]-> | | A10 | <- Ack [perf info] | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[O: /relをする]->。| | A2| <。 Ack| | A3| RQNT[S: /hu、Rをしてください: /rlcをする]->。| | A4| <。 Ack| | A5| <。 NTFY[O: /rlcをしてください]| | A6| Ack->。| | A7| <。 DLCX[S: hu、R: rg]| | A8| Ack[perfインフォメーション]->。| | A9| DLCX[R: /rgをする]->。| | A10| <。 Ack[perfインフォメーション]| ---------------------------------------------------------------------
Foster Informational [Page 42] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[42ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A1 The originating PBX goes on-hook resulting in a Notify from the gateway to indicate that the trunk is being released (reason indicating normal release).
トランクが解放されているのを(通常のリリースを示す理由)示すためにゲートウェイからのNotifyとなって、ステップA1の由来しているPBXはフックに行きます。
NTFY 3005 aaln/0@gw-o.whatever.net MGCP 1.0
X: 45375842
O: do/rel(0)
NTFY3005 aaln/0@gw-o.whatever.net MGCP1.0X: 45375842○: /relをしてください。(0)
Step A2 The Call Agent Acks the Notify
A2呼び出しエージェントAcksを踏んでください、通知
200 3005 OK
3005が承認する200
Step A3 The Call Agent sends a request to release the trunk.
ステップA3Callエージェントはトランクを解放するという要求を送ります。
Step A4 The Gateways acks the request
ステップA4Gateways acksは要求です。
Step A5 PBX at the terminating end releases the call by releasing tip-ground and a Notify is then sent to the Call Agent to indicate that release is complete.
終わり終わりのステップA5 PBXはチップ地面をリリースすることによって、呼び出しをリリースします、そして、次に、リリースが完全であることを示すためにCallエージェントにNotifyを送ります。
Note that there is no ground signal in case of loop-start.
However, this NTFY message is still generated as soon as hu
signal is applied.
地上信号機が全く輪始めの場合にないことに注意してください。 しかしながら、hu信号が適用されているとすぐに、このNTFYメッセージはまだ発生しています。
Step A6 The Call Agent returns an Ack
ステップA6CallエージェントはAckを返します。
Step A7 The Call Agent sends a delete connection to the originating gateway with a request to go onhook.
Callエージェントがaを送るステップA7はonhookしに行くという要求で由来しているゲートウェイに接続を削除します。
Step A8 The Gateway Acks and provides performance information.
A8ゲートウェイAcksを踏んで、性能情報を提供します。
Step A9 The Call Agent sends a DLCX to the terminating gateway.
ステップA9Callエージェントは終わりゲートウェイにDLCXを送ります。
Step A10 The gateway acks with performance information
ステップA10は性能情報があるゲートウェイacksです。
Foster Informational [Page 43] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[43ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
5.3. Example Call Setup - "MD" Package
5.3. 例の呼び出しセットアップ--「MD」パッケージ
The following describes Feature Group D call setup using the "MD" package. The table gives an overview of the initial part of the call flow with details to follow.
以下は、「MD」パッケージを使用することでFeature Group D呼び出しセットアップについて説明します。 テーブルは、続くように詳細がある呼び出し流動の初期の部分の概観を与えます。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | NTFY[O:md/sup] -> | | A2 | <- Ack | | A3 | NTFY[O:md/inf(<id>)] -> | | A4 | <- Ack | | A5 | NTFY[O:md/inf(<addr>)] -> | | A6 | <- Ack | | B1 | <- CRCX [M:recvonly, LCO, R: md/rel] | | B2 | Ack[SDP1] -> | | B3 | CRCX [M:sendrecv, LCO, SDP1] -> | | B4 | <- Ack [SDP2] | | B5 | <- MDCX [recvonly,SDP2] | | B6 | Ack -> | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[O: Md/一口]->。| | A2| <。 Ack| | A3| NTFY[O: Md/inf(<イド>)]->。| | A4| <。 Ack| | A5| NTFY[O: Md/inf(<addr>)]->。| | A6| <。 Ack| | B1| <。 CRCX[M: recvonly、LCO、R: Md/rel]| | B2| Ack[SDP1]->。| | B3| CRCX[M: sendrecv、LCO、SDP1]->。| | B4| <。 Ack[SDP2]| | B5| <。 MDCX[recvonly、SDP2]| | B6| Ack->。| ---------------------------------------------------------------------
The assumption is that prior to the initial "notify", the Call Agent has sent a request to be informed of "sup" and "inf" events using quarantine handling "Q: loop".
初期の前のそれが「通知してください」であるという仮定、Callエージェントが隔離取り扱いを使用することで「一口」と"inf"出来事において知識があるという要求を送った、「Q:」 「輪にしてください。」
Step A1 Trunk seizure results in a notify to the Call Agent indicating the start of a call setup:
aのステップA1 Trunk捕獲結果は呼び出しセットアップの始まりを示すCallエージェントに通知します:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
NTFY3001 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/一口
Step A2 The Call Agent sends an Ack.
ステップA2CallエージェントはAckを送ります。
Step A3 Once the digits for the identification field are collected the gateway notifies the call agent:
A3 Onceを踏んでください。識別分野へのケタは集められて、ゲートウェイが呼び出しエージェントに通知するということです:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
NTFY3002 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/inf(k0、0、0、4、0、8、5、5、5、1、2、3、4、s0)
Step A4 The Call Agent responds with an ack.
ステップA4Callエージェントはackで応じます。
Foster Informational [Page 44] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[44ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A5 When the digits are collected for the address field, another notify is sent:
A5 Whenを踏んでください、別のものが、ケタがアドレス・フィールドに集められるように通知する、送ります:
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
NTFY3003 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/inf(k0、5、1、2、5、5、5、4、5、6、7、s0)
Step A6 The Call Agent "acks"
ステップA6呼び出しエージェント"acks"
Step B1 Create connection - receive only:
ステップB1 Create接続--受信専用:
CRCX 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
C: A3C47F21456789F1
L: p:10, a:PCMU
M: sendrecv
X: 0123456789B1
R: md/rel
CRCX2002 ds/ds1-3/6@mgw45.whatever.net MGCP1.0C: A3C47F21456789F1L: p: 10 : PCMU M: sendrecv X: 0123456789B1R: Md/rel
Step B2 The Gateway "acks" the request and provides connection ID and SDP information.
ステップB2ゲートウェイは、要求が"acksする"であり、接続IDとSDPに情報を供給します。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
ステップB3Callエージェントは接続要求の一部として終わりゲートウェイ(GW-t)にこのSDP情報を通過します。
Step B4 The terminating gateway, responds with an ack and its SDP information.
B4を踏んでください、ゲートウェイを終えて、ackとそのSDPと共に情報を反応させます。
Step B5 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
B5 Callエージェントがaを送るステップは、終了ゲートウェイから接続モードが受信専用である状態で創作ゲートウェイに接続要求を変更して、選択されたプロフィールでSDP情報を含んでいます。
Step B6 The Gateway Acks the modify connection request.
B6ゲートウェイAcksを踏んでください、接続要求を変更してください。
Foster Informational [Page 45] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[45ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
In the case of EAIN signaling there is some additional information provided so that this initial part of the call setup looks slightly different:
EAINがそこで合図する場合では、何らかの追加情報を提供するので、呼び出しセットアップのこの初期の部分はわずかに異なるように見えます:
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | NTFY[O:md/sup] -> | | A2 | <- Ack | | A3 | NTFY[O:md/inf(<ca>)] -> | | A4 | <- Ack | | A5 | <- RQNT[S:md/cwk, R:md/inf,md/rel] | | A6 | <- Ack | | A7 | NTFY[O:md/inf(<id>)] -> | | A8 | <- Ack | | A9 | NTFY[O:md/inf(<addr>)] -> | | A10 | <- Ack | | B1 | <- CRCX [M:recvonly, LCO, R: md/rel] | | B2 | Ack[SDP1] -> | | B3 | CRCX [M:sendrecv, LCO, SDP1] -> | | B4 | <- Ack [SDP2] | | B5 | <- MDCX [recvonly,SDP2] | | B6 | Ack -> | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[O: Md/一口]->。| | A2| <。 Ack| | A3| NTFY[O: Md/inf(<ca>)]->。| | A4| <。 Ack| | A5| <。 RQNT[S: Md/cwk、R: Md/inf、Md/rel]| | A6| <。 Ack| | A7| NTFY[O: Md/inf(<イド>)]->。| | A8| <。 Ack| | A9| NTFY[O: Md/inf(<addr>)]->。| | A10| <。 Ack| | B1| <。 CRCX[M: recvonly、LCO、R: Md/rel]| | B2| Ack[SDP1]->。| | B3| CRCX[M: sendrecv、LCO、SDP1]->。| | B4| <。 Ack[SDP2]| | B5| <。 MDCX[recvonly、SDP2]| | B6| Ack->。| ---------------------------------------------------------------------
The assumption is that prior to the initial "notify", the Call Agent has sent a request to be informed of "sup" and "inf" events using quarantine handling "Q: loop".
初期の前のそれが「通知してください」であるという仮定、Callエージェントが隔離取り扱いを使用することで「一口」と"inf"出来事において知識があるという要求を送った、「Q:」 「輪にしてください。」
Step A1 Trunk seizure results in a notify to the Call Agent indicating the start of a call setup:
aのステップA1 Trunk捕獲結果は呼び出しセットアップの始まりを示すCallエージェントに通知します:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
NTFY3001 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/一口
Step A2 The Call Agent sends an Ack
ステップA2CallエージェントはAckを送ります。
Step A3 The initial digit string contains the country address field:
初期のケタのA3が結ぶステップは国のアドレス・フィールドを含んでいます:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,1,3,8,9,9,0,0,1,9,s0)
NTFY3002 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/inf(k0、1、3、8、9、9、0、0、1、9、s0)
Step A4 The Call Agent responds with an ack
ステップA4Callエージェントはackで応じます。
Foster Informational [Page 46] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[46ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A5 The Call Agent does processing on the country address field and sends a request to initiate further input (sends a continue wink):
ステップA5Callエージェントが国のアドレス・フィールドで処理をして、さらなる入力を開始するという要求を送る、(発信、aがウインクを続けている、)、:
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/inf,md/rel
S: md/cwk
RQNT2002 ds/*@mgw45.whatever.net MGCP1.0X: 0123456789B1Q: 輪R: Md/inf、Md/rel S: Md/cwk
Step A6 The Gateway "acks" the request.
ステップA6ゲートウェイは要求を"acksする"です。
Step A7 Once the digits for the identification field are collected the gateway notifies the call agent:
A7 Onceを踏んでください。識別分野へのケタは集められて、ゲートウェイが呼び出しエージェントに通知するということです:
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
NTFY3003 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/inf(k0、0、0、4、0、8、5、5、5、1、2、3、4、s0)
Step A8 The Call Agent responds with an ack
ステップA8Callエージェントはackで応じます。
Step A9 When the digits are collected for the address field, another notify is sent:
A9 Whenを踏んでください、別のものが、ケタがアドレス・フィールドに集められるように通知する、送ります:
NTFY 3004 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
NTFY3004 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/inf(k0、5、1、2、5、5、5、4、5、6、7、s0)
Step A10 The Call Agent "acks"
ステップA10呼び出しエージェント"acks"
Step B1 Create connection - receive only:
ステップB1 Create接続--受信専用:
CRCX 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
C: A3C47F21456789F1
L: p:10, a:PCMU
M: sendrecv
X: 0123456789B1
R: md/rel
CRCX2002 ds/ds1-3/6@mgw45.whatever.net MGCP1.0C: A3C47F21456789F1L: p: 10 : PCMU M: sendrecv X: 0123456789B1R: Md/rel
Step B2 The Gateway "acks" the request and provides connection ID and SDP information
ステップB2ゲートウェイは、要求が"acksする"であり、接続IDとSDPに情報を供給します。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
ステップB3Callエージェントは接続要求の一部として終わりゲートウェイ(GW-t)にこのSDP情報を通過します。
Step B4 The terminating gateway, responds with an ack and its SDP information
B4を踏んでください、ゲートウェイを終えて、ackとそのSDPと共に情報を反応させます。
Foster Informational [Page 47] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[47ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step B5 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
B5 Callエージェントがaを送るステップは、終了ゲートウェイから接続モードが受信専用である状態で創作ゲートウェイに接続要求を変更して、選択されたプロフィールでSDP情報を含んでいます。
Step B6 The Gateway Acks the modify connection request
B6ゲートウェイAcksを踏んでください、接続要求を変更してください。
The following table shows the remainder of the call flow to set up the call for FGD EANA.
以下のテーブルは、FGD EANAのために呼び出しをセットアップするために呼び出し流動の残りを示しています。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | C1 | RQNT [S:sup, R:md/swk,md/oc, md/rel,md/awk, md/ans] ->| | C2 | <- Ack | | C3 | <- NTFY [O:md/swk)] | | C4 | Ack -> | | C5 | <- NTFY [O:md/oc(md/sup)]| | C6 | Ack -> | | C7 | <- NTFY [O:md/awk)] | | C8 | Ack -> | | C9 | <- RQNT[S:md/awk] | | C10 | Ack -> | | C11 | <- NTFY [O: md/ans] | | C12 | Ack -> | | C13 | <- MDCX [M:sendrecv, S: md/ans, R: md/rel] | | C14 | Ack -> | | C15 | RQNT [R: md/sus, md/rel] -> | | C16 | <- Ack | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | C1| RQNT[S: 一口、R: Md/swk、Md/oc、Md/rel、Md/awk、Md/ans]、->|、| C2| <。 Ack| | C3| <。 NTFY[O: Md/swk]| | C4| Ack->。| | C5| <。 NTFY[O: Md/oc(Md/一口)]| | C6| Ack->。| | C7| <。 NTFY[O: Md/awk]| | C8| Ack->。| | C9| <。 RQNT[S: Md/awk]| | C10| Ack->。| | C11| <。 NTFY[O: Md/ans]| | C12| Ack->。| | C13| <。 MDCX[M: sendrecv、S: Md/ans、R: Md/rel]| | C14| Ack->。| | C15| RQNT[R: Md/sus、Md/rel]->。| | C16| <。 Ack| ---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the terminating gateway The setup request for an MF EANA FGD interface will be the following:
ステップC1CallエージェントはMF EANA FGDインタフェースを求めるセットアップ要求が以下になるという終わりゲートウェイへのセットアップ要求をします:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:
md/sup(ct(nda),addr(k0,5,5,5,5,2,2,1,2,3,4,s0),id(k0,0,5,5,5,1,
2,3,4,s2))
R: md/swk,md/oc,md/rel,md/awk,md/ans
RQNT2001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841、Q: 輪S: Md/一口(ct(nda)、addr(k0、5、5、5、5、2、2、1、2、3、4、s0)、イド(k0、0、5、5、5、1、2、3、4、s2))R: Md/swk、Md/oc、Md/rel、Md/awk、Md/ans
Foster Informational [Page 48] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[48ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Note that the result of the "sup" signal is the following
sequence on the interface to the PBX:
「一口」信号の結果がPBXへのインタフェースの以下の系列であることに注意してください:
* off-hook -> SCN
* wink <- SCN
* caller ID digits sent to SCN
* address digits sent to SCN
* SCN*発信者番号ケタがSCNに送られたSCN*アドレスケタに送ったオフフック->SCN*ウインク<。
Step C2 The gateway responds with an ack
ゲートウェイがackで反応させるステップC2
Step C3 "Notify" the CA that the start of signaling has occurred (incoming wink start has occurred) i.e.:
ステップC3が、シグナリングの始まりが起こったことを(入って来るウインク始めは起こりました)カリフォルニアに「通知する」、すなわち:
NTFY 3000 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/swk
NTFY3000 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/swk
Step C4 The Call Agent "acks".
C4呼び出しエージェント"acks"を踏んでください。
Step C5 "Notify" that out-pulsing is complete:
脈打つのから完全なステップC5は「通知します」:
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/oc(md/sup)
NTFY3001 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/oc(Md/一口)
Step C6 The Call Agent "acks".
C6呼び出しエージェント"acks"を踏んでください。
Step C7 "Notify" that the acknowledgement wink has been received:
C7が、承認をウインクさせるように「通知する」というステップを受けました:
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/awk
NTFY3002 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/awk
Step C8 The Call Agent "acks".
C8呼び出しエージェント"acks"を踏んでください。
Step C9 The acknowledge wink is passed to the originating gateway:
C9を踏んでください、ウインクが由来しているゲートウェイに通過されると認めてください:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
S: md/awk
R: md/rel
RQNT2001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375842秒間: Md/awk R: Md/rel
Step C10 GW-o "acks".
C10 GW-o"acks"を踏んでください。
Foster Informational [Page 49] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[49ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step C11 "Notify" off-hook event (the person at the other end has answered):
ステップC11はオフフック出来事に「通知する」(もう一方の端の人は答えました):
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/ans
NTFY3003 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B0O: Md/ans
Step C12 The Call Agent "acks".
C12呼び出しエージェント"acks"を踏んでください。
Step C13 The Call Agent now sends a request to make the connection full duplex and indicates that the other end has answered the phone (S: ans sent)
ステップC13Callエージェントは、現在、接続全二重を作るという要求を送って、もう一方の端が電話に出たのを示します。(S: 送られたans)
Step C14 The Gateway acks the request
ステップC14ゲートウェイacksは要求です。
In the case of FGD EAIN, there is an additional digits string
(country address and/or carrier access code that has to be
included so that step C1 looks like the following in a case where
there is no overlapped sending:
FGD EAINの場合には、追加ケタストリングがある、(ステップC1が場合で以下に似ていて、発信が重ね合わせられないところにそれが含まれるように持っている国のアドレス、そして/または、キャリヤーアクセスコード:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:md/sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,
0,5,5,5,1,2,3,4,s0),addr(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0))
R: md/swk,md/oc,md/rel,md/awk,md/ans
RQNT2001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0X: 45375841、Q: S: Md/一口(ct(nta)、ca(k0、1、3、8、9、9、0、0、1、0、s0)、イド(k0、0、5、5、5、1、2、3、4、s0)、addr(ko、0、1、1、3、8、1、2、3、4、7、6、5、s0))Rを輪にしてください: Md/swk、Md/oc、Md/rel、Md/awk、Md/ans
If overlapped sending is done, only the country address and
caller ID digit strings are sent out in step C1:
重ね合わせられた送付が完了しているなら、ステップC1で国のアドレスと発信者番号ケタストリングだけを出します:
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
RQNT2001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0
X: 45375841
Q: loop
S:md/sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,0,
5,5,5,1,2,3,4,s0))
R: md/swk,md/oc,md/rel,md/ans
X: 45375841、Q: S: Md/一口(ct(nta)、ca(k0、1、3、8、9、9、0、0、1、0、s0)、イド(k0、0、5、5、5、1、2、3、4、s0))Rを輪にしてください: Md/swk、Md/oc、Md/rel、Md/ans
Then after these digits go out indicated by event "oc(sup)" in
step C5, and as soon as the Call Agent has the address
information, it sends it out using the "inf" signal:
次に、これらのケタがステップC5のイベント「oc(一口)」で示された状態で出かけて、Callエージェントにアドレス情報があるとき同じくらいすぐ出かけた後に、"inf"信号を使用することでそれを出します:
RQNT 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/oc,md/rel,md/awk,md/ans
S: md/inf(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0)
RQNT2002 ds/ds1-3/6@mgw45.whatever.net MGCP1.0X: 0123456789B1Q: 輪R: Md/oc、Md/rel、Md/awk、Md/ans S: Md/inf(ko、0、1、1、3、8、1、2、3、4、7、6、5、s0)
Foster Informational [Page 50] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[50ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
The Call Agent will then get a further "md/oc(md/sup)" event when
these digits have gone out.
そして、これらのケタが出かけたとき、Callエージェントは一層の「Md/oc(Md/一口)」出来事を得るでしょう。
Step C15 The Call Agent requests to be told of on-hook ("sus")
events
or abnormal release ("rel") events.
C15フックにおける("sus")出来事について言われるというCallエージェント要求か異常なリリース("rel")出来事を踏んでください。
Step C16 The gateway "acks" the request.
C16を踏んでください。ゲートウェイは要求を"acksする"です。
5.4. Example Call Setup - "MO" Package
5.4. 例の呼び出しセットアップ--「MO」パッケージ
The following describes Feature Group D operator services signaling call setup (911 call) using the "MO" package. The table gives an overview of the initial part of the call flow with details to follow. In this case GW-o is a residential gateway using the line package and GW-t connects to the E911 tandem.
以下は「MO」パッケージを使用することで呼び出しセットアップ(警察への緊急電話)を示すFeature Group Dオペレータサービスについて説明します。 テーブルは、続くように詳細がある呼び出し流動の初期の部分の概観を与えます。 この場合、GW-oは線パッケージを使用する住宅のゲートウェイです、そして、GW-tは911Eの2人乗り自転車に接続します。
--------------------------------------------------------------------- | Steps | GW-o | CA | GW-t | |---------------------------------------------------------------------| | A1 | NTFY[O:hd] -> | | A2 | <- Ack | | A3 | <- RQNT S: dl, R: [0-9*#T](D) | | A4 | Ack -> | | A5 | NTFY[O: 9,1,1] -> | | A6 | <- Ack | | B1 | <- CRCX [M:recvonly, R: hu] | | B2 | Ack[SDP1] -> | | B3 | CRCX [M:sendrecv, LCO, SDP1, S: mo/sup] -> | | B4 | <- Ack [SDP2] | | B5 | <- NTFY [O: oc(sup)] | | B6 | Ack -> | | B5 | <- MDCX [sendrecv,SDP2] | | B6 | Ack -> | ---------------------------------------------------------------------
--------------------------------------------------------------------- | ステップ| GW-o| カリフォルニア| GW-t| |---------------------------------------------------------------------| | A1| NTFY[O: hd]->。| | A2| <。 Ack| | A3| <。 RQNT S: dl、R: [0-9*#T] (D)| | A4| Ack->。| | A5| NTFY[O: 9、1、1]->。| | A6| <。 Ack| | B1| <。 CRCX[M: recvonly、R: hu]| | B2| Ack[SDP1]->。| | B3| CRCX[M: sendrecv、LCO、SDP1、S: 折り/一口]->。| | B4| <。 Ack[SDP2]| | B5| <。 NTFY[O: oc(一口)]| | B6| Ack->。| | B5| <。 MDCX[sendrecv、SDP2]| | B6| Ack->。| ---------------------------------------------------------------------
Note: the originating side in this case is a line-side gateway.
以下に注意してください。 この場合、由来側は線サイドゲートウェイです。
Step A1 The user goes off-hook:
ユーザのステップA1はフックに行きます:
NTFY 3001 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: l/hd
NTFY3001 aaln/1@gw-o.whatever.net MGCP1.0X: 0123456789AF O: l/hd
Step A2 The Call Agent sends an Ack:
ステップA2CallエージェントはAckを送ります:
200 3001 OK
3001が承認する200
Foster Informational [Page 51] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[51ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step A3 The Call Agent sends dial-tone and requests that digits be collected:
ステップA3Callエージェントはダイヤルトーンとケタが集められるという要求を送ります:
RQNT 2001 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
S: l/dl
R: d/[0-9#*T](D), hu
RQNT2001 aaln/1@gw-o.whatever.net MGCP1.0X: 0123456789B0 S: l/dl R: d/[0-9#*T](D)、hu
Step A4 The gateway responds with an ack:
ゲートウェイがackで反応させるA4を踏んでください:
200 2001 OK
2001が承認する200
Step A5 Once the digits are collected the gateway notifies the Call Agent. In this case, it is a 911 call
A5 Onceを踏んでください。ケタは集められて、ゲートウェイがCallエージェントに通知するということです。 この場合、それは警察への緊急電話です。
NTFY 3002 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: d/9,d/1,d/1
NTFY3002 aaln/1@gw-o.whatever.net MGCP1.0X: 0123456789B0O: d/9、d/1、d/1
Step A6 The Call Agent responds with an ack:
ステップA6Callエージェントはackで応じます:
200 3002 OK
3002が承認する200
Step B1 The Call Agent now requests that a receive-only connection be made.
ステップB1Callエージェントは、現在、受信専用接続が作られているよう要求します。
CRCX 2002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
L: a:PCMU,s:off,e:on
M: recvonly
X: 0123456789B1
R: l/hu.
CRCX2002 ds/ds1-3/6@gw-o.whatever.net MGCP1.0C: A7453949499L: : PCMU、s: オフである、e: Mに関して: recvonly X: 0123456789B1R: l/hu。
Step B2 The Gateway acks with a connection ID and provides the SDP information:
接続IDと共にB2ゲートウェイacksを踏んで、SDP情報を提供します:
200 2002 OK
I: 23474FE
200 2002はIを承認します: 23474FE
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m= audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 128.96.41.1 s=cは0 0t=mのIN IP4 128.96.41.1=オーディオの3456RTP/AVP0と等しいです。
Foster Informational [Page 52] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[52ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request and does a call setup request at the same time:
Callエージェントが接続要求の一部として終わりゲートウェイ(GW-t)にこのSDP情報を通過して、呼び出しをするステップB3は同時に、要求をセットアップします:
CRCX 4001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
C: A7453949499
X: 45375840
L: a:PCMU,s:off,e:on
M: sendrecv
Q: loop
R: oc, rel, orbk
S: sup(addr(k0,9,1,1,s2),id(k0,0,8,3,4,5,6,7,8,s0))
CRCX4001 ds/ds1-5/3@gw-t.whatever.net MGCP1.0C: A7453949499X: 45375840、L: : PCMU、s: オフである、e: Mに関して: sendrecv Q: 輪R: oc、rel、orbk S: 一口(addr(k0、9、1、1、s2)、イド(k0、0、8、3、4、5、6、7、8、s0))
v=0
o=- A7453949499 0 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 128.96.41.1 s=cは0 0t=mのIN IP4 128.96.41.1=オーディオの3456RTP/AVP0と等しいです。
As a result of this request, the following signaling interactions will occur between GW-t and the Switched Circuit Network (SCN - in this case, the E911 tandem):
この要求の結果、以下のシグナリング相互作用はGW-tとSwitched Circuit Network(SCN--この場合911Eの2人乗り自転車)の間に起こるでしょう:
* Off-hook -> SCN
* Wink <- SCN
* k0,9,1,1,s2 -> SCN
* Off-hook <- SCN
* k0,0,8,3,4,5,6,7,8,s0
* オフフック->SCN*ウインク<SCN*k0、9、1、1、s2->SCN*オフフック<SCN*k0、0、8、3、4、5、6、7、8、s0
Note that off-hook from the SCN is part of the protocol (a
request for the caller ID) and does not provide an indication of
whether the operator answered or not.
SCNからのオフフックがプロトコル(発信者番号を求める要求)の一部であり、オペレータが答えたかどうかしるしを供給しないことに注意してください。
Step B4 The terminating gateway, responds with an ack and its SDP information:
B4を踏んでください、ゲートウェイを終えて、ackとそのSDP情報で以下を反応させます。
200 4001 OK
I: 34738A
200 4001はIを承認します: 34738A
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 47.123.34.33 s=cは0 0t=mのIN IP4 47.123.34.33=オーディオの3456RTP/AVP0と等しいです。
Foster Informational [Page 53] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[53ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Step B5 The Call Agent will get a further notify when outpulsing of all of the digits is complete.
ケタのすべての「外-律動的に送」りが完全であるときに、Callエージェントがaを得るステップB5はさらに通知します。
NTFY 3003 aaln/1@gw-o.whatever.net MGCP 1.0
NTFY3003 aaln/1@gw-o.whatever.net MGCP1.0
X: 45375840
O: oc(sup)
X: 45375840○: oc(一口)
Step B6 The Call Agent returns an "ack"
ステップB6Callエージェントは"ack"を返します。
200 3003 OK
3003が承認する200
Step B7 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
B7 Callエージェントがaを送るステップは、終了ゲートウェイから接続モードが受信専用である状態で創作ゲートウェイに接続要求を変更して、選択されたプロフィールでSDP情報を含んでいます。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: sendrecv
MDCX2003 ds/ds1-3/6@gw-o.whatever.net MGCP1.0C: A7453949499I: 34738A M: sendrecv
v=0
o=- A7453949499 0 IN IP4 47.123.34.33
s=-
c=IN IP4 47.123.34.33
t=0 0
m= audio 3456 RTP/AVP 0
v=0o=A7453949499 0IN IP4 47.123.34.33 s=cは0 0t=mのIN IP4 47.123.34.33=オーディオの3456RTP/AVP0と等しいです。
Step B8 The Gateway Acks the modify connection request
B8ゲートウェイAcksを踏んでください、接続要求を変更してください。
200 2003 OK
2003が承認する200
The call is now established between the user and the operator.
呼び出しは現在、ユーザとオペレータの間で確立されます。
Acknowledgements
承認
The source for some these packages are Flemming Andreasen, Wai-Tak Siu - Cisco Systems, and Don Stanwyck - IP Unity. Special thanks to Joe Clark, Telcordia Technologies for his CAS interface expertise. Also thanks to all the reviewers for all their comments, including but not limited to the following people: Charles Eckel, Cisco Systems; Jerry Kamitses, Sonus Networks.
これらがパッケージするいくつかのためのソースはフレミングシュウ--シスコシステムズ、およびドン・スタンウィック--Andreasen、Wai-タークIP Unityです。 ジョー・クラークのおかげで特別であることで、彼のCASのためのTelcordia Technologiesは専門的技術を連結します。 また、以下が住ませる他を含む彼らのすべてのコメントのためにすべての評論家をありがとうございます: チャールズEckel、シスコシステムズ。 ジェリーKamitses、Sonusネットワーク。
Foster Informational [Page 54] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[54ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
References
参照
[1] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
October 1999.
[1]ArangoとM.とデュガン、A.、エリオット、I.とHuitemaとC.とS.ピケット、「メディアゲートウェイコントロールは(MGCP)についてバージョン1インチ議定書の中で述べます、RFC2705、1999年10月。」
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[2] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[3] Bellcore, Compatibility Information for Feature Group D Switched
Access Service, TR-NPL-000258, Issue 1, October 1985.
[3] Bellcore、特徴グループDのための互換性情報は1985年10月にアクセス・サービス、TR-NPL-000258、問題1を切り換えました。
[4] Bellcore, Interoffice LATA Switching Systems Generic Requirements
(LSSGR): Verification Connections (25-05-0903), TR-TSY-000531,
Issue 2, July 1987.
[4]Bellcore、Interoffice LATA交換システムジェネリック要件(LSSGR): 検証コネクションズ(25-05-0903)(TR-TSY-000531)は2、1987年7月を発行します。
[5] Bellcore, LSSGR: Signaling for Analog Interfaces, GR-506-CORE,
Issue 1, June 1996.
[5]Bellcore、LSSGR: アナログ・インタフェース、GR506コア、問題1のために、1996年6月に合図します。
[6] PacketCableTM PSTN Gateway Call Signaling Protocol Specification,
Pkt-SP-TGCP-I01-991201
[6] PacketCableTM PSTNゲートウェイ呼び出しシグナリングプロトコル仕様、Pkt-SP-TGCP-I01-991201
Author's Address
作者のアドレス
Bill Foster 170 West Tasman Dr San Jose, CA, 95134
サンノゼ、ビルフォスター170西洋タスマンカリフォルニア博士 95134
Phone: 408-527-8791 EMail: bfoster@cisco.com
以下に電話をしてください。 408-527-8791 メールしてください: bfoster@cisco.com
Foster Informational [Page 55] RFC 3064 MGCP CAS Packages February 2001
2001年2月に情報[55ページ]のRFC3064MGCP CASパッケージを伸ばしてください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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 assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
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 Informational [Page 56]
フォスターInformationalです。[56ページ]
一覧
スポンサーリンク
