Network Working Group B. Foster
Request for Comments: 3064 Cisco Systems
Category: Informational February 2001
MGCP CAS Packages
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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、北米CAS、CAS PBX相互接続のためのメディアゲートウェイチャネル連携信号（CAS）のパッケージだけでなく、基本的なFXOのサポートのコレクションが含まれています。 6つのパッケージが含まれています。 「MS」パッケージには、MF単段ダイヤルトランクをカバーしています。これは、ウィンク開始および即時開始PBX DID / DODトランク並びに基本R1 [3]プロトコルを終端グループD（FGD）を備えてい含みます。 「DT」パッケージは、即時開始し、基本的なDTMFやダイヤルパルスをトランクをカバーし、 『BL』パッケージは、基本的なPBX（デジタルまたはFXSインタフェース）へのインターフェースを覆います。終端プロトコルに加えて、[3]で説明した3つの他のFGDプロトコルが存在します。これらは、「MO」パッケージによって処理され囲まれた「MD」パッケージとオペレータサービスシグナリングプロトコルで覆われているEAINとEANAが含まれます。基本的なFXO相互接続のサポートは、「DO」パッケージで提供されています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
この文書は、コミュニティの情報については公表されています。これは、現在の製品の数に展開されているプロトコルを記述しています。実装者は、現在、このプロトコルへの潜在的な後継に取り組んでいるIETF Megacoの作業部会とITU SG16の動向に注意する必要があります。
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
There are a number of different possible approaches for partitioning the functional responsibility between the Call Agent and the Media Gateway:
コール・エージェントとメディアゲートウェイとの間の機能の責任を分割するための異なる可能な多数のアプローチがあります。
* The Call Agent takes all of the responsibility for the CAS state machine giving the media gateway detailed commands
*コール・エージェントは、メディアゲートウェイ詳細なコマンドを与えるCASステートマシンの責任のすべてを取ります
* The media gateway contains the CAS state machine and provides an abstract interface to the Call Agent
*メディアゲートウェイは、CASのステートマシンが含まれており、コールエージェントへの抽象インタフェースを提供します
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プロトコルとタイミング詳細を処理し、より高いレベルの処理が必要とされるたびにコールエージェントが唯一の関与持つことができるようにすることです。
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).
このアプローチを取ると、理想的な状況は、メディアゲートウェイに詳細を残して、コールエージェントは同様の方法でできるだけ多くCASプロトコルを扱うことができるようになります。例：単一の着信桁の文字列が含まれ、着信MFトランクのために、コールエージェントが、これはウインクスタートトランクまたは即時スタートトランク（メディアゲートウェイは、ウィンクスタート信号を提供する必要はありませんが）であるかどうかを気にしてはいけません。
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.
*コール・エージェントとメディアゲートウェイとの間の相互作用の数を最小限に抑えます。
* 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.
*メディアゲートウェイはディジット分析（例えば、入ってくる数字は、キャリアアクセス情報を含むことを決定するために）を実行する必要はありません。これは、コールエージェントの責任です。
* 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).
それが可能な場合、コールが（例えば、エージェントは一桁の文字列が関与しているとき、ウインクスタートと即時開始インタフェースを区別する必要はありませんコール）が流れる再利用できるように*コール・エージェントのための抽象化のいくつかの合理的なレベルを提供します。
* 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.
*メディアゲートウェイは、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).
例えば、同じ着信コール・セットアップのイベントはMFの場合にも使用することができるように、a）のそれもかかわらず、起動して、MF即時スタートトランク、コールエージェントに共通のインタフェースを提示ウィンクコール・エージェントのための抽象インタフェースを可能にCASステートマシンレベルのセマンティクスがわずかに異なる（場合を開始ウィンクMFで、すなわち、ウィンク開始信号は、即時開始場合のように、これは必須ではない着信発作の結果として再帰提供されます） 。
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）は、埋め込まれた通知をトリガする可能性がある潜在的なイベント（例えば、典型的には必要と上記着信発作）はとにかく請求のコールエージェントに見えるようにします。
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.
アウトパルスアプローチ：outpulsingためのセマンティクスを提供するために、特殊な高レベルの信号（コールセットアップ情報は、「INF」の例えば、「SUP」）は、必要なセマンティクスを含むものが含まれます。
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:
オフフック及びオンフック信号とイベント：オフフックとオンフックイベントの高レベルのビューは、インターフェース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
以前のイベントを参照することなく、正確に何が起こっているかのようにメッセージを見たとき*これは、（デバッグを容易にするため）より明らかです
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）内で行われている（例えば、即時開始に対する開始ウィンク）。コールエージェントの責任は、特定のパッケージ（すなわち、一般的にはコールエージェントがそれらの違いは、MGでの世話をしているので、ウィンクスタートと即時開始を区別する必要はありません）をサポートすることです。しかし、コールエージェントは、着信、発信や双方向であるトランクを知っている必要があります。
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トランクが/ DIDは「MS」パッケージが使用されています。またトランクを開始ウィンク着信または発信MFのために使用される（R1およびFGDプロトコルを終端[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 | |
--------------------------------------------------
DTMF and dial-pulse (DP) trunks (except basic PBX) are covered by the "DT" package along with the DTMF "D" package:
（基本的なPBX除く）DTMFとダイヤルパルス（DP）トランクは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 | |
--------------------------------------------------
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「D」パッケージ（本質的にこれは「NO機能を持つ基本的なライン」に似ている）と一緒に - デジタルまたはFXSトランクインターフェイス基本的なPBXトランクを「BL」パッケージで覆われている（DP）DTMFとパルスダイヤル
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| |
--------------------------------------
The "DO" package is used for analog FXO loop-start and ground-start analog trunks as indicated in the following table.
以下の表に示されているように、「DO」パッケージは、アナログFXOループスタート及びグラウンドスタートアナログトランクのために使用されます。
Table 4 FXO analog PBX Trunks
表4 FXOアナログPBXトランク
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|FXO, loop-start|Bi-directional |
|FXO, ground- |Bi-directional |
| start | |
--------------------------------------
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機能グループD EANAとEAIN [3]のためのサポートを提供します。以下の表のCASシグナリングタイプ]列は、コール・エージェントとメディアゲートウェイの両方に共通の関心事である差異をシグナルを示すことを意図しています。唯一のメディアゲートウェイに関心のある構成情報が特定されていません。
Table 4 Feature Group D MF Trunks Supported
表4機能グループD MFトランクはサポートされています
--------------------------------------------------
| 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) |
--------------------------------------------------
Note that EANA and EAIN signaling may be requested on the same trunk on a call-by-call basis.
EANAとEAINシグナリングは、コールごとに同じトランクに要求することができることに注意してください。
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オペレータサービスシグナリングのために使用され、出トランクだけ。グループCは、同じインターフェイスでサポートされていることができています。
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.
このセクションでは、イベントパッケージを定義します。用語「信号」及び「イベント」は、メディアゲートウェイ（「シグナル」）へのコールエージェントからのコマンドを区別するために使用されるメディアゲートウェイによって検出され、その後、コールエージェントに「通知される」「イベント」から。
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:
イベントは、コールエージェントによって要求されることができるかどうか*イベント「X」は、この列に表示されます。また、以下のシンボルのうちの1つまたは複数が表示されることがあります。
- "P" indicating that the event is persistent,
- イベントが永続的であることを示す「P」、
- "S" indicating that the event is an event-state that may be audited,
- イベントを監査することができるイベント状態であることを示す「S」、
- "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」）を監査することができるという目的は二つの質問の一つ答えることであることに注意してください。
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.このライン/トランクにコールが開始されていますか？によって、 - （「BL」パッケージFXS）または（FXO）以下「DO」パッケージの場合に従うパッケージにおいて、例えば、呼セットアップ開始「がSUP」イベントまたは「HD」のいずれかで示されますこれらのイベントは、彼らが監査可能であることを示すイベント欄に「S」を持っているように、「RG」イベント。
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:
*信号は何もこの列に表示されていない場合、このイベントは、コール・エージェントからの要求に合図することはできません。そうでなければ、次のシンボルの一つは、信号の種類を識別するために提供されます。
- "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"。信号はそれをオフにするには、Call Agentによって命じ、及びその逆になるまでオンになっています。 - "TO" タイムアウト信号。それは、新たな信号に取って代わらやイベントの検出に終了されない限り、信号が与えられた期間持続します。デフォルトのタイムアウト値が供給されています。ゼロの値は、タイムアウト期間が無限大であることを示しています。プロビジョニング・プロセスは、これらのデフォルト値を変更することができます。 - "BR" ブリーフ信号。信号は、短い、既知の持続時間を有します。
* Additional info Provides additional information about the event/signal, e.g., the default duration of TO signals.
*追加情報はイベント/信号、例えば、信号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.
特に明記しない限り、イベント/信号のすべてが検出された/それらによって生成されたエンドポイントと音声に適用されているエンドポイントが持つかもしれない接続で転送されません。イベント/信号によって生成された音声検出/接続に適用されているが、接続モードに関係なく対応する接続に転送されます。
The following codes are used to identify events and signals for the "MS" package:
以下のコードは、「MS」パッケージのイベントと信号を識別するために使用されます。
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 | |
---------------------------------------------------------------------
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 | |
---------------------------------------------------------------------
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 |
---------------------------------------------------------------------
The following codes are used to identify events and signals for the "DO" package:
以下のコードは、「DO」パッケージのイベントと信号を識別するために使用されます。
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 |
---------------------------------------------------------------------
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 | - | |
---------------------------------------------------------------------
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.
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.
イベント/信号名は、対応するイベント+シグナルが続くカッコ内に表示されたコードに加えてイベント/信号が発生しているパッケージのリストを属性。
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 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.
謝辞ウィンク（awkに、P + BR; MD）：このイベントは、 "MD" のパッケージにのみ適用されます。これは、すべての数字が正しく受信された表示を提供します。発信トランクに、イベントは、要求及び受信したとき、接続スイッチはアドレス情報の全てを受信したことを示しています。元のトランクでは、この信号は、すべてのアドレス情報が受信されたもう一方の端を知らせるために送信されます。コール・エージェントは、例えばトランジットアプリケーションを提供している着信と発信トランクが両方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.
ブロック（; S + BR、BL 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.
コール・エージェントは、それが、これは一方通行の発信トランクであり、それは、着信呼設定要求（「SUP」イベント）を参照してくださいことはありませんことを知っている場合は、「BL」イベントを要求すべきです。イベントとして要求された場合、「BL」などは、「SUP」永続的なイベントとして抑制されます。
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を参照してください。トーンの定義は、国家の特性によって定義されたプロビジョニングを介して確立することができます。 LSSGR、シグナリング、セクション17.2.6 - ステーションビジーは、GR-506-COREに定義されています。 480と620ヘルツの周波数および-24 dBmのそれぞれのレベルを有する2つの交流トーンの組み合わせとして-21 dBmでの合成レベルを得ました。ステーションビジートーン用ケイデンスは繰り返し、オフ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 + - ; DO）：TR-NWT-001188、GR-30-CORE、およびTR-NWT-000031を参照されたいです。三つのフィールドのそれぞれは、しかし、カンマのそれぞれが常に含まれます、オプションです。
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が01と12の間の月のための2桁の値であり、DDは1と31の間の日に2桁の値であり、「MM / DD / HH / MM」として符号化された時間、及び時間と分であります軍の現地時間に応じてコード化された2桁の値、例えば、00は真夜中、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.
数パラメータは、呼び出し元の行番号を識別する桁の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.
nameパラメータは、呼び出し元のライン名を識別するASCII文字の文字列として符号化されます。文字列が引用されている場合、ホワイトスペースが許可されています。
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」が利用できない番号または名前を示すために使用されます。次の例では、発信者ID、イベントの使用を示します。
O: ci(10/14/17/26, "555 1212", somename)
：あなたは（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; - + TO; BL、DT）トーンダイヤル：ITU E.180を参照してください。トーンの定義は、国家の特性によって定義されたプロビジョニングを介して確立することができます。 GR-506-COREにおいて - LSSGR、シグナル伝達、セクション17.2.1、SIALトーンは-10 dBmでの合成レベルを与えるために350と440ヘルツの周波数および-13dBmそれぞれのレベルを有する2つの連続したACトーンの組み合わせとして定義されます。試してみて、フック上にあり、そのような試みは、（ - フックの電話エラーコード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.
情報桁（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数字列が受信されたことを示すためにイベントとして使用されています。この場合、<INF-桁>までに蓄積されたすべての桁であり、数字はST、ST「ST 『』、ST 『』」をデリミタを含みます。 STの数字の1で終わる数字の複数のシーケンスは、単一の「INF」イベントに渡すことができます。 （K0がKPと同じである、K1は時々KPと呼ばれ、これに「等が同様S0がSTと同じであり、S1は、STと同じです」。
The value of <inf-digits> is a comma separated list of MF digits: MF1, MF2, ..., MFn
MF1、MF2、...、MFN：<INF-数字>の値は、MF桁のカンマ区切りリストです
where each of MFi will be one of the following MF digit symbols:
どこのMFiのそれぞれには、以下のMF桁のシンボルの一つになります。
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'''|
--------------------------
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:
完了操作（; X + OC - ;すべて）：ゲートウェイは、1つまたはエンドポイント上のタイプのいくつかの信号、及び検出により停止することなく完了それらの信号の一つ以上を適用するように頼まれたときの動作完了イベントが生成され要求されたか、永続的なイベントのような設定など。完了報告は、パラメータとしてのように、その生きた時間の終わりに来た信号の名前を運ぶことができます。
O: ms/oc(ms/sup)
A. MS / OC（MS / SUP）
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.
操作completeイベントが要求されると、それはどんなイベントパラメータをパラメータ化することはできません。
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.
外パルス化が完了すると、動作完了のイベントが示されます - （イベントに出て、脈打つ）「SUP」のために同じ信号で要求されたときにことに注意してください。
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 +の - ;全て）動作不良：一般的に、エンドポイントは、1つまたはエンドポイント上のタイプのいくつかの信号を印加するように頼まれたときに動作不良イベントが生成されてもよいし、これらの信号の1つ以上が前に失敗しましたタイムアウト。完了報告は、パラメータとしてのように、障害が発生した信号の名前を運ぶことができます。
O: ms/of(ms/sup)
A. MS /オフ（MS / SUP）
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.
動作不良イベントが要求されると、それはどんなイベントパラメータをパラメータ化することはできません。
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).
オペレータのリングバック（ORBK; X + - ; MO）：シグナリングMF CASの説明このイベントの結果はTR-NPL-000258の付録に記述されていることを知らせる[3]。簡単に言えば、それは、通常ウィンクオン信号又はMFトーンが続いてもしなくてもよいです。このイベントは、発呼者が（「MO」パッケージのみ）警告されたときにオペレータのサービス要求を生成します。
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.
忙しい作るリバース（; P + RBZ - ; MO）：このイベントは、一方向オペレータサービストランクのもう一方の端（「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.
リリースコール（REL; P、S + BR、BL、DT、MD、MO、MS、DO）：メディアゲートウェイへのコールエージェントによって送信された「REL」信号が関連付けられたすべてのリソースを解放するための要求でありますコールのテレフォニーレグ。これはまた、適切な送信されてオフフック信号をもたらすことができます。 「REL」信号の結果として、ゲートウェイは、リソースが解放された時はいつでも、「RCL」イベントに応答します。コールのテレフォニーレグに関連付けられたリソースを解放すると、既存の接続（ネットワーク脚）には影響しません。これは、そのエンドポイントへのネットワーク接続を解放するために、適切な削除接続コマンドを送信するには、Callエージェント次第です。
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:
コールは、コール（通常のリリース）の発信側からかによる呼び出しを解放が生じた異常事象にオンフックイベントの結果として放出されるたびにメディアゲートウェイは、「リリースコール」イベントを生成します。イベントは、リリースの理由を示す、次の原因コードのいずれかでパラメータ化することがあります。
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) |
-----------------------------------------------------------------
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.
（原因オンフック着信に）理由コード「0」を示す正常リリースで「REL」イベントのみ発呼が発生ゲートウェイによって「通知」されることに注意してください。この動作は、発信者がコールを解放したとき、すべてのリソースが解放されてもよいというルールに従います。オンフックコールの終端部のための対応するイベントは、フックの状態を示し、解放されているリソースにはなりません。「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グラウンドスタートの場合（「DO」パッケージ）の場合、メディアゲートウェイはコールが遠端から先端の接地リリースイベントの結果として放出されるたびに、「リリースコール」イベントを生成します。
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）：これは、着信側がコールを再開したことを示し、以前は（「SUS」）中断の後、すなわち、パーティはオフフックに行きましたが、元のスイッチの前に（「相対」）トランクをリリースしました。 「SUS」と「解像度」のイベント/信号は、コールに関連付けられているリソースを解放することなく、オンフックとオフフックイベントを伝播するために使用されています。全てが、オペレータサービスケース（「MO」パッケージ）では、これらのイベントは、通常、発信端に終端から伝播されることになる（すなわち、コールの終端からイベントとして要求し、ゲートウェイへの信号としてゲートウェイに送信コールの発信側の）。
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 Agentに任されています。そうでない場合は、コールの終端から「SUP」イベントを受信したとき、それは単に先に行くと、すぐに電話を取り壊す（「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).
（; P、S + TO; RG BL、DO）をリンギング：この信号は、発信基本トランク（ "BL" のパッケージ）のために使用されています。 GR-506-COREを参照 - LSSGR：シグナル伝達、第14プロビジョニング・プロセスは、リンギングリズムを定義することができます。これはトランクがオフフックに示す場合にしようとするエラーとリングとみなされ、そのような試みがなされているときにエラーが結果として返されるべきである（ - 電話のオフフックをエラーコード401）。
In the case of the "DO" package, "rg" is defined as an event used to indicate detection of ringing.
「DO」パッケージの場合には、「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; DO、DT、MD、MO、MS）完全なリリース：エンドポイントとコールエージェントがコールを確認するために、解放完了イベント/信号を使用するには、リリースされており、トランクは別のコールのために利用可能です。ゲートウェイがオンフックになった後FXOグラウンドスタート（「DO」パッケージ）のために、これは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）：-21の合成レベルを与えるために、トーン480及び620ヘルツの周波数および-24 dBmのレベルのそれぞれに2つの交流トーンの組み合わせで並べ替えますdBmの。リオーダートーンのためのリズムは継続的に繰り返し、オフ0.25秒に続いての0.25秒です。 SIGNALING、セクション17.2.7：LSSGR - GR-506-COREを参照してください。
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）：可聴着信音が440と480ヘルツの周波数および-19 dBmのレベルのそれぞれに2つの交流トーンの組み合わせである、の複合レベルを与えるために-16 dBmに。米国では可聴着信音にケイデンスは、4秒オフに続いての2秒になるように定義されます。トーンの定義は、リングバックトーンの国民性によって定義され、プロビジョニングを介して確立され得ます。 SIGNALING、セクション17.2.5：LSSGR - GR-506-COREを参照してください。
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.
コールセットアップ（SUP; P、S + TO; DO、DT、MD、MS、MO）：イベント/信号が発信および着信コールセットアップの両方に使用されます。それぞれ、以下に分けて説明します。
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.
発信トランクには、「SUP」信号は、トランクとアウトパルス数字をつかむために使用されます。 "SUP" 信号は、パッケージに応じて最大4つのパラメータSUP（<CT>、<CA>、<ID>、<ADDR>）でパラメータ化されます。これらのパラメータの順序は重要ではありません。次の表は、様々なパッケージ（「F」）、（「M」）必須オプション（「O」）または禁止されているものを示しています。
Table 13 "sup" parameters.
表13 "SUP" のパラメータ。
------------------------------------
| 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 |
------------------------------------
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値>）である<CT-value>はCASシグナリングのタイプを示し、EANA及び「NTA」の二つの値「NDA」（北米ダイレクトアクセス）のいずれかを有することができますEAIN用（北米タンデムアクセス）。同じトランクの両方のために使用することができるので、このパラメータは「MD」のパッケージを扱うトランクの場合に必要とされる理由があります。 <ADDR>フィールドは、宛先番号が含まれており、存在する場合は、フォームになります
addr(dig1, dig2, ..., dign)
ADDRES（DIG1、dig2、...、彼女は）
The <id> field contains the identification of the caller and when present will be of the form:
<ID>フィールドは、発信者の識別情報を含み、存在する場合は、次の形式のものであろう。
id(dig1, dig2, ..., dign)
それ（DIG1、dig2、...、彼女は）
The <ca> field contains the country address information and when present will be of the form:
<CA>フィールドは、国のアドレス情報及び存在する場合は、フォームのものであろう含まれています。
ca(dig1, dig2, ..., dign)
CA（DIG1、dig2、...、彼女は）
When present, the <addr> field contains the destination number and will be of the form
存在する場合、<ADDR>フィールドは、宛先番号が含まれており、形式のものであろう
addr(dig1, dig2, ..., dign)
ADDRES（DIG1、dig2、...、彼女は）
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.
"MS"、 "MO"、及び "MD" パッケージとDIGIがDTMFシンボルである（0~9、*、＃、A、B、C、Dの場合には表11に定義されてDIGIはMFシンボルであります）「DT」と「DO」のパッケージの場合には
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):
次の表は、単段outpulsingアプリケーション（「DT」、「MS」と「DO」のパッケージ）のためのメディアゲートウェイ（MG）と回線交換ネットワーク（SCN）との間に何らかの相互作用を示しています。
Table 14 SCN Sequencing during Call Setup (single stage outpulsing)
コールセットアップ中に表14 SCNシーケンシング（単段outpulsing）
------------------------------------------------------------------
|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|
------------------------------------------------------------------
Call setup signal example for this case (MF signaling):
この場合のセットアップ信号例（MFシグナリング）を呼び出します。
sup(addr(s0,5,5,5,1,2,3,4,k0))
SUP（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シーケンシング（HANAとRAIN）
------------------------------------------------------------------
|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|
------------------------------------------------------------------
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))
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））
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」イベントは、（他端が答え）遠端からオフフックの指標です。しかし、特徴グループDのオペレータサービスシグナリング（OSS）プロトコルの場合に - 以下の表に示す、オフフック操作者からようにプロトコル（発信番号に対する要求）の一部である「ANS」におけるこの場合は、オペレータが答えた（番号のみを呼び出すことオフフック/要求が受信された）ことを示すものではありません。
Table 16 SCN Sequencing during Call Setup OSS Protocol ("MO" Package)
コール設定OSSプロトコル（「MO」パッケージ）中の表16 SCNシーケンシング
------------------------------------------------------------------
|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|
------------------------------------------------------------------
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.
着信設定は：「SUP」イベントは、着信コールが到着したとき（入ってくるオフフックイベントに対応する）を示すために使用されます。イベントは、パラメータなしで提供されています。
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.
コール（; P + BR; SUS 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.
オンフックイベントは、コールの終端に「MS」を使用するインターフェイス、「DT」とエンドポイントからの「MD」パッケージの「SUS」のイベントとしてコールエージェントに「通知」される（比較して、発信側から「REL」イベントに）。着信エンドポイントからの「SUS」イベントは、コール・エージェントに単に電話を解放するために、「サスペンド/レジューム」処理を行うかのオプションを提供します。
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」信号は、オンフックを送信し、呼に関連するリソースを解放します。
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」の「解像度」（オフフック）に続いて、コールがもう存在しないため、「REL」は「RES」が続いていないことができない一方で、通話が再開できるようにすることができます。
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.
（オンフック）、「SUS」、「RES」（オフフック）および「RCL」（フラッシュフック）とすることができる、ようにE911（「MO」パッケージ）のために、操作者が呼を解放する制御で通常であります通話を解除せずにオペレータにユーザーのフックイベントを渡すために使用。
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.
スタートウィンク（SWK; X + - MD、MO）:.コール・エージェントは、必要に応じて、ウィンク開始信号が発生したときにそれを通知するためのMGを要求することができます。ウィンクスタート注（「SWK」）は、信号としてコールエージェントによって適用することはできません。入トランク上のウィンクスタートの発生は、コールエージェントの関与を必要としない反射的行動です。
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:
冒頭で述べたように、より高いレベルのビューは、インターフェイスがQ.931-ようにするためにCASパッケージの多くはオンフックとオフフックのイベントのために取られています。これは、その利点を提供します。
* 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.
この一例は、オフフックハイレベル信号として数字が続く送信含む「SUP」信号です。 「ANS」イベントはオフフックが、呼が応答された時点で終端から表すために使用されます。
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」、履歴書とリリースの「REL」の「解像度」は一端（オリジネーター）がコールを制御しているという考え方に基づいています。制御側がオンフックになる場合は、「相対」コールエージェントに通知され、解放されたコールで結果ています。非支配（終端）側がオンフックになる場合は、「SUS」イベントは、（代わりに「REL」イベントで）発生します。これは、コールエージェントに/再開処理を中断することのオプションを提供します。
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.
コールエージェントがサスペンド/レジューム処理をしないことを決定した場合、それはコールの非支配（終了）端から「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.
一方、それはサスペンド/レジューム処理を行うことを決定した場合、それはコールの非支配（終端）側から「SUS」イベントを受信したとき、それはタイムアウトを開始することができ、それが「RESを受信した場合、コールを続けます「（オフフック）イベント。また、着信ゲートウェイに信号として「SUS」と「RES」をバック伝搬するためのオプションを持っているし、それを呼び出し（「REL」イベント）か否かを解放する機会を可能にします。いずれの場合も、「SUS」の利用および「解像度」の信号がオンフック送るだけでなく、コールのテレフォニーレグに関連付けられたリソースを解放するだけでなく、「REL」信号を制御の別のレベルを与えます。
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.
E911（「MO」パッケージ）のためになおすると、そのオペレータ（終了端）における特殊な場合は常に、制御端です。 「SUS」および「RES」信号がオペレータに前方ユーザフック状態を渡すために使用されます。 「REL」イベントは、オンフックコールを解放しなければならないことを示すオペレータから受信されたときにコールエージェントに通知として渡されます。 「REL」が受信されない場合、コールは存続し続けなければなりません。
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」信号/イベントは、一般的に意味オンフックが、より、それはまた、コールのテレフォニーレグのための「リソースの解放」を示すことこと。コールエージェントが送信した場合は、「相対」信号の代わりに、「SUS」それが放棄されるコールを要求している（すなわち、「relが」「RES」が続くことはできません）。
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.
*コールの電話脚はもはや維持することができるように、メディア・ゲートウェイ内のいくつかの異常事象。
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.
*コールエージェントは、そのトランクのために送られているオフフックの発信で、その結果、トランクを解放するために、「相対」を送信します。メディアゲートウェイは、他端からオンフックを受信すると、トランクが放出され、利用可能であることを示す「RLC」イベントを返します。 *メディアゲートウェイはコールエージェントに送信される「相対」イベントで、その結果、コールの制御終了時にトランクからオンフックを受けます。 Callエージェントは、次にオンフック反対方向に送信され、その結果、メディアゲートウェイに「RLC」を送信します。 *「REL」イベントは、メディアゲートウェイが呼（例えば、グレア状態）の電話脚を維持することができないであるいくつかの異常が発生した場合にコールエージェントに送信されます。コールエージェントはコールのリリースを完了するために、ゲートウェイに「RLC」を送信します。 『（『SUS制御（発信）に信号をREL 『*コールエージェントが送信することができます（「RLCがオンフックに対応していなくてもよいが、一般的に反応して、とにかく送られる』 RELことに注意してください）』の代わりに』）コールの終了コールを放棄する。ゲートウェイがオフフックがもう一方の端から受信された、すべてのリソースが解放されたとき、「RLC」と返されます。*「相対」は一方通行の着信に送信することができますトランクは以前に送られたブロック（「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.
「DO」（FXO）パッケージには、しかし、グラウンドスタートの場合には先端地盤のリリースの結果として呼び出しを「解放」する機能があるため、「REL」と「RLC」を持っています。 PBXは、最初の（：HUコールエージェントからの解放を完了するために、Sに続く）コールを解放した場合に信号「REL」が使用されています。 PBXは、先端地盤のリリースを行う際に、エージェントを呼び出すためにメディアゲートウェイから「RLC」イベントが続く - 解放を開始するHU：また、コールエージェントはSを送信することができます。ループスタートトランクは、通常、この動作を（唯一のグラウンドスタートに適用される）持っていませんが、メディア・ゲートウェイがコールエージェントに共通のインターフェースを可能にするためにループスタートの場合の動作をエミュレートする必要があります。
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」信号/事象があります。
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.
以下は涙ダウンをするために呼確立からオフフックとオンフック伴う各種イベントの使用をまとめました。これは主に、「MS」、「DT」、「MD」へとより少ない程度「DO」のパッケージに適用されます。
* 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.
*「SUP」イベントは、オフフック発信を表します。 *パラメータを持つ「SUP」信号は、着信側の桁outpulsingとオフフック提供します。 * outpulsingが完了すると、「ANS」イベントは、（被呼者が応答した）の終端側からオフフックを示しています。 *コールエージェントは、着信側が応答したことを呼び出し側に示すために、発信側に（オフフック）、「ANS」信号を送信することができます。 *コール・エージェントは（例えば、呼び出しを中止する）呼び出しを取り壊すためにいつでもどちらかの端に「REL」を送ることができます。 *メディアゲートウェイは、（パラメータなどの理由で）コールの異常終了を示すために「REL」を送信することができます。着信側がオフになった場合*ただし、いったんコールが確立され、通常の動作の下で、コールエージェントは、発信者がオンフックと「RES」行ったことを示すために、終端から「SUS」（一時停止）イベントを期待することができますコールエージェントがコールを切断する前に再びフック。コールエージェントがコールを切断することなく、発呼者にオフフックとオンフックを示すために、発信側にこれらの同じ信号を送信することができます。コールが確立されると*通常動作時には、オンフック発信側（発信側）から「REL」信号になります。コールエージェントはその後、通常の通話を終了するために終端部に「REL」信号を送信します。 「RELが正常に続いて 『RLC完全に示されたリリースに発呼者に戻ってオンフックに送信し、『RLC 『で応答し、コールエージェントの』相対』（例えば、メディア・ゲートウェイは、とオンフックパーティを呼び出す示して』。
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」は、ユーザのフック状態を示すオペレータにフォワード信号です。
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.
ゲートウェイは、ゲートウェイは、制御または非制御する「スイッチ」であるか否かを示すように設定することができるあたりDS0基づいて設定グレアビットを有することができます。しかし、一般的に、PBXが事前に設定されているかまたは非制御スイッチとして動作するように構成することができます。彼らは、許容ウインク長を超えてオフフックを参照してくださいこの場合、彼らは、受信機を取り付けますオンフック、および新しいコールの桁を待っています。一方、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秒のデフォルト値）まで待ちます通常の方法で、パルスします。オンフックへの状態変化が発生する前にタイムアウトが発生した場合は、ゲートウェイがコールエージェント（ - まぶしさを示す原因コード「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）は」ゲートウェイによって送信されると、それは、呼が解放されている過程にあり、コールエージェントはそのトランク上であきらめるべきであることをコールエージェントへの指示です。ただし、ゲートウェイは、実際にもう一方の端はウインクなどのオンフックを取るという可能性を避けるために、その時点でオンフックを送信したくない場合があります。代わりに、それは第二のタイマを起動して、トランクを解放するまでの時間のいくつかの長い期間（例えば、16秒程度）を待つことがあります。それがタイムアウトする以前にオンフックを受信した場合、それはオンフックによるリリースを完了します。もう一方の端がオンフックになる前に、他の一方で、タイマーの期限が切れた場合、それは単にオンフックとオンフックするもう一方の端を待ちます。いずれにせよ、一度両端がオンフック状態に戻ってきた、「RLC」イベントがコールエージェントに送信されます。
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トランクの送信発作で検出された場合、リンギングの要求は「NACKさ」（オフフック電話エラーコード401）でなければなりません。
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:
次のコールフローは、コールの両側を処理する単一のコールエージェントを含む（すなわち、インターコールエージェントシグナルは無視されます）。コールに関係するコンポーネントは、次のとおりです。
* The Call Agent (CA)
*コールエージェント（CA）
* The originating Media Gateway (GW-o) and
*元のメディアゲートウェイ（GW-O）と
* The terminating Media Gateway (GW-t)
*終端メディアゲートウェイ（GW-T）
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 -> |
---------------------------------------------------------------------
Step A1 PBX seizure results in a notify to the Call Agent indicating the start of a call setup:
コールセットアップの開始を示すコール・エージェントに通知してA1 PBX発作の結果をステップ：
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: ms/sup (or dt/sup)
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
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X：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:
別の方法としては、ステップA3でその要求を通知し、組み合わせて、この中になったRQNTに埋め込まれた要求を使用することであっただろう。例 - "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))
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
This would result in both notifies occurring without requiring the RQNT in step A3.
これは、ステップA3でRQNTを必要とせずに発生する両方の通知をもたらすであろう。
Step A2 The Call Agent sends an Ack:
ステップA2ザ・コール・エージェントは、ACKを送信します。
200 3001 OK
200 3001 OK
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:
桁が収集さA3ザ・コール・エージェントの要求をステップ。ここで使用されるアプローチは、PBXインターフェイスのタイプによって異なります。 MFインタフェースの呼び出しエージェントは、次のような情報の桁が収集されることを要求します。
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
R: 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:
コール・エージェントはまた、トランクがコールセットアップの過程でいくつかの理由（「REL」イベント）（リリースイベントは、例えば、いくつかのシグナリング・エラーが原因である可能性があり）のためにリリースされるならば言われるように求められます。 DTMFトランク（ウィンクスタート、即時開始と基本PBX）の場合、要求はケタマップに基づいているので、少し違って見えます。
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)
0123456789B0 R：D / [0-9 *＃T]（D）、DT / REL（基本の場合のBL / HD MGCP 1.0 X ds/ds1-3/6@gw-o.whatever.net RQNT 2001 PBX）
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インターフェイスの要件に応じて、ここであってもなくてもよい信号に - 基本的なPBXのために必要とBL / DLと、いくつかの即時スタート・インタフェースのためのDT / dlで。
Step A4 The gateway responds with an ack:
ゲートウェイがACKで応答A4ステップ：
200 2001 OK
200 2001 OK
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。 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)
In the case of a DTMF interface (including Basic PBX), it will look like the following:
（基本的なPBXを含む）DTMFインターフェイスの場合は、次のようになります。
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
MGCP 1.0 X ds/ds1-3/6@gw-o.whatever.net NTFY 3002：0123456789B0 O：D / 5、D / 5、D / 5、D / 1、D / 2、D / 3、D / 4
Step A6 The Call Agent responds with an ack:
ステップA6ザ・コール・エージェントは、ACKで応答します。
200 3002 OK
200 3002 OK
Step B1 The Call Agent now requests that a receive-only connection be made.
コールエージェントB1ステップは現在、受信専用の接続がなされることを要求します。
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).
Step B2 The Gateway acks with a connection ID and provides the SDP information:
ステップB2ゲートウェイのACKコネクションIDを有するとSDP情報を提供するが：
200 2002 OK
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
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request:
CallエージェントB3ステップは、接続要求の一部として、終端ゲートウェイ（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
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 = 0 0 = - A7453949499 0 IP4 IN 128.96.41.1 S = - C = IP4 IN 128.96.41.1 T = 0、M =オーディオ3456 RTP / AVP 0
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).
それは、後に（ステップC1）が示されている - 終端トランク上のコールセットアップが、このコールフローであるが、このCRCXで行うことができることに留意されたいです。
Step B4 The terminating gateway, responds with an ack and its SDP information:
ステップB4終端ゲートウェイは、ACKおよびそのSDP情報で応答します。
200 4001 OK
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 = 0 0 = - A7453949499 0 IP4 47.123.34.33におけるS = - C = IP4 IN 47.123.34.33 T = 0、M =オーディオ3456 RTP / AVP 0
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のコールエージェントが接続モードに変更接続要求が受信専用発信ゲートウェイに送信し、終端ゲートウェイから選択されたプロファイルとのSDP情報を含みます。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: recvonly 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
Step B6 The Gateway Acks the modify connection request
ステップB6ゲートウェイAcksを接続要求を変更
200 2003 OK
200 2003 OK
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.
以下の表は、従うべき詳細を基本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 |
---------------------------------------------------------------------
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:
ステップC1ザ・コール・エージェントは、以下になる終端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
Note that the result of the "sup" signal is the following sequence on the interface to the PBX:
「SUP」信号の結果は、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に送信します
For DTMF PBX interface (except Basic PBX), the only difference is that the MF start and end delimiters (k0 and s0) are not included:
（基本的なPBX除く）DTMF 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
45375841 Q：MGCP 1.0 X ds/ds1-5/3@gw-t.whatever.net RQNT 4002ループS：DT / SUP（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
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0 X：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.
この場合、リングバックは、ゲートウェイから来るし、室温での@ connectionIDのための信号要求をすぐに開始します。これとすぐにイベントが他のPBXの場合には（オフフック回答イベントを表す）が発生して終了します、リングバックトーンは、PBXから来ているので、ゲートウェイによって生成されている必要はありません。
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
200 4002 OK
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ステップ、ディジットが送信される完了している（数字はパルス出力されていない）場合は、によって事実を通知するゲートウェイは、操作が完了したことを示します。
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))
Step C4 The Call Agent acks the notify
C4ザ・コール・エージェントは通知ACKのステップ
200 1001 OK
200 1001 OK
In the case of the BL package, steps C3 and C4 will not exist.
BLパッケージの場合には、C3とC4が存在しません繰り返します。
Step C5 When an answer is obtained from the other end (off-hook from the PBX), the gateway sends a notify to indicate:
ステップC5回答がもう一方の端（オフフックPBXから）から得られた場合、ゲートウェイは示すために通知送信します。
NTFY 1002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
O: ms/ans (or dt/ans or bl/hd)
Step C6 The Call Agent acks
ステップC6ザ・コール・エージェントのACK
200 1002 OK
200 1002 OK
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.
ステップC7ザ・コール・エージェントは現在、全二重接続をするために要求を送信し、もう一方の端が電話に答えたことを示します。
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)
Step C8 The Gateway acks the request
要求のACK C8ザ・ゲートウェイステップ
200 2004 OK
200 2004 OK
Step C9 The Call Agent sends a notification request to be told when the trunk to be released.
ステップC9ザ・コール・エージェントは、トランクがリリースされる際に告げする通知要求を送信します。
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)
Step C10 The gateway acks the request
要求ACKS C10ザゲートウェイステップ
200 4003 OK
200 4003 OK
The call is now setup.
コールは現在の設定です。
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).
二つの例は、発信側が終端がリリース（セクション5.1.2.2）を開始リリース（セクション5.1.2.1）と1つを開始1は、ここに含まれています。
The following call flow shows an example where the origination end initiates the release for the "MS" package (similar for "DT" Package).
次のコールフローは、発信側が（「DT」パッケージに類似した）「MS」パッケージのリリースを開始する例を示しています。
--------------------------------------------------------------------
| 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] |
---------------------------------------------------------------------
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] |
---------------------------------------------------------------------
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)
ステップ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)
Step A2 The Call Agent Acks the Notify
A2ザ・コール・エージェントは通知ACKのステップ
200 3005 OK
200 3005 OK
Step A3 The Call Agent sends a request to release the trunk. (For all but Basic PBX.)
ステップA3ザ・コール・エージェントは、トランクを解放するための要求を送信します。 （基本的な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)
For the Basic PBX ("BL" package), dial-tone is played
基本的なPBX（「BL」のパッケージ）の場合、ダイヤルトーンが再生されます
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0 X: 45375843 S: bl/dl R: bl/hu
45375843 S：BL / DLのR：BL / HU MGCP 1.0 X ds/ds1-5/3@gw-t.whatever.net RQNT 4004
Step A4 The Gateways acks the request
A4ザ・ゲートウェイのACK要求ステップ
200 4004 OK
200 4004 OK
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もう一方の端がオンフックになることによって通話を解放し、A通知は、そのリリースが完了であることを示すためにコールエージェントに送信されます。
NTFY 1004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
O: ms/rlc (or dt/rlc)
In the case of Basic PBX, this is:
基本的なPBXの場合、これは次のとおりです。
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0 X: 45375843 O: bl/hu
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0 X：45375843 O：BL / HU
Step A6 The Call Agent returns an Ack
ステップA6ザ・コール・エージェントは、ACKを返します
200 1004 OK
200 1004 OK
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).
ステップ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)
Or in the case of Basic PBX ("BL" package):
または基本的なPBX（「BL」のパッケージ）の場合：
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0 X: 45375844 I: 34738A R: bl/hd
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0 X：45375844 I：34738A R：BL / HD
Step A8 The Gateway Acks and provides performance information.
A8ザ・ゲートウェイACKをステップとパフォーマンス情報を提供します。
250 4005 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
Step A9 The Call Agent sends a DLCX to the terminating gateway.
ステップA9ザ・コール・エージェントは、終端ゲートウェイに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)
Step A10 The gateway acks with performance information
性能情報とA10ゲートウェイACKをステップ
250 2004 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
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).
次のコールフローは、すべての基本的なPBX（ - 「DT」パッケージが似ている「MS」パッケージ）のためのコールを解除終了端の例を示します。
---------------------------------------------------------------------
| 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] -> |
---------------------------------------------------------------------
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.
以下は、同じコールフローを示したが、基本的な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] -> |
---------------------------------------------------------------------
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.
ステップA1 AnがオンフックPBXから受信されます。すべてが、「BL」のパッケージの場合、これは一時停止のためのイベント「SUS」と通知になります。
Step A2 The Call Agent returns an acknowledge
ステップA2ザ・コール・エージェントはアクノリッジを返します。
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.
Note that for Basic PBX (the "BL" package), steps A3 - A6 are missing (these steps do not exist for basic PBX).
A6（これらのステップは、基本的なPBXのために存在していない）不足している - 基本的なPBX（「BL」のパッケージ）のためなお、A3を繰り返します。
Step A3 A "sus" signal is sent to the originating side resulting in a on-hook being sent to the originating PBX.
ステップA3 A「SUS」信号がオンフック発信PBXに送信され、その結果、発信側に送信されます。
Step A4 GW-o acks the request.
A4 GW-O要求ACKをステップ。
Step A5 The Call Agent sends a request to see off-hook or resume ("res") events.
ステップA5ザ・コール・エージェントは、（「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.
注意：このコールエージェントが/再開処理を中断やりたいかどうかに依存します。ない場合は、コールエージェントは、単に両端にDLCXと一緒に「REL」を送ることができます。
Step A6 GW-t acks the request.
要求のACK A6 GW-Tステップ。
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).
ステップA7 Anがオンフックイベント「REL」とGW-oから通知もたらす発信PBX（「HU」基本PBXインターフェイスの）から受信されます。
Step A8 The Call Agent "acks"
ステップA8ザ・コール・エージェント「のACK」
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)
A9 Aは接続を削除するステップは、（ - そのような信号がない基本的なPBXを除く）終端PBXに送信されるオンフックになる信号「REL」と終端ゲートウェイに送信されます
Step A10 GW-t acks the DLCX and provides performance information
ステップA10 GW-T DLCX ACKは及び性能情報を提供します
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
A12コール・エージェント「ACKを」ステップ通知
Step A13 A delete connection is sent to the originating side (with signal "rlc" except in the case of the "BL" package).
ステップA13削除接続（「BL」パッケージの場合を除いて、信号「RLC」で）発信側に送信されます。
Step A14 GW-o returns an "ack" with performance information.
ステップA14 GW-Oは、性能情報と、「ACK」を返します。
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 |
---------------------------------------------------------------------
Step A1 PBX rings results in a notify to the Call Agent indicating the start of a call setup:
ステップA1のPBXリング結果は、コールセットアップの開始を示すコール・エージェントに通知します：
NTFY 3001 aaln/0@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: do/rg
Step A2 The Call Agent sends an Ack:
ステップA2ザ・コール・エージェントは、ACKを送信します。
Step B1 The Call Agent now requests that a receive-only connection be made.
コールエージェントB1ステップは現在、受信専用の接続がなされることを要求します。
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.
Step B2 The Gateway acks with a connection ID and provides the SDP information.
ステップB2は、ゲートウェイのACKコネクションIDを有するとは、SDP情報を提供します。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
CallエージェントB3ステップは、接続要求の一部として、終端ゲートウェイ（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のコールエージェントが接続モードに変更接続要求が受信専用発信ゲートウェイに送信し、終端ゲートウェイから選択されたプロファイルとの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:
ステップ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
Note that the result of the "sup" signal is the following sequence on the interface to the PBX:
「SUP」信号の結果は、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
200 4002 OK
Step C3 When the digits have been completely sent out, the gateway will notify the fact by indicate that the operation is complete.
ステップC3数字が完全に送り出されてきた場合には、ゲートウェイは、操作が完了したことを示すことで事実を通知します。
NTFY 1001 aaln/0@gw-t.whatever.net MGCP 1.0
X: 45375841
O: do/oc(do/sup)
Step C4 The Call Agent acks the notify
C4ザ・コール・エージェントは通知ACKのステップ
200 1001 OK
200 1001 OK
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.
ステップC5ザ・コール・エージェントは現在、全二重接続をするために要求を送信し、もう一方の端が電話に答えたことを示します。
If the endpoint is running FXO ground-start, the call would also
requests detection of disconnect supervision from the PBX
(R:do/rel)
Step C6 The Gateway acks the request
要求のACK C6ザ・ゲートウェイステップ
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.
（：DO / REL R）をステップC7エンドポイントは、FXOグラウンドスタートを実行している場合は、コールエージェントはトランクがリリースされる際に通知要求は言わなければ送信します。エンドポイントがFXOループスタートを実行している場合、このステップとステップC8は必要ありません。
Step C8 The gateway acks the request and the call is now setup.
要求のACK C8にゲートウェイをステップと、コールは現在の設定です。
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は、呼解放を開始することはできません。この場合、呼解放は常にオンフック行くことによって、メディアゲートウェイによって開始されます。 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] |
---------------------------------------------------------------------
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).
ステップA1発信PBXトランク（通常解除を示す理由を）解放されていることを示すために、オンフックゲートウェイからの通知をもたらす進みます。
NTFY 3005 aaln/0@gw-o.whatever.net MGCP 1.0
X: 45375842
O: do/rel(0)
Step A2 The Call Agent Acks the Notify
A2ザ・コール・エージェントは通知ACKのステップ
200 3005 OK
200 3005 OK
Step A3 The Call Agent sends a request to release the trunk.
ステップA3ザ・コール・エージェントは、トランクを解放するための要求を送信します。
Step A4 The Gateways acks the request
A4ザ・ゲートウェイのACK要求ステップ
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は、先端-地面を解放することによって、コールを解放し、通知後、そのリリースが完了であることを示すためにコールエージェントに送信されます。
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.
Step A6 The Call Agent returns an Ack
ステップA6ザ・コール・エージェントは、ACKを返します
Step A7 The Call Agent sends a delete connection to the originating gateway with a request to go onhook.
ステップA7ザ・コール・エージェントは、オンフックするための要求と発信ゲートウェイへの削除の接続を送信します。
Step A8 The Gateway Acks and provides performance information.
A8ザ・ゲートウェイACKをステップとパフォーマンス情報を提供します。
Step A9 The Call Agent sends a DLCX to the terminating gateway.
ステップA9ザ・コール・エージェントは、終端ゲートウェイにDLCXを送信します。
Step A10 The gateway acks with performance information
性能情報とA10ゲートウェイACKをステップ
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」のパッケージを使用して、グループ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 -> |
---------------------------------------------------------------------
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".
「：ループQ」の仮定は、最初は「通知」前に、コールエージェントは、検疫処理を使用して「SUP」と「INF」のイベントが通知される要求を送信したことです。
Step A1 Trunk seizure results in a notify to the Call Agent indicating the start of a call setup:
コールセットアップの開始を示すコール・エージェントに通知してA1トランク発作の結果をステップ：
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
Step A2 The Call Agent sends an Ack.
ステップA2ザ・コール・エージェントは、ACKを送信します。
Step A3 Once the digits for the identification field are collected the gateway notifies the call agent:
識別フィールドの桁が収集されると、ゲートウェイは、コールエージェントに通知するA3ステップ。
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)
Step A4 The Call Agent responds with an ack.
ステップA4ザ・コール・エージェントは、ACKで応答します。
Step A5 When the digits are collected for the address field, another notify is sent:
数字はアドレスフィールドのために収集されているステップA5、別の通知が送信されます。
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)
Step A6 The Call Agent "acks"
ステップA6ザ・コール・エージェント「のACK」
Step B1 Create connection - receive only:
ステップB1は、接続を作成します - 受信のみ：
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
Step B2 The Gateway "acks" the request and provides connection ID and SDP information.
ステップB2ゲートウェイ「のACK」リクエスト及び接続IDとSDP情報を提供します。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
CallエージェントB3ステップは、接続要求の一部として、終端ゲートウェイ（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のコールエージェントが接続モードに変更接続要求が受信専用発信ゲートウェイに送信し、終端ゲートウェイから選択されたプロファイルとのSDP情報を含みます。
Step B6 The Gateway Acks the modify connection request.
ステップB6ザ・ゲートウェイACKは、接続要求を変更します。
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 -> |
---------------------------------------------------------------------
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".
「：ループQ」の仮定は、最初は「通知」前に、コールエージェントは、検疫処理を使用して「SUP」と「INF」のイベントが通知される要求を送信したことです。
Step A1 Trunk seizure results in a notify to the Call Agent indicating the start of a call setup:
コールセットアップの開始を示すコール・エージェントに通知してA1トランク発作の結果をステップ：
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
Step A2 The Call Agent sends an Ack
ステップA2ザ・コール・エージェントは、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)
Step A4 The Call Agent responds with an ack
ステップA4ザ・コール・エージェントは、ACKで応答します
Step A5 The Call Agent does processing on the country address field and sends a request to initiate further input (sends a continue wink):
ステップA5ザ・コール・エージェントは、国のアドレスフィールドに処理を行い、（継続ウインクを送信します）、さらに入力を開始する要求を送信します。
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/inf,md/rel
S: md/cwk
Step A6 The Gateway "acks" the request.
A6ザ・ゲートウェイ「のACK」リクエストをステップ。
Step A7 Once the digits for the identification field are collected the gateway notifies the call agent:
識別フィールドの桁が収集されると、ゲートウェイは、コールエージェントに通知するステップA7：
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)
Step A8 The Call Agent responds with an ack
ステップA8ザ・コール・エージェントは、ACKで応答します
Step A9 When the digits are collected for the address field, another notify is sent:
数字はアドレスフィールドのために収集されているステップA9、別の通知が送信されます。
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)
Step A10 The Call Agent "acks"
ステップA10コール・エージェント「のACK」
Step B1 Create connection - receive only:
ステップB1は、接続を作成します - 受信のみ：
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
Step B2 The Gateway "acks" the request and provides connection ID and SDP information
ステップB2ゲートウェイ「のACK」リクエスト及び接続IDとSDP情報を提供します
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
CallエージェントB3ステップは、接続要求の一部として、終端ゲートウェイ（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のコールエージェントが接続モードに変更接続要求が受信専用発信ゲートウェイに送信し、終端ゲートウェイから選択されたプロファイルとの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 |
---------------------------------------------------------------------
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:
ステップC1ザ・コール・エージェントは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
Note that the result of the "sup" signal is the following sequence on the interface to the PBX:
「SUP」信号の結果は、PBXへのインタフェース上で、以下の配列であることに注意してください。
* off-hook -> SCN * wink <- SCN * caller ID digits sent to SCN * address digits sent to SCN
*オフフック - > SCN *ウインク< - SCNに送られたSCN SCNに送信*発信者IDの桁*アドレスの数字
Step C2 The gateway responds with an ack
ステップC2ザゲートウェイは、ACKで応答します
Step C3 "Notify" the CA that the start of signaling has occurred (incoming wink start has occurred) i.e.:
C3のステップすなわち（着信ウィンクスタートが発生した）シグナル伝達の開始が発生したことをCAを「通知」.:
NTFY 3000 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/swk
Step C4 The Call Agent "acks".
C4ザ・コール・エージェント「ACKを」ステップ。
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)
Step C6 The Call Agent "acks".
C6ザ・コール・エージェント「ACKを」ステップ。
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
Step C8 The Call Agent "acks".
C8ザ・コール・エージェント「ACKを」ステップ。
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
Step C10 GW-o "acks".
C10 GW-O "ACKを" ステップ。
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
Step C12 The Call Agent "acks".
C12ザ・コール・エージェント「ACKを」ステップ。
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)
ステップC13ザ・コール・エージェントは現在、全二重接続をするために要求を送信し、もう一方の端が電話応答したことを示している（Sを次のようになります。ans送っ）
Step C14 The Gateway acks the request
要求のACK C14ザ・ゲートウェイステップ
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:
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
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0 X：45375841 Q：ループS：MD / SUP（CT（NTA）、カリフォルニア州（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
If overlapped sending is done, only the country address and caller ID digit strings are sent out in step C1:
オーバーラップ送信が行われた場合、唯一の国アドレスと、発信者IDの数字列は、ステップC1に送信されます：
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
MGCP 1.0 ds/ds1-5/3@gw-t.whatever.net RQNT 2001
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 / 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
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（SUP）」を出て行き、コールエージェントはアドレス情報を持っているとすぐに、それは「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)
RQNT 2002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0 X：0123456789B1 Q：ループ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）
The Call Agent will then get a further "md/oc(md/sup)" event when these digits have gone out.
コール・エージェントは、その後さらに、「MD / OC（MD / SUP）」これらの数字が出てきたイベントを取得します。
Step C15 The Call Agent requests to be told of on-hook ("sus") events or abnormal release ("rel") events.
ステップC15ザ・コール・エージェントの要求は、オンフック（「SUS」）イベントや異常なリリース（「相対」）イベントの語られます。
Step C16 The gateway "acks" the request.
C16にゲートウェイ「のACK」リクエストをステップ。
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」パッケージを使用して、コールセットアップ（911コール）のシグナリング機能グループDのオペレータサービスについて説明します。表には従うべき詳細とコールフローの最初の部分の概要を説明します。この場合、GW-O線パッケージとGW-Tを用いて、レジデンシャルゲートウェイは、E911の直列に接続されています。
---------------------------------------------------------------------
| 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 -> |
---------------------------------------------------------------------
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
Step A2 The Call Agent sends an Ack:
ステップA2ザ・コール・エージェントは、ACKを送信します。
200 3001 OK
200 3001 OK
Step A3 The Call Agent sends dial-tone and requests that digits be collected:
ステップA3ザ・コール・エージェントは、数字を収集するダイヤルトーンとリクエストを送信します。
RQNT 2001 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
S: l/dl
R: d/[0-9#*T](D), hu
Step A4 The gateway responds with an ack:
ゲートウェイがACKで応答A4ステップ：
200 2001 OK
200 2001 OK
Step A5 Once the digits are collected the gateway notifies the Call Agent. In this case, it is a 911 call
数字は、ゲートウェイがコールエージェントに通知収集されるとステップA5。この場合、それは911の呼び出しです
NTFY 3002 aaln/1@gw-o.whatever.net MGCP 1.0
X: 0123456789B0
O: d/9,d/1,d/1
Step A6 The Call Agent responds with an ack:
ステップA6ザ・コール・エージェントは、ACKで応答します。
200 3002 OK
200 3002 OK
Step B1 The Call Agent now requests that a receive-only connection be made.
コールエージェントB1ステップは現在、受信専用の接続がなされることを要求します。
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.
Step B2 The Gateway acks with a connection ID and provides the SDP information:
ステップB2ゲートウェイのACKコネクションIDを有するとSDP情報を提供するが：
200 2002 OK
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 = 0 0 = - A7453949499 0 IP4 IN 128.96.41.1 S = - C = IP4 IN 128.96.41.1 T = 0、M =オーディオ3456 RTP / AVP 0
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:
ステップB3 Callエージェントは、接続要求の一部として、終端ゲートウェイ（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
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))
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 = 0 0 = - A7453949499 0 IP4 IN 128.96.41.1 S = - C = IP4 IN 128.96.41.1 T = 0、M =オーディオ3456 RTP / AVP 0
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および回線交換ネットワーク（SCN - この場合、E911タンデム）との間で発生します。
* Off-hook -> SCN
* Wink <- SCN
* k0,9,1,1,s2 -> SCN
* Off-hook <- 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からのプロトコル（発信者IDのための要求）の一部であり、オペレータが応答するか否かの指示を提供しないことに注意してください。
Step B4 The terminating gateway, responds with an ack and its SDP information:
ステップB4終端ゲートウェイは、ACKおよびそのSDP情報で応答します。
200 4001 OK
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 = 0 0 = - A7453949499 0 IP4 47.123.34.33におけるS = - C = IP4 IN 47.123.34.33 T = 0、M =オーディオ3456 RTP / AVP 0
Step B5 The Call Agent will get a further notify when outpulsing of all of the digits is complete.
ステップB5コールエージェントは、すべての桁のoutpulsingが完了したときに通知し、さらに取得します。
NTFY 3003 aaln/1@gw-o.whatever.net MGCP 1.0
MGCP 1.0 aaln/1@gw-o.whatever.net NTFY 3003
X: 45375840 O: oc(sup)
X：45375840 O：OC（SUP）
Step B6 The Call Agent returns an "ack"
コールエージェントB6ステップは、「ACK」を返します
200 3003 OK
200 3003 OK
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コールエージェントが接続モードに変更接続要求が受信専用発信ゲートウェイに送信し、終端ゲートウェイから選択されたプロファイルとのSDP情報を含みます。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 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 = 0 0 = - A7453949499 0 IP4 47.123.34.33におけるS = - C = IP4 IN 47.123.34.33 T = 0、M =オーディオ3456 RTP / AVP 0
Step B8 The Gateway Acks the modify connection request
ステップB8ゲートウェイAcksを接続要求を変更
200 2003 OK
200 2003 OK
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.
シスコシステムズ、そしてドン・スタンウィック - - IPユニティいくつかのソースは、これらのパッケージは、フレミングAndreasenの、ワイ・徳・シウです。彼のCASインターフェイスの専門知識のためのジョー・クラーク、Telcordiaの技術に感謝します。また、すべての彼らのコメントのためのすべてのレビューのおかげで、以下の人々を含むがこれらに限定されない：チャールズ・Eckel氏、シスコシステムズ、ジェリーKamitses、ソナス・ネットワーク。
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]アランゴ、M.、デュガン、A.、エリオット、I.、のHuitema、C.及びS.ピケット、 "メディアゲートウェイ制御プロトコル（MGCP）バージョン1.0"、RFC 2705、1999年10月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[3] Bellcore, Compatibility Information for Feature Group D Switched Access Service, TR-NPL-000258, Issue 1, October 1985.
機能グループDのための[3]のBellcore、互換性情報は、アクセスサービス、TR-NPL-000258、1号、1985年10月に交換しました。
[4] Bellcore, Interoffice LATA Switching Systems Generic Requirements (LSSGR): Verification Connections (25-05-0903), TR-TSY-000531, Issue 2, July 1987.
[4]ベルコア、局間LATAスイッチングシステムの一般的な要件（LSSGR）：TR-TSY-000531検証接続（25-05-0903）、2号、1987年7月。
[5] Bellcore, LSSGR: Signaling for Analog Interfaces, GR-506-CORE, Issue 1, June 1996.
[5]ベルコア、LSSGR：アナログインターフェイス、GR-506-CORE、第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西タスマン博士サンノゼ、CA、95134
Phone: 408-527-8791 EMail: bfoster@cisco.com
電話：408-527-8791 Eメール：bfoster@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。