[要約] RFC 3064は、MGCP（Media Gateway Control Protocol）CAS（Channel Associated Signaling）パッケージに関する仕様です。このRFCの目的は、MGCPを使用してCAS信号化をサポートするためのパッケージを定義することです。
Network Working Group B. Foster
Request for Comments: 3064 Cisco Systems
Category: Informational February 2001
MGCP CAS Packages
MGCP CASパッケージ
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.
Copyright（c）The Internet Society（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インターコネクト、および基本的なFXOサポートのメディアゲートウェイチャネル関連シグナル伝達（CAS）パッケージのコレクションが含まれています。6つのパッケージが含まれています。「MS」パッケージは、MFシングルステージダイヤルトランクをカバーしています。これには、Wink Startおよび即時開始PBX DID/DODトランク、および基本的なR1および特徴グループD（FGD）終了プロトコル[3]が含まれます。「DT」パッケージは、即時の開始と基本的なDTMFおよびダイヤルパルストランクをカバーし、「BL」パッケージは基本的なPBX（デジタルまたはFXSインターフェイス）へのインターフェイスをカバーします。終了プロトコルに加えて、[3]で説明されている他の3つのFGDプロトコルがあります。これらには、囲まれた「MD」パッケージと「MO」パッケージによって処理されるオペレーターサービスシグナリングプロトコルでカバーされるEAINとEANAが含まれます。基本的なFXO Interconnectのサポートは、「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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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
1.0.Introduction
1.0.introduction
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).
* コールエージェントに何らかの合理的なレベルの抽象化を提供して、可能な場合にコールフローを再利用できるようにします（たとえば、コールエージェントは、1桁の文字列のみが関与している場合、ウィンクスタートと即時開始インターフェイスを区別する必要はありません）。
* 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).
a) これにより、コールエージェントの抽象インターフェイスが許可されているため、たとえば、MF Wink Startと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.
アウトパルスアプローチ：補助するためのセマンティクスを提供するために、必要なセマンティクスを含む特別な高レベルの信号（たとえば、コールセットアップの「sup」、情報の「inf」が含まれています）が含まれています。
Off-hook and On-hook Signals and Events: A higher level view of off-hook and on-hook events is taken in order to make the interface Q.931-like. This provides the advantage that:
オフフックおよびオンフックの信号とイベント：インターフェイスQ.931のようにするために、オフフックおよびオンフックイベントのより高いレベルのビューが取られます。これは、次の利点を提供します。
* Similar call flows result when dealing with Q.931-based interfaces (e.g., PRI)
* Q.931ベースのインターフェイス（例：PRI）を扱う場合、同様のコールフローの結果が生じます
* It's more evident (for ease in debug) when looking at message as to exactly what is going on without having to refer to previous events
* 以前のイベントを参照せずに正確に何が起こっているかについてメッセージを見ると、それはより明白です（デバッグで簡単に）
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.
以下は、さまざまなパッケージによってサポートされるトランクの種類について説明しています。特定のトランクタイプの構成（たとえば、Wink Start vsIcent Start）は、MGCPの範囲外のプロビジョニング機能を介してメディアゲートウェイ（MG）内で行われます。コールエージェントの責任は、特定のパッケージをサポートすることです（つまり、一般に、コールエージェントは、これらの違いがMGによって世話されるため、Winkの開始と即時開始を区別する必要はありません）。ただし、コールエージェントは、どのトランクが着信、発信、または双方向であるかを知る必要があります。
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]).
「MS」パッケージは、次の表に示されているように、PBX DID/DODトランクに使用されます。また、受信または発信MFウィンクスタートトランク（R1およびFGD終端プロトコル[6]）にも使用されます。
Table 1 MF PBX Trunks
表1MF 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:
DTMFおよびダイヤルパルス（DP）トランク（基本的なPBXを除く）は、DTMF「D」パッケージとともに「DT」パッケージでカバーされています。
Table 2 DTMF and DP Wink Start and Immediate Start Trunks
表2 DTMFおよびDPウィンクの開始と即時スタートトランク
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|DTMF, Immediate |Incoming (originate from PBX) |
| start, wink | |
| start | |
|DTMF, Immediate |Outgoing (terminate on PBX) |
| start, wink | |
| start | |
--------------------------------------------------
DTMF and dial-pulse (DP) basic PBX trunks are covered by the "BL" package - along with the DTMF "D" package (essentially this is like a "basic line with no features") - either digital or FXS trunk interface:
DTMFおよびダイヤルパルス（DP）基本的なPBXトランクは、「BL」パッケージとDTMF「D」パッケージとともにカバーされています（基本的にこれは「機能なしの基本ライン」のようなものです） - デジタルまたはFXSトランクインターフェイスのいずれかです。
Table 3 Basic FXS Interface
表3基本的なFXSインターフェイス
--------------------------------------
| Trunk Type | Direction |
| | (w.r.t. the gateway) |
--------------------------------------
|Basic, DTMF and |Bi-directional |
|DP, Loop Start | |
|Basic, DTMF and |Bi-directional |
|DP, Ground Start| |
--------------------------------------
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.
* 説明イベント/信号の簡単な説明。
* 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」）を監査できる目的は、2つの質問のいずれかに答えることであることに注意してください。
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. このライン/トランクで呼び出しが開始されましたか？たとえば、以下のパッケージでは、コールセットアップの開始は、「SUP」イベントまたは「HD」（FXS-「BL」パッケージ）のいずれかによって示されます。「RG」イベントでは、これらのイベントがイベント列に「S」があり、監査可能であることを示します。
2. The other question of interest is to know whether the telephony leg of the call is in the idle state so that a new call can be initiated. This is indicate by the "rlc" (release complete) event-state for packages that have that event.
2. 興味のあるもう1つの問題は、新しい呼び出しを開始できるように、コールのテレフォニーレッグがアイドル状態にあるかどうかを知ることです。これは、そのイベントがあるパッケージの「RLC」（Release Complete）イベント状態によって示されます。
* 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」オン/オフ信号。シグナルは、コールエージェントがオフにするように命令されるまでオンになり、その逆も同様です。 - "to"タイムアウト信号。信号は、新しい信号に取って代わったり、イベントの検出時に終了したりしない限り、特定の期間にわたって持続します。デフォルトのタイムアウト値が提供されます。ゼロの値は、タイムアウト期間が無限であることを示します。プロビジョニングプロセスは、これらのデフォルト値を変更する場合があります。 - 「BR」短い信号。信号の期間は短いです。
* Additional info Provides additional information about the event/signal, e.g., the default duration of TO signals.
* 追加情報は、イベント/信号に関する追加情報、たとえば信号のデフォルトの期間を提供します。
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.
特に明記しない限り、すべてのイベント/信号はエンドポイントで検出/適用され、それらによって生成されたオーディオは、エンドポイントの接続に転送されません。ただし、接続で検出/適用されるイベント/信号によって生成されるオーディオは、接続モードに関係なく関連する接続に転送されます。
2.1. Events and Signals for the "MS" package:
2.1. 「MS」パッケージのイベントと信号：
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 | |
---------------------------------------------------------------------
2.2. Events and Signals for the "DT" package:
2.2. 「DT」パッケージのイベントと信号：
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 |
---------------------------------------------------------------------
2.4. Events and Signals for the "DO" package:
2.4. 「do」パッケージのイベントと信号：
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 |
---------------------------------------------------------------------
2.5. Events and Signals for the "MD" package:
2.5. 「MD」パッケージのイベントと信号：
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 | - | |
---------------------------------------------------------------------
2.6. Events and Signals for the "MO" package:
2.6. 「MO」パッケージのイベントと信号：
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).
Call Answer（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.
謝辞Wink（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.
コールブロック（bl; s br; dt、ms、md）：それ以上の呼び出しが受け入れられないことを示すために、一方向の入ってくるトランクに適用される安定したオフフック信号。「BL」が信号として使用される場合、「REL」信号を使用してブロッキング条件を解放します。
A Call Agent should only request the "bl" event in a case where it knows that this is a one-way outgoing trunk, and it should never see an incoming call-setup request ("sup" event). As such if "bl" is requested as an event, then "sup" is suppressed as a persistent event.
コールエージェントは、これが一方向の発信トランクであることを知っている場合にのみ「BL」イベントを要求する必要があり、着信コールセットアップリクエスト（「SUP」イベント）が表示されることはありません。そのため、「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を参照してください。トーンの定義は、国家の特性によって定義され、プロビジョニングによって確立される場合があります。ステーションビジーは、GR-506-CORE-LSSGR、シグナル伝達、セクション17.2.6で定義されています。2つのACトーンと480および620 HERTZの周波数とそれぞれ-24 dBMのレベルの組み合わせとして、-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を参照してください。3つのフィールドはそれぞれオプションですが、それぞれのコンマは常に含まれます。
The time parameter is coded as "MM/DD/HH/MM", where MM is a two-digit value for Month between 01 and 12, DD is a two-digit value for Day between 1 and 31, and Hour and Minute are two-digit values coded according to military local time, e.g., 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m.
時間パラメーターは「mm/dd/hh/mm」としてコード化されています。ここで、mmは01〜12の間の月の2桁の値です。DDは1日から31日の2桁の値であり、時間と分は2桁の値です。軍事現地時間に従ってコード化された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.
名前パラメーターは、呼び出し線名を識別する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)
O：CI（10/14/17/26、 "555 1212"、somename）
Continue Wink (cwk ; - + BR; MD): This signal is only applicable to the "md" package. It provides an indication that digits sent have been accepted, and further digits must be sent in order to process the call. For example, when using FGD EAIN signaling, this would correspond to sending a wink after the country access code had been received to indicate readiness to receive identification and address fields.
Continue Wink（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トーンは、2つの連続ACトーンと350および440 HERTZの周波数と-13dBMのレベルの組み合わせとして定義され、それぞれ-10 dBMの合計レベルが得られます。。フックにある電話でダイヤルトーンを再生しようとするのはエラーと見なされます。その結果、そのような試行が行われたときにエラーが返される必要があります（エラーコード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-digits>）; 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-digits>はすべて、桁デリミター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
<inf-digits>の値は、MF桁のコンマ分離リストです：MF1、MF2、...、MFN
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:
操作Complete（oc; x - ; all）：操作完全イベントは、ゲートウェイがエンドポイント上にタイプの1つまたは複数の信号を適用するように求められたときに生成され、それらの信号の1つ以上が完了して完了し、停止することなく完了しました。セットアップなどの要求または永続的なイベント。完了レポートは、次のように、ライブタイムの終わりに至った信号の名前をパラメーターとして伝達する場合があります。
O: ms/oc(ms/sup)
O：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.
操作完全イベントが要求された場合、どのイベントパラメーターでもパラメーター化することはできません。
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)
O：ms/of（ms/sup）
or
または又はそれとも若しくは乃至或るいは
O: bl/of(bl/rg)
O：bl/of（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).
オペレーターのringback（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.
逆にするには逆になります（rbz; p-; 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」イベントで応答します。通話のテレフォニーレッグに関連するリソースをリリースしても、既存の接続（ネットワーク脚）には影響しません。そのエンドポイントへのネットワーク接続をリリースするために、適切な削除接続コマンドを送信するのはコールエージェント次第です。
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:
Media Gatewayは、コールの発生端（通常のリリース）からのオンフックイベントの結果として、またはコールのリリースをもたらした異常なイベントにより、コールがリリースされるたびに「リリースコール」イベントを生成します。このイベントは、リリースの理由を示す次の原因コードのいずれかでパラメーター化される場合があります。
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」信号を送信することにより）をリリースします。
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）：これは、呼び出された当事者がコールを再開したことを示しています。（ "rel"）トランク。「SUS」および「RES」イベント/信号は、コールに関連付けられたリソースをリリースすることなく、オンフックおよびオフフックイベントを伝播するために使用されます。オペレーターサービスのケース（「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).
ただし、「一時停止」/「再開」処理を行うかどうかを決定するのは、コールエージェント次第です。そうでない場合、コールの終了端から「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).
リンギング（rg; p、s to; 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.
リリースComplete（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; - ; BL、DT、MD、MS）：Reorder Toneは、2つのACトーンと480および620 HERTZの周波数とそれぞれ-24 dBMのレベルを組み合わせて、-21 dBMの合計レベルを提供する。再注文のケイデンスは0.25秒で、その後0.25秒オフが続き、継続的に繰り返されます。GR-506-CORE-LSSGR：シグナリング、セクション17.2.7を参照してください。
Ring back tone (rt; - + TO; BL,DT,MD,MS): Audible Ring Tone is a combination of two AC tones with frequencies of 440 and 480 Hertz and levels of -19 dBm each, to give a combined level of -16 dBm. In the US the cadence for Audible Ring Tone is defined to be 2 seconds on followed by 4 seconds off. The definition of the tone is defined by the national characteristics of the Ring-back Tone, and MAY be established via provisioning. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.5.
リングバックトーン（rt; - to; bl、dt、md、ms）：可聴リングトーンは、2つのACトーンと440および480の周波数とそれぞれ-19 dBMのレベルの組み合わせであり、 - 合計レベルの - 16 dBm。米国では、可聴着信音のリズムは2秒で4秒オフであると定義されています。トーンの定義は、リングバックトーンの国家的特徴によって定義され、プロビジョニングによって確立される場合があります。GR-506-CORE-LSSGR：シグナル、セクション17.2.5を参照してください。
Call Setup (sup ; P,S + TO; DO,DT,MD,MS,MO): The event/signal is used both for outgoing and incoming call setups. Each will be described separately in the following.
コールセットアップ（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>）でパラメーター化されます。これらのパラメーターの順序は重要ではありません。次の表は、さまざまなパッケージの必須（ "m"）、オプション（ "o"）、または禁止（ "f"）を示します。
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
addr(dig1, dig2, ..., dign)
addr（dig1、dig2、...、sign）
The <id> field contains the identification of the caller and when present will be of the form:
<id>フィールドには発信者の識別が含まれており、存在する場合は次のとおりです。
id(dig1, dig2, ..., dign)
id（dig1、dig2、...、sign）
The <ca> field contains the country address information and when present will be of the form:
<ca>フィールドには国の住所情報が含まれており、存在する場合は次のとおりです。
ca(dig1, dig2, ..., dign)
ca（dig1、dig2、...、sign）
When present, the <addr> field contains the destination number and will be of the form
存在する場合、<addr>フィールドには宛先番号が含まれ、フォームになります
addr(dig1, dig2, ..., dign)
addr（dig1、dig2、...、sign）
where digi is an MF symbol as defined in table 11 in the case of "MS", "MO", and "MD" packages and digi is a DTMF symbol (0-9, *,#,A,B,C,D) in the case of the "DT" and "DO" packages.
ここで、Digiは「MS」、「MO」、および「MD」パッケージの場合、表11で定義されているMFシンボルであり、DigiはDTMFシンボル（0-9、 *、＃、A、B、C、D）「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):
次の表は、シングルステージの排出アプリケーション（「DT」、「MS」、「DO」パッケージ）のメディアゲートウェイ（MG）とスイッチド回路ネットワーク（SCN）との相互作用を示しています。
Table 14 SCN Sequencing during Call Setup (single stage outpulsing)
表14コールセットアップ中のSCNシーケンス（シングルステージの追い越し）
------------------------------------------------------------------
|Interface Type |Setup | Interactions |
|------------------------------------------------------------------|
|wink start |sup(add(<addrvalue>)) |MG| off-hook -> |SCN|
| | |MG| <- wink |SCN|
| | |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
|Immediate Start|(sup(addr(<addrvalue>)) |MG| off-hook -> |SCN|
| or FXO) | |MG| <addrvalue> -> |SCN|
------------------------------------------------------------------
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シーケンス（EANAおよびEAIN）
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| addr(<addrvalue>), id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------
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))
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)
表16コールセットアップ中のSCNシーケンスossプロトコル（ "mo"パッケージ）
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <- off-hook |SCN|
| |MG| <addrvalue> -> |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------
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.
一時停止（SUS; P BR; DT、MD、MS、MO）：Suspend（ "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」の後に「RES」（オフフック）が続き、呼び出しが再開されますが、「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.
E911（ "Mo"パッケージ）の場合、オペレーターは通常、コールのリリースを制御しているため、「sus」（on-hook）、 "res"（off-hook）、 "rcl"（flash-hook）になります。通話をリリースせずにユーザーフックイベントをオペレーターに渡すために使用されます。
Start Wink (swk; x + - MD,MO):. An Call Agent can optionally request the MG to notify it when the wink start signal occurs. Note that wink start ("swk") cannot be applied by the Call Agent as a signal. The occurrence of wink-start on an incoming trunk is a reflexive action that does not require Call Agent involvement.
Winkを開始（SWK; X -MD、MO）：。コールエージェントは、オプションで、Wink Start Signalが発生したときにMGに通知を要求することができます。Wink Start（ "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:
導入部で述べたように、多くのCASパッケージのオンフックイベントやオフフックイベントでは、インターフェイスをQ.931に似たものにするために、より高いレベルのビューが取られます。これは、次の利点を提供します。
* Similar call flows result as when dealing with Q.931-based interfaces (e.g., PRI) * It's more evident (for ease in debug) when looking at message as to exactly what is going on without having to refer to previous flows.
* Q.931ベースのインターフェイス（PRIなど） *を扱う場合、以前のフローを参照せずに何が起こっているのかを正確に見ているときに、より明確になります。
This does require that media gateways maintain some state but this is a relatively small price to pay.
これには、メディアゲートウェイがある状態を維持する必要がありますが、これは比較的小さい価格です。
One example of this is the "sup" signal which involves sending off-hook followed by digits as a high level signal. The "ans" event is also used to represent off-hook but from the terminating end at the point where the call is answered.
これの1つの例は、「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」、「resume for rel」の「sus」、および「Rel」は、一方の端（オリジネーター）がコールを制御しているという概念に基づいています。制御端がオンフックになった場合、「REL」がコールエージェントに通知され、その結果、コールがリリースされます。ただし、非制御（終了）端がオンフックになると、（「Rel」イベントの代わりに）「SUS」イベントが発生します。これにより、コールエージェントは、中断/履歴書処理を行うオプションを提供します。
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」をIngress Gatewayに戻すように伝播するオプションがあり、コール（「Rel」イベント）をリリースする機会を与えます。いずれにせよ、「SUS」と「RES」信号の使用は、オンフックを送信するだけでなく、コールのテレフォニーレッグに関連するリソースをリリースする「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」信号を送信する場合、呼び出しを放棄するように要求しています（つまり、「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」信号は、接続を完全にリリースするには、接続を含むコールを完全にリリースするには、信号「rel」に加えて（または接続する）dlcxが必要になることを意味するものではありません。
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.
* コールエージェントは「REL」を送信してトランクをリリースし、そのトランクに発信オフハックが送信されます。メディアゲートウェイが反対側からオンフックを受信すると、トランクがリリースされ利用可能であることを示す「RLC」イベントを返します。*メディアゲートウェイは、コールの制御端でトランクからオンフックを受け取り、「rel」イベントがコールエージェントに送信されます。その後、コールエージェントはメディアゲートウェイに「RLC」を送信し、その結果、オンフックが反対方向に送信されます。*メディアゲートウェイがコールのテレフォニーレッグを維持できない異常な条件がある場合、「rel」イベントがコールエージェントに送信されます（例：グレア条件）。コールエージェントは、「RLC」をゲートウェイに送信して、コールのリリースを完了します。（「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が最初にコールをリリースした場合（リリースを完了するためにコールエージェントからS：HUが続く）場合、信号「REL」が使用されます。あるいは、コールエージェントはS：HUを送信してリリースを開始することができます。その後、PBXがTIPグラウンドリリースを行うときに、メディアゲートウェイから「RLC」イベントがエージェントを呼び出します。ループスタートのトランクには通常、この動作はありませんが（グラウンドスタートにのみ適用されます）、メディアゲートウェイは、コールエージェントに共通のインターフェイスを許可するために、ループスタートの場合の動作をエミュレートする必要があります。
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」信号は、終端側に桁を上回るオフフックを提供します。*補助が完了すると、「ANS」イベントは終了側からのオフフックを示します（呼び出されたパーティーが答えました）。*コールエージェントは、「ANS」信号（オフフック）を元の端に送信して、呼び出した当事者が回答したことを発信者に示すことができます。*コールエージェントは、いずれかの端に「Rel」をいつでも送信して、コールを取り壊すことができます（たとえば、コールを中止する）。*メディアゲートウェイは、「REL」を送信して、コールの異常な終了を示すことができます（パラメーターとして理由があります）。*ただし、コールが確立されると通常の操作の下で、コールエージェントは終了端から「SUS」（サスペンド）イベントを予想して、呼び出されたパーティーがオフになった場合に発信者がオンフックになり、「RE」が「res」になったことを示すことができます。コールエージェントがコールを引き裂く前に再びフックします。コールエージェントは、これらの同じ信号を元の端に送信して、コールを引き裂くことなく、オフハックとオンフックを呼び出しパーティーに示すことができます。*通常の操作中に、呼び出しが確立されると、呼び出しパーティー（Origination Side）のオンフックが「Rel」信号になります。コールエージェントは通常、コールを終了するために「rel」信号を終了端に送信します。「RELの後には「RLC」が続きます（たとえば、メディアゲートウェイは「REL」を使用した呼び出しパーティーを示し、コールエージェントは「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.
ゲートウェイには、ゲートウェイが制御「スイッチ」であるか非制御のかどうかを示すように設定できる設定可能なグレアビットがある場合があります。ただし、一般に、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）」がゲートウェイによって送信されると、それはコールエージェントがコールがリリースされており、コールエージェントがそのトランクをgiveめるべきであることをコールエージェントに示します。ただし、ゲートウェイは、反対側がオンフックをウインクとして取る可能性を避けるために、実際にその時点でオンフックを送信したくない場合があります。代わりに、トランクをリリースする前に、2番目のタイマーを起動し、長期間（たとえば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トランクの発信発作時にまぶしさが検出された場合、呼び出しエージェントにリンギングのリクエストを「ナック」（エラーコード401-電話オフハック）にする必要があります。
5.1. PBX to PBX ("MS", "DT, and "BL" packages).
5.1. PBXからPBX（ "MS"、 "dt、および" bl "パッケージ）。
The following call flows involve a single Call Agent that handles both sides of the call (i.e., the inter-Call-Agent signaling is ignored). The components involved in the call are:
次のコールフローには、コールの両側を処理する単一のコールエージェントが含まれます（つまり、コール間のシグナル伝達は無視されます）。通話に関与するコンポーネントは次のとおりです。
* 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)
NTFY 3001 DS/DS1-3/6@GW-O.HATEVER.NET MGCP 1.0 X：0123456789AF O：MS/SUP（または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」パッケージ（BASIC 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.HATEVER.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:
別の選択肢は、RQNTに組み込みリクエストを使用して、この通知をもたらし、その要求をステップA3と組み合わせることでした。例 - 「MS」パッケージ：
RQNT 2001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
R: ms/sup(E(R(ms/inf, ms/rel))
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
RQNT 2001 DS/DS1-3/6@GW-O.HATEVER.NET MGCP 1.0 X：0123456789AF Q：ループR：MS/SUP、MS/INF、MS/REL 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
RQNT 2001 DS/DS1-3/6@GW-O.HATEVER.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:
また、コールエージェントは、コールセットアップのプロセスで何らかの理由でトランクがリリースされるかどうかを告げます（リリースイベントは、たとえば何らかのシグナルエラーが原因である可能性があります）。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)
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.
注：Signal Dial -Toneのリクエストは、PBXインターフェイスの要件に応じてここにある場合とそうでない場合があります - 基本的なPBXに必要なBL/DL。DT/DLいくつかの即時開始インターフェイスの場合。
Step A4 The gateway responds with an ack:
ステップA4ゲートウェイはACKで応答します。
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)
NTFY 3002 DS/DS1-3/6@GW-O.HATEVER.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:
DTMFインターフェイス（基本的なPBXを含む）の場合、次のようになります。
NTFY 3002 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 X: 0123456789B0 O: d/5,d/5,d/5,d/1,d/2,d/3,d/4
NTFY 3002 DS/DS1-3/6@GW-O.HATEVER.NET MGCP 1.0 X：0123456789B0 O：D/5、D/5、D/5、D/1、D/2、D/3、D/3、D/3、D/34
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).
CRCX 2002 DS/DS1-3/6@GW-O.HATEVER.NET MGCP 1.0 C：A7453949499 L：A：PCMU、S：OFF、E：ON M：RECVONLY X：0123456789B1 R：MS/REL（またはDT/REL）relまたはbl/hu）。
Step B2 The Gateway acks with a connection ID and provides the SDP information:
ステップB2接続IDを備えたゲートウェイAcksと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
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 0
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request:
ステップB3コールエージェントは、接続要求の一部としてこのSDP情報を終了ゲートウェイ（GW-T）に渡します。
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 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
Note that the call setup on the terminating trunk can be done with this CRCX, although in this call flow - it is shown later (step C1).
このCRCXでは、終端トランクのコールセットアップは実行できることに注意してください。ただし、このコールフローでは、後で表示されます（ステップC1）。
Step B4 The terminating gateway, responds with an ack and its SDP information:
ステップB4終了ゲートウェイは、ACKとそのSDP情報で応答します。
200 4001 OK I: 34738A
200 4001 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 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 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コールエージェントは、接続モードを使用した変更の修正要求をOrigination Gatewayに送信し、終了ゲートウェイから選択したプロファイルを含む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
MDCX 2003 DS/DS1-3/6@GW-O.HATEVER.NET MGCP 1.0 C：A7453949499 I：34738A M：Recvonly V = 0 O = -A7453949499 0 IN IP4 47.123.34.33 S = -C = -C IN IP4 47.123。34.33 T = 0 0 M =オーディオ3456 RTP/AVP 0
Step B6 The Gateway Acks the modify connection request
ステップb6ゲートウェイアクセス接続要求を変更します
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コールエージェントは、終端ゲートウェイにセットアップ要求を行います。MFPBXインターフェイスのセットアップリクエスト（Wink Startまたは即時開始）は次のとおりです。
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 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 * wink-> pbx（wink -startトランクの場合;即時開始のためにシーケンスのこの部分は含まれません）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
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.HATEVER.NET MGCP 1.0 X：45375841 Q：LOOP 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.
この場合、リングバックはゲートウェイから来て、RT@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:
ステップC2ゲートウェイはACKで応答します。
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.
ステップC3基本的なPBXを除いて、桁が完了した場合、基本的なPBX、ケース（数字が高くなっていない場合）が送信された場合、ゲートウェイは操作が完了したことを示すことで事実に通知します。
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)
NTFY 1002 DS/DS1-5/3@GW-T.HATEVER.NET MGCP 1.0 X：45375841 O：MS/ANS（またはDT/ANSまたはBL/HD）
Step C6 The Call Agent acks
ステップC6コールエージェントAcks
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
ステップC8ゲートウェイACKSリクエスト
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
ステップC10ゲートウェイACKSリクエスト
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).
ここには2つのケースが含まれています。1つはオリジネーションエンドがリリースを開始し（セクション5.1.2.1）、もう1つは終了終了がリリースを開始する（セクション5.1.2.2）。
The following call flow shows an example where the origination end initiates the release for the "MS" package (similar for "DT" Package).
次のコールフローは、Origination Endが「MS」パッケージのリリースを開始する例を示しています（「DT」パッケージと同様）。
--------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|-------------------------------------------------------------------- |
| A1 | NTFY[O: ms/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: ms/rel, R: ms/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: ms/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: ms/rlc, R: ms/sup] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: ms/sup]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
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コールエージェントが通知をアクセスします
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)
RQNT 4004 DS/DS1-5/3@GW-T.HATEVER.NET MGCP 1.0 X：45375843 S：MS/REL（またはDT/REL）R：MS/RLC（または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
RQNT 4004 DS/DS1-5/3@GW-T.HATEVER.NET MGCP 1.0 X：45375843 S：BL/DL R：BL/HU
Step A4 The Gateways acks the request
ステップa4ゲートウェイはリクエストをアクセスします
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もう一方の端は、オンフックに移動することでコールを解放し、通知がコールエージェントに送信され、リリースが完了したことを示します。
NTFY 1004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0 X: 45375843 O: ms/rlc (or dt/rlc)
NTFY 1004 DS/DS1-5/3@GW-T.HATEVER.NET MGCP 1.0 X：45375843 O：MS/RLC（または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.-hatever.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)
dlcx 4005 ds/ds1-5/3@gw-o.-hatever.net mgcp x：45375844 i：34738a s：ms/rlc（またはdt/rlc）r：ms/sup（または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.HATEVER.NET MGCP 1.0 X：45375844 I：34738A R：BL/HD
Step A8 The Gateway Acks and provides performance information.
ステップA8ゲートウェイACKSとパフォーマンス情報を提供します。
250 4005 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
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)
DLCX 2004 DS/DS1-5/3@GW-T.HATEVER.NET MGCP 1.0 X：0123456789B3 I：23474FE R：MS/SUP（またはDT/SUPまたは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を除くすべての呼び出しを終了する終了端の例を示します（ "MS"パッケージ - "dt"パッケージも似ています）。
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | <- NTFY[O: ms/sus] |
| A2 | Ack -> |
| A3 | <- RQNT [S: ms/sus, R: ms/rel ] |
| A4 | Ack -> |
| A5 | RQNT [R: ms/res] -> |
| A6 | <- Ack |
| A7 | NTFY [O: ms/rel] -> |
| A8 | <- Ack |
| A9 | DLCX [S: ms/rel, R: ms/rlc] -> |
| A10 | <- Ack [perf info] |
| A11 | <- Notify [O: ms/rlc] |
| A12 | Ack -> |
| A13 | <- DLCX [S: ms/rlc, R: ms/sup ] |
| A14 | Ack [perf info] -> |
---------------------------------------------------------------------
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オンフックは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.
コールエージェントは、この時点でタイマーを開始します（通常は10秒）。オリジネーションサイドが解放される前にGW-Tに接続されたPBXからオフハックが受信された場合、コールは継続されます（これは、基本的なPBXインターフェイスの場合、「RE」イベントまたは「HD」として表示されます）。オリジネーション側がオンフックになったり、タイマーが期限切れになった場合、コールが取り壊されます。
Note that for Basic PBX (the "BL" package), steps A3 - A6 are missing (these steps do not exist for basic PBX).
基本的なPBX（「BL」パッケージ）の場合、ステップA3 -A6が欠落していることに注意してください（これらの手順は基本的なPBXには存在しません）。
Step A3 A "sus" signal is sent to the originating side resulting in a on-hook being sent to the originating PBX.
ステップa3「SUS」信号が発信された側に送信され、オンフックが発信されるPBXに送信されます。
Step A4 GW-o acks the request.
ステップA4 GW-O Acksリクエスト。
Step A5 The Call Agent sends a request to see off-hook or resume ("res") events.
ステップ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.
ステップA6 GW-T Acksリクエスト。
Step A7 An on-hook is received from the originating PBX resulting in a notify from GW-o with event "rel" ("hu" for Basic PBX interface).
ステップA7オンフックは、発信されたPBXから受信され、イベント「Rel」（基本的なPBXインターフェイスの「Hu」）とのGW-Oからの通知が得られます。
Step A8 The Call Agent "acks"
ステップA8コールエージェント「Acks」
Step A9 A delete connection is sent to the terminating gateway with signal "rel" which results in on-hook being sent to the terminating PBX (except for basic PBX - where there is no such signal)
ステップa9削除接続は、シグナル「rel」を使用して終端ゲートウェイに送信されます。これにより、オンフックが終端pbxに送信されます（基本PBXを除く - そのような信号がない場合）
Step A10 GW-t acks the DLCX and provides performance information
ステップA10 GW-T ACKS DLCXとパフォーマンス情報を提供する
Steps A11 and A12 do not exist for the basic PBX case.
基本的なPBXケースでは、手順A11とA12は存在しません。
Step A11 GW-t returns an "rlc" event
ステップA11 GW-Tは「RLC」イベントを返します
Step A12 The Call Agent "acks" the notify
ステップa12コールエージェント「acks」に通知
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
ntfy 3001 aaln/0@gw-o.hatever.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.
エンドポイントがFXOグラウンドスタートを実行している場合、コールはPBX（R：DO/REL）からの切断監督の検出も要求し、リンギングに応じてオフハック（S：DO/HD）を送信する必要があります。
Step B2 The Gateway acks with a connection ID and provides the SDP information.
ステップB2接続IDを備えたゲートウェイAcksとSDP情報を提供します。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
ステップB3コールエージェントは、接続要求の一部としてこのSDP情報を終了ゲートウェイ（GW-T）に渡します。
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コールエージェントは、接続モードを使用した変更の修正要求をOrigination Gatewayに送信し、終了ゲートウェイから選択したプロファイルを含むSDP情報を含めます。
Step B6 The Gateway Acks the modify connection request
ステップb6ゲートウェイアクセス接続要求を変更します
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 * tip-ground <-pbx（ループスタートの場合、この手順は適用されません） * pbxに送信
Step C2 The gateway responds with an ack:
ステップC2ゲートウェイはACKで応答します。
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)
ntfy 1001 aaln/0@gw-t.hatever.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)
エンドポイントがFXOグラウンドスタートを実行している場合、コールはPBXからの切断監督の検出も要求します（R：DO/REL）
Step C6 The Gateway acks the request
ステップC6ゲートウェイACKSリクエスト
Step C7 If the endpoint is running FXO ground-start, the Call Agent sends a notification request to be told when the trunk to be released (R: do/rel). This step and step C8 are not needed if the endpoint is running FXO loop-start.
ステップC7エンドポイントがFXOグラウンドスタートを実行している場合、コールエージェントは、トランクがリリースされるときに通知される通知リクエストを送信します（R：DO/REL）。エンドポイントがFXOループスタートを実行している場合、このステップとステップC8は必要ありません。
Step C8 The gateway acks the request and the call is now setup.
ステップC8ゲートウェイACKSリクエストと通話がセットアップされます。
If the endpoint is running FXO loop-start, the PBX cannot initiate call release. In this case, call release is always initiated by the Media Gateway by going onhook. Disconnect supervision from the PBX is provided only for FXO ground-start. However, it does not matter whether the origination end or the termination end initiates the release. The call flows for either case are the same. Therefore, only the case where the origination end initiates the release is illustrated in this section.
エンドポイントがFXOループスタートを実行している場合、PBXはコールリリースを開始できません。この場合、コールリリースは、Onhookに行くことにより、常にメディアゲートウェイによって開始されます。PBXからの切断監督は、FXOグラウンドスタートにのみ提供されます。ただし、オリジネーションの終了または終了終了がリリースを開始するかどうかは関係ありません。どちらの場合もコールの流れは同じです。したがって、このセクションには、オリジネーションエンドがリリースを開始する場合のみです。
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: do/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: do/hu, R: do/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: do/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: hu, R: rg] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: do/rg]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
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)
ntfy 3005 aaln/0@gw-o.hatever.net mgcp 1.0 x：45375842 o：do/rel（0）
Step A2 The Call Agent Acks the Notify
ステップa2コールエージェントが通知をアクセスします
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ゲートウェイはリクエストをアクセスします
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終端端での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.
ループスタートの場合は接地信号がないことに注意してください。ただし、このNTFYメッセージは、HU信号が適用されるとすぐに生成されます。
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ゲートウェイACKSとパフォーマンス情報を提供します。
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".
仮定は、最初の「Notify」の前に、Call Agentが検疫処理「Q：Loop」を使用して「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
NTFY 3001 DS/DS1-3/6@MGW45.HATEVER.NET MGCP 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)
NTFY 3002 DS/DS1-3/6@MGW45.HATEVER.NET MGCP X：0123456789B0 O：MD/INF（K0,0,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アドレスフィールドの数字が収集されると、別のNOTIFYが送信されます。
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)
NTFY 3003 DS/DS1-3/6@MGW45.HATEVER.NET MGCP X：0123456789B0 O：MD/INF（K0,5,1,2,5,5,5,4,5,6,7、S0）
Step A6 The Call Agent "acks"
ステップa6コールエージェント「acks」
Step B1 Create connection - receive only:
ステップB1接続の作成 - 受信のみ：
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ゲートウェイ「Acks」リクエストを「Acks」し、接続IDとSDP情報を提供します。
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
ステップB3コールエージェントは、接続要求の一部としてこのSDP情報を終了ゲートウェイ（GW-T）に渡します。
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コールエージェントは、接続モードを使用した変更の修正要求をOrigination Gatewayに送信し、終了ゲートウェイから選択したプロファイルを含むSDP情報を含めます。
Step B6 The Gateway Acks the modify connection request.
ステップb6ゲートウェイアクセス接続要求を変更します。
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".
仮定は、最初の「Notify」の前に、Call Agentが検疫処理「Q：Loop」を使用して「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
NTFY 3001 DS/DS1-3/6@MGW45.HATEVER.NET MGCP 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)
NTFY 3002 DS/DS1-3/6@MGW45.HATEVER.NET MGCP 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 Step A5 The Call Agent does processing on the country address field and sends a request to initiate further input (sends a continue wink):
ステップA4コールエージェントはACKで応答しますステップA5コールエージェントは国アドレスフィールドで処理し、さらに入力を開始するリクエストを送信します（続行ウィンクを送信します）：
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0 X: 0123456789B1 Q: loop R: md/inf,md/rel S: md/cwk
RQNT 2002 DS/*@MGW45.HATEVER.NET MGCP 1.0 X：0123456789B1 Q：LOOP R：MD/INF、MD/REL S：MD/CWK
Step A6 The Gateway "acks" the request.
ステップa6ゲートウェイ「Acks」リクエスト。
Step A7 Once the digits for the identification field are collected the gateway notifies the call agent:
ステップA7識別フィールドの数字が収集されると、ゲートウェイにコールエージェントに通知されます。
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)
NTFY 3003 DS/DS1-3/6@MGW45.HATEVER.NET MGCP X：0123456789B0 O：MD/INF（K0,0,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アドレスフィールドの数字が収集されると、別のNOTIFYが送信されます。
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)
NTFY 3004 DS/DS1-3/6@MGW45.HATEVER.NET MGCP X：0123456789B0 O：MD/INF（K0,5,1,2,5,5,5,4,5,6,7、S0）
Step A10 The Call Agent "acks"
ステップA10コールエージェント「Acks」
Step B1 Create connection - receive only:
ステップB1接続の作成 - 受信のみ：
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ゲートウェイ「Acks」リクエストと接続IDとSDP情報を提供する
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request.
ステップB3コールエージェントは、接続要求の一部としてこのSDP情報を終了ゲートウェイ（GW-T）に渡します。
Step B4 The terminating gateway, responds with an ack and its SDP information 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.
ステップB4終端ゲートウェイは、ACKで応答し、SDP情報ステップB5コールエージェントは、接続モードを使用してMODIFY接続要求をOrigination Gatewayに送信し、終端ゲートウェイから選択したプロファイルを持つSDP情報を含めます。
Step B6 The Gateway Acks the modify connection request
ステップb6ゲートウェイアクセス接続要求を変更します
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コールエージェントは、終了ゲートウェイにセットアップ要求を行います。MFEANAFGDインターフェイスのセットアップリクエストは次のとおりです。
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 * wink <-scn * scnに送信される発信者IDディジット * scnに送信される桁
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
NTFY 3000 DS/DS1-3/6@MGW45.HATEVER.NET MGCP 1.0 X：0123456789B0 O：MD/SWK
Step C4 The Call Agent "acks".
ステップC4コールエージェント「Acks」。
Step C5 "Notify" that out-pulsing is complete:
ステップC5は、パルスが完了していることを「通知」します。
NTFY 3001 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0 X: 0123456789B0 O: md/oc(md/sup)
NTFY 3001 DS/DS1-3/6@MGW45.HATEVER.NET MGCP 1.0 X：0123456789B0 O：MD/OC（MD/SUP）
Step C6 The Call Agent "acks".
ステップC6コールエージェント「Acks」。
Step C7 "Notify" that the acknowledgement wink has been received:
ステップC7は、承認ウィンクが受信されたことを「通知」します。
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0 X: 0123456789B0 O: md/awk
NTFY 3002 DS/DS1-3/6@MGW45.HATEVER.NET MGCP 1.0 X：0123456789B0 O：MD/AWW
Step C8 The Call Agent "acks".
ステップC8コールエージェント「Acks」。
Step C9 The acknowledge wink is passed to the originating gateway:
ステップC9確認ウィンクは、元のゲートウェイに渡されます。
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0 X: 45375842 S: md/awk R: md/rel
RQNT 2001 DS/DS1-5/3@GW-T.HATEVER.NET MGCP 1.0 X：45375842 S：MD/AWK R：MD/REL
Step C10 GW-o "acks".
ステップC10 GW-O "Acks"。
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
NTFY 3003 DS/DS1-3/6@MGW45.HATEVER.NET MGCP X：0123456789B0 O：MD/ANS
Step C12 The Call Agent "acks".
ステップC12コールエージェント「Acks」。
Step C13 The Call Agent now sends a request to make the connection full duplex and indicates that the other end has answered the phone (S: ans sent)
ステップC13コールエージェントは、接続を完全にデュプレックスするリクエストを送信し、もう一方の端が電話に応答したことを示します（s：ans送信）
Step C14 The Gateway acks the request
ステップ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:
FGD EAINの場合、追加の数字文字列（国アドレスおよび/またはキャリアアクセスコードが含まれている必要があります。
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
If overlapped sending is done, only the country address and caller ID digit strings are sent out in step C1:
重複した送信が行われた場合、ステップC1で国民の住所と発信者ID桁の文字列のみが送信されます。
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
RQNT 2001 DS/DS1-5/3@GW-T.HATEVER.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))
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.HATEVER.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」）イベントまたは異常なリリース（「REL」）イベントについて通知するよう要求します。
Step C16 The gateway "acks" the request.
ステップC16ゲートウェイ「Acks」リクエスト。
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」パッケージを使用して、機能グループDオペレーターサービスシグナリングコールセットアップ（911コール）を説明しています。このテーブルは、コールフローの最初の部分の概要を示しており、詳細を説明します。この場合、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
ntfy 3001 aaln/1@gw-o.hatever.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:
ステップA4ゲートウェイはACKで応答します。
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
ntfy 3002 aaln/1@gw-o.hatever.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.
CRCX 2002 DS/DS1-3/6@GW-O.HATEVER.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接続IDを備えたゲートウェイAcksとSDP情報を提供します。
200 2002 OK I: 23474FE
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 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 and does a call setup request at the same time:
ステップB3コールエージェントは、接続要求の一部としてこのSDP情報を終了ゲートウェイ（GW-T）に渡し、同時にコールセットアップリクエストを実行します。
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 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
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
* オフホック - > scn * wink <-scn * k0,9,1,1、s2-> scn * offhook <-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
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 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 B5 The Call Agent will get a further notify when outpulsing of all of the digits is complete.
ステップB5コールエージェントは、すべての数字の補償が完了すると、さらに通知を取得します。
NTFY 3003 aaln/1@gw-o.whatever.net MGCP 1.0
ntfy 3003 aaln/1@gw-o .hatever.net mgcp 1.0
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コールエージェントは、接続モードでの変更接続要求をOrigination Gatewayに送信し、終了ゲートウェイから選択したプロファイルを含むSDP情報を含めます。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0 C: A7453949499 I: 34738A M: sendrecv
MDCX 2003 DS/DS1-3/6@GW-O.HATEVER.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 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 B8 The Gateway Acks the modify connection request
ステップb8ゲートウェイアクセス接続要求を変更します
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.
これらのパッケージのいくつかのソースは、フレミングアンドレアセン、ワイタクシウ - シスコシステム、およびドンスタンウィック - イップユニティです。彼のCASインターフェイスの専門知識に感謝しているTelcordia Technologies、Joe Clarkに感謝します。また、次の人々を含むがこれらに限定されないすべてのレビュアーに感謝します。チャールズエッケル、シスコシステムズ。Jerry Kamitses、Sonus Networks。
References
参考文献
[1] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
[1] Arango、M.、Dugan、A.、Elliott、I.、Huitema、C。and S. Pickett、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 2705、1999年10月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and 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.
[3] ベルコア、機能グループDスイッチアクセスサービスの互換性情報、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] ベルコア、インターオフィスラタスイッチングシステムジェネリック要件（LSSGR）：検証接続（25-05-0903）、TR-TSY-000531、第2号、1987年7月。
[5] Bellcore, LSSGR: Signaling for Analog Interfaces, GR-506-CORE, Issue 1, June 1996.
[5] ベルコア、LSSGR：アナログインターフェイスのシグナリング、GR-506コア、1996年6月1日、第1号。
[6] PacketCableTM PSTN Gateway Call Signaling Protocol Specification, Pkt-SP-TGCP-I01-991201
[6] PacketCableTM PSTNゲートウェイコールシグナル伝達プロトコル仕様、PKT-SP-TGCP-I01-991201
Author's Address
著者の連絡先
Bill Foster 170 West Tasman Dr San Jose, CA, 95134
ビルフォスター170ウェストタスマン博士サンノゼ、カリフォルニア州、95134
Phone: 408-527-8791 EMail: bfoster@cisco.com
電話：408-527-8791メール：bfoster@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。