Network Working Group B. Foster
Request for Comments: 3064 Cisco Systems
Category: Informational February 2001
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.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. Included are six packages. The "MS" package covers MF single stage dialing trunks. This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3]. The "DT "package covers immediate start and basic DTMF and dial-pulse trunks and the "BL" package covers the interface to a basic PBX (digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These include EAIN and EANA which is covered by the enclosed "MD" package and the Operator Service Signaling protocol which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package.
本文档包含用于R1 CAS、北美CAS、CAS PBX互连以及基本FXO支持的媒体网关通道相关信令（CAS）包的集合。包括六个包裹。“MS”包包括MF单级拨号中继线。这包括wink启动和立即启动PBX DID/DOD中继以及基本R1和功能组D（FGD）终止协议[3]。“DT”包包括即时启动、基本DTMF和拨号脉冲中继，“BL”包包括与基本PBX（数字或FXS接口）的接口。除终止协议外，还有[3]中描述的三种其他FGD协议。其中包括随附的“MD”包中包含的EAIN和EANA，以及由“MO”包处理的运营商服务信令协议。“DO”软件包提供对基本FXO互连的支持。
Conventions used in this document
本文件中使用的公约
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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 ................................................ 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.1导言
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中继，呼叫代理不应关心这是wink start中继还是立即启动中继（媒体网关不应提供wink start信号）。
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).
* 为调用代理提供一些合理的抽象级别，以便它可以在可能的情况下重用调用流（例如，当只涉及一个数字字符串时，调用代理不必区分wink start和immediate start接口）。
* 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:
嵌入式通知的使用：不依赖于嵌入式通知的使用，而是定义了具有所需特定语义的信号和事件。原因有两个：
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 immediate start中继的情况下，可以使用相同的传入呼叫设置事件，为呼叫代理提供一个通用接口，即使CAS状态机级别的语义略有不同（即，在MF wink start情况下，由于传入的癫痫发作，会反射性地提供wink start信号，而在立即启动情况下，这是不需要的）。
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.
以下描述了各种包支持的中继类型。通过MGCP范围外的供应设施，在媒体网关（MG）内完成特定中继类型的配置（例如，眨眼启动与立即启动）。呼叫代理的责任是支持特定的包（即，通常呼叫代理不必区分wink start和immediate start，因为这些差异由MG负责）。但是，呼叫代理需要知道哪些中继是传入的、传出的或双向的。
The "MS" package is used for PBX DID/DOD trunks as indicated in the following table. It is also used for incoming or outgoing MF wink start trunks (R1 and FGD Terminating protocol [6]).
“MS”包用于PBX DID/DOD中继，如下表所示。它还用于传入或传出MF wink start中继（R1和FGD终止协议[6]）。
Table 1 MF PBX Trunks
表1 MF PBX中继
--------------------------------------------------
| Trunk Type | Direction (w.r.t. the gateway) |
--------------------------------------------------
|MF, wink start |Incoming - originate from PBX |
| |(the same as FGD terminating |
| | protocol) |
|MF, wink start |Outgoing - terminate on PBX |
|MF, wink start |Bi-directional |
|MF, Immediate |Incoming (originate from PBX) |
| start | |
|MF, Immediate |Outgoing (terminate on PBX) |
| start | |
--------------------------------------------------
--------------------------------------------------
| 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 | |
--------------------------------------------------
--------------------------------------------------
| 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:
“BL”包包括DTMF和拨号脉冲（DP）基本PBX中继线，以及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| |
--------------------------------------
--------------------------------------
| 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 | |
--------------------------------------
--------------------------------------
| 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) |
--------------------------------------------------
--------------------------------------------------
| 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:
每个包定义都包括一个包名称、事件名称代码以及包中每个事件的定义。在每个包的事件/信号表中，有五列：
* 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”。或者，可能会出现以下一个或多个符号：
- "P" indicating that the event is persistent,
- “P”表示事件是持续的，
- "S" indicating that the event is an event-state that may be audited,
- “S”表示事件是可审核的事件状态，
- "C" indicating that the event/signal may be detected/applied on a connection. If "C" is associated with an event, this refers to an event that can occur on the media stream. However, "C" may also be associated with a signal (in the signal column), the signal can be requested to sent over a connection.
- “C”表示可在连接上检测/应用事件/信号。如果“C”与事件相关联，则表示媒体流上可能发生的事件。然而，“C”也可能与信号（在信号列中）相关联，可以请求通过连接发送信号。
Note that the intent of being able to audit state ("S") in an event in the following packages is to answer one of the two questions:
请注意，能够在以下程序包中的事件中审核状态（“S”）的目的是回答以下两个问题之一：
1. Has a call been initiated on this line/trunk? For example in the packages that follow, call setup initiation is indicated by either a "sup" event or an "hd" (FXS - "BL" packages) or in the case of the "DO" package below (FXO), by the "rg" event so that those events have an "S" in the event column indicating that they are auditable.
1. 此线路/中继线上是否已启动呼叫？例如，在随后的程序包中，调用设置启动由“sup”事件或“hd”（FXS-“BL”程序包）指示，或者在下面的“DO”程序包（FXO）的情况下，由“rg”事件指示，以便这些事件在事件列中有一个“S”表示它们是可审核的。
2. The other question of interest is to know whether the telephony leg of the call is in the idle state so that a new call can be initiated. This is indicate by the "rlc" (release complete) event-state for packages that have that event.
2. 另一个感兴趣的问题是知道呼叫的电话分支是否处于空闲状态，以便可以发起新呼叫。这由具有该事件的包的“rlc”（发布完成）事件状态指示。
* Signal If nothing appears in this column then this event cannot be signaled on request by the Call Agent. Otherwise, one of the following symbols is provided to identify the type of signal:
* 信号如果此列中未显示任何内容，则呼叫代理无法根据请求发出此事件的信号。否则，提供以下符号之一以识别信号类型：
- "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”开/关信号。信号开启，直到呼叫代理命令将其关闭，反之亦然。-“到”超时信号。除非信号被新信号取代或在检测到事件时终止，否则该信号将持续给定的时间。提供了默认的超时值。值为零表示超时周期是无限的。配置过程可能会更改这些默认值。-“BR”简短信号。该信号的持续时间较短。
* Additional info Provides additional information about the event/signal, e.g., the default duration of TO signals.
* 附加信息提供有关事件/信号的附加信息，例如TO信号的默认持续时间。
Unless otherwise stated, all of the events/signals are detected/applied on endpoints and audio generated by them is not forwarded on any connection the endpoint may have. Audio generated by events/signals that are detected/applied on a connection will however be forwarded on the associated connection irrespective of the connection mode.
除非另有说明，否则在端点上检测/应用所有事件/信号，并且由它们生成的音频不会在端点可能具有的任何连接上转发。然而，由在连接上检测/应用的事件/信号生成的音频将在相关连接上转发，而与连接模式无关。
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 | |
---------------------------------------------------------------------
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 | |
---------------------------------------------------------------------
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 |
---------------------------------------------------------------------
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 |
---------------------------------------------------------------------
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 | - | |
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
|Code|Description |Event|Signal |Additional Info |
|---------------------------------------------------------------------|
|ans |Call Answer !Note | P | - | |
| oc |Operation Complete| x | - | |
| of |Operation Fail | x | - | |
|orbk|Operator Ringback | x | - | |
|rbz |Reverse make busy | P,S | - | |
|rcl |Operator Recall | - | BR | |
|rel |Release Call | P | BR | |
|res |Resume Call | - | BR | |
|rlc |Release complete | P,S | BR | |
|sup |Call Setup | - | TO | |
|sus |Suspend Call | - | BR | |
|swk |Start Wink | x | - | |
---------------------------------------------------------------------
!Note: There is no indication that the operator answered the call.
The "ans" event is an indication that off-hook was received
from the far end which simply indicates that the destination
address was received properly and the calling number is in the
process of being outpulsed.
The following provides a list of the event and signal descriptions.
以下列出了事件和信号说明。
The event/signal name appears in parenthesis followed by the corresponding Event + Signal attribute code plus a list of the packages in which the event/signal occurs.
事件/信号名称显示在括号中，其后是相应的事件+信号属性代码以及事件/信号发生的包列表。
Call answer (ans; P + BR; DT,MD,MS,MO): Off-hook signal normally indicates that the call has been answered and that cut-through has been established. The exception is the "MO" package where it simply indicates that off-hook was received and the calling number is in the process of being sent (i.e., there is no event available to indicate that the operator answered the call for operator services signaling).
呼叫应答（ans；P+BR；DT、MD、MS、MO）：摘机信号通常表示呼叫已应答且已建立直通。例外情况是“MO”包，其中它仅表示已收到摘机，且呼叫号码正在发送过程中（即，没有任何事件可用于指示运营商响应运营商服务信令呼叫）。
Acknowledgement Wink (awk; P + BR; MD): This event is only applicable to the "md" package. It provides an indication that all digits have been received correctly. In an outgoing trunk, the event is requested and when received indicates that the connecting switch
确认闪烁（awk；P+BR；MD）：此事件仅适用于“MD”包。它指示所有数字都已正确接收。在传出中继中，请求该事件，当接收到该事件时，表示连接交换机
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.
收到所有的地址信息。在始发中继上，发送该信号以通知另一端已接收到所有寻址信息。例如，如果呼叫代理正在提供一个转接应用程序，其中传入和传出中继都是EANA中继，那么在从终止中继接收到确认wink后，它将被传递到发端，以便发端知道寻址已传递到目的地交换机。
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；-+至；BL、DT、MD、MS）：参考ITU E.180。音调的定义由国家特征定义，并可通过规定确定。GR-506-CORE-LSSGR，信令，第17.2.6节中定义了车站忙。作为频率为480和620赫兹的两个交流音调的组合，每个音调的电平为-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.
来电显示（ci（时间、号码、名称）；x+-；DO）：见TR-NWT-001188、GR-30-CORE和TR-NWT-000031。这三个字段中的每一个都是可选的，但始终会包含每个逗号。
The time parameter is coded as "MM/DD/HH/MM", where MM is a two-digit value for Month between 01 and 12, DD is a two-digit value for Day between 1 and 31, and Hour and Minute are two-digit values coded according to military local time, e.g., 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m.
时间参数编码为“MM/DD/HH/MM”，其中MM是01和12之间月份的两位数值，DD是1和31之间日期的两位数值，小时和分钟是根据军事当地时间编码的两位数值，例如，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.
number参数编码为十进制数字的ASCII字符串，用于标识主叫线号码。如果字符串被引用，则允许使用空格，但它们将被忽略。
The name parameter is coded as a string of ASCII characters that identify the calling line name. White spaces are permitted if the string is quoted.
name参数编码为ASCII字符字符串，用于标识主叫线路名称。如果字符串被引用，则允许使用空格。
A "P" in the number or name field is used to indicate a private number or name, and an "O" is used to indicate an unavailable number or name. The following example illustrates the use of the caller-id event:
数字或名称字段中的“P”用于表示私人数字或名称，“O”用于表示不可用的数字或名称。以下示例说明了调用方id事件的使用：
O: ci(10/14/17/26, "555 1212", somename)
O: ci(10/14/17/26, "555 1212", somename)
Continue Wink (cwk ; - + BR; MD): This signal is only applicable to the "md" package. It provides an indication that digits sent have been accepted, and further digits must be sent in order to process the call. For example, when using FGD EAIN signaling, this would correspond to sending a wink after the country access code had been received to indicate readiness to receive identification and address fields.
继续闪烁（cwk；-+BR；MD）：此信号仅适用于“MD”包。它指示发送的数字已被接受，并且必须发送更多的数字才能处理呼叫。例如，当使用FGD EAIN信令时，这将对应于在接收到国家接入码后发送眨眼，以指示准备接收标识和地址字段。
Dial-tone (dl ; - + TO; BL,DT): Refer to ITU E.180. The definition of the tone is defined by the national characteristics and may be established via provisioning. In GR-506-CORE - LSSGR, SIGNALING, Section 17.2.1, sial Tone is defined as a combination of two continuous AC tones with frequencies of 350 and 440 Hertz and levels of -13dBm each to give a combined level of -10 dBm. It is considered an error to try and play dial-tone on a phone that is on hook and an error should consequently be returned when such attempts are made (error code 402 - phone on hook).
拨号音（dl；-+至；BL，DT）：参考ITU E.180。音调的定义由国家特征定义，并可通过规定确定。在GR-506-CORE-LSSGR，信令，第17.2.1节中，sial音调定义为两个频率为350和440赫兹且电平为-13dBm的连续交流音调的组合，以给出-10dBm的组合电平。尝试在挂机的电话上播放拨号音被认为是错误的，因此在进行此类尝试时应返回错误（错误代码402-挂机电话）。
Information Digits (inf(<inf-digits>); x + TO; MS,MD): On an outgoing call ("md" package only) it is used as a signal to out-pulse the address information when doing overlapped sending.
信息数字（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''的所有数字。在单个“inf”事件中，可以传递以ST位之一结尾的多个数字序列。（注意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'''|
--------------------------
-------------------------
| 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:
Operation Complete（oc；x+-；all）：当要求网关在端点上应用一个或多个类型的信号时，会生成Operation Complete事件，并且这些信号中的一个或多个已完成，而不会因检测到请求的或持久性事件（如设置）而停止。完工报告可将到达现场时间结束的信号名称作为参数，如：
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”信号（输出脉冲-a至事件）时，操作完成事件将指示输出脉冲何时完成。
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:
操作失败（of；x+-；all）：通常，当要求端点将一个或多个类型的信号应用于端点上，并且其中一个或多个信号在超时之前失败时，可能会生成操作失败事件。完成报告可将失败信号的名称作为参数，如：
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).
操作员回叫（orbk；x+-；MO）：导致此事件的MF CAS信令说明见TR-NPL-000258[3]附录。简言之，它通常是一个眨眼信号，之后可能会或可能不会出现中频音。当运营商服务请求通知呼叫方（“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”信号用于为地面启动中继线提供tip地面释放。在环路启动中继的情况下，请求播放此信号无效。
The Media Gateway generates a "release call" event whenever a call is released as a result of an on-hook event from an originating end of a call (normal release) or due to abnormal event that resulted in releasing the call. The event may be parameterized with one of the following cause codes indicating the reason for the release:
无论何时由于呼叫的发起端的挂机事件（正常释放）或导致释放呼叫的异常事件而释放呼叫，媒体网关都会生成“释放呼叫”事件。事件可通过以下原因代码之一参数化，以指示释放原因：
Table 12 Release Reason Codes
-----------------------------------------------------------------
|Cause Code |Reason |
|-----------------------------------------------------------------
| 0 |Normal release |
| 44 |Requested channel/circuit not available |
| |(glare or incoming seizure detected during call |
| | setup) |
| 111 |Protocol/signaling error, unspecified (e.g. timeout) |
-----------------------------------------------------------------
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”软件包），只要由于远端的tip地面释放事件而释放呼叫，媒体网关就会生成“释放呼叫”事件。
Resume call (res ; P + BR; DT,MD,MS,MO): This indicates that the called party resumed the call, i.e., the party went off-hook after a previous suspend ("sus") but before the originating switch released ("rel") the trunk. The "sus" and "res" events/signals are used to propagate on-hook and off-hook events without releasing the resources associated with the call. In all but the operator services case ("MO" package), these events would normally be propagated from the terminating to the originating end (i.e., requested as events from the terminating end of the call and sent to the gateway as signals to a gateway on the originating side of the call).
恢复呼叫（res；P+BR；DT，MD，MS，MO）：这表示被叫方恢复了呼叫，也就是说，被叫方在前一次挂起（“sus”）之后，但在始发交换机释放（“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.
释放完成（rlc；P，S+BR；DO，DT，MD，MO，MS）：端点和呼叫代理使用释放完成事件/信号确认呼叫已被释放，中继可用于另一个呼叫。对于FXO地面启动（“DO”包），这表示网关挂机后从PBX释放tip地面事件。
Reorder tone (ro; - + TO; BL,DT,MD,MS): Reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for reorder tone is 0.25 seconds on followed by 0.25 seconds off, repeating continuously. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.
重排序音调（ro；-+TO；BL、DT、MD、MS）：重排序音调是两个交流音调的组合，频率分别为480和620赫兹，电平分别为-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）：可听铃声是两种交流音的组合，频率分别为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”信号由多达四个参数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 |
------------------------------------
------------------------------------
| 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
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)
地址（dig1，dig2，…，dign）
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，…，dign）
The <ca> field contains the country address information and when present will be of the form:
<ca>字段包含国家/地区地址信息，当出现时，其形式如下：
ca(dig1, dig2, ..., dign)
ca（dig1，dig2，…，dign）
When present, the <addr> field contains the destination number and will be of the form
存在时，<addr>字段包含目的地编号，其形式如下
addr(dig1, dig2, ..., dign)
地址（dig1，dig2，…，dign）
where digi is an MF symbol as defined in table 11 in the case of "MS", "MO", and "MD" packages and digi is a DTMF symbol (0-9, *,#,A,B,C,D) in the case of the "DT" and "DO" packages.
其中，对于“MS”、“MO”和“MD”包，digi是表11中定义的MF符号；对于“DT”和“DO”包，digi是DTMF符号（0-9、*、#、a、B、C、D）。
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|
------------------------------------------------------------------
------------------------------------------------------------------
|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))
辅助（地址（s0,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|
------------------------------------------------------------------
------------------------------------------------------------------
|Setup | Interactions |
|------------------------------------------------------------------|
| sup(ct(nda),addr(<addrvalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| addr(<addrvalue>), id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
| |MG| <addrvalue> -> |SCN|
|------------------------------------------------------------------|
| sup(ct(nta), ca(<cavalue>), |MG| off-hook -> |SCN|
| id(<idvalue>)) |MG| <- wink |SCN|
| |MG| <cavalue> -> |SCN|
| |MG| <- wink |SCN|
| |MG| <idvalue> -> |SCN|
------------------------------------------------------------------
The last example is an overlapped sending example where the address value would be sent later using the "inf" signal.
最后一个示例是重叠发送示例，稍后将使用“inf”信号发送地址值。
An example setup:
示例设置：
sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,0,5,5,5,1,2,3,4,s0))
sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,0,5,5,5,1,2,3,4,s0))
In all of the above cases, the "ans" event is an indication of off-hook from the far end (the other end answered). However, in the case of the operator service signaling (OSS) protocol of Feature Group D - shown in the following table, off-hook from the operator is part of the protocol (a request for the calling number) so that "ans" in this case does not indicate that the operator answered (only that off-hook/request for calling number was received).
在上述所有情况下，“ans”事件表示从远端（另一端应答）脱钩。然而，在下表所示的功能组D的运营商服务信令（OSS）协议的情况下，来自运营商的摘机是协议的一部分（呼叫号码请求），因此在这种情况下，“ans”并不表示运营商应答（仅接收到摘机/呼叫号码请求）。
Table 16 SCN Sequencing during Call Setup OSS Protocol ("MO" Package)
表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|
------------------------------------------------------------------
------------------------------------------------------------------
|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.
挂起呼叫（Suspend call，P+BR；DT，MD，MS，MO）：挂起（“Suspend”）是一个挂机事件，表示被叫方挂机。
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”（挂机）、“res”（摘机）和“rcl”（闪存挂机）将用户挂机事件传递给操作员。
Start Wink (swk; x + - MD,MO):. An Call Agent can optionally request the MG to notify it when the wink start signal occurs. Note that wink start ("swk") cannot be applied by the Call Agent as a signal. The occurrence of wink-start on an incoming trunk is a reflexive action that does not require Call Agent involvement.
开始眨眼（swk；x+-MD，MO）：。呼叫代理可以选择请求MG在wink start信号出现时通知它。请注意，呼叫代理无法将wink start（“swk”）作为信号应用。在传入中继上出现wink start是一种反射动作，不需要呼叫代理参与。
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.
这方面的一个例子是“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”表示暂停，“res”表示恢复，“rel”表示释放，它们基于一端（发起者）控制呼叫的概念。如果控制端挂机，“rel”将通知呼叫代理，并导致呼叫被释放。但是，如果非控制（终止）端挂机，则会发生“sus”事件（而不是“rel”事件）。这使呼叫代理可以选择执行挂起/恢复处理。
If the Call Agent decides not to do suspend/resume processing, it can simply send "rel" and delete connection commands to the endpoints after it receives "sus" from the non-controlling (terminating) end of the call.
如果呼叫代理决定不执行挂起/恢复处理，则在从呼叫的非控制（终止）端接收到“sus”后，它可以简单地向端点发送“rel”和“delete”连接命令。
On the other hand, if it decides to do suspend/resume processing, it can start a timeout when it receives the "sus" event from the non-controlling (terminating) end of the call and continue the call if it receives a "res" (off-hook) event. It also has the option of propagating the "sus" and "res" as signals back to the ingress gateway and allow it an opportunity to release the call ("rel" event) or not. In any case the use of "sus" and "res" signals give another level of control over the "rel" signal which will not only send on-hook but also release the resources associated with the telephony leg of the call.
另一方面，如果它决定执行挂起/恢复处理，它可以在从调用的非控制（终止）端接收到“sus”事件时启动超时，并在接收到“res”（摘机）事件时继续调用。它还可以选择将“sus”和“res”作为信号传回入口网关，并允许其有机会释放呼叫（“rel”事件）或不释放呼叫。在任何情况下，“sus”和“res”信号的使用给予了对“rel”信号的另一级控制，该信号将不仅在hook上发送，而且释放与呼叫的电话分支相关的资源。
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”信号/事件通常意味着挂机，但更重要的是，它还表示呼叫的电话分支的“资源释放”。如果呼叫代理发送一个“rel”信号而不是“sus”，则它请求放弃呼叫（即，“rel”后面不能跟“res”）。
The "rel" signal does not also imply that connections should be deleted so that to completely release the call including connections would require a DLCX in addition to (or conjunction with) the signal "rel".
“rel”信号并不意味着应删除连接，以便在“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”（release）后面通常跟着“rlc”（release complete）。release complete（释放完成）信号/事件表示中继资源现在已完全释放，可用于另一个呼叫。这也是一个事件状态，可以按照该事件列中的“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”而发送的）*呼叫代理可以向呼叫的控制（发起）端发送“rel”（而不是“sus”）信号以放弃呼叫。网关将返回“rlc”“当从另一端收到摘机且所有资源都已释放时。*可以在单向传入中继上发送“rel”，以释放先前发送的块（“bl”）。
The "BL" (FXS) package is a simple line package, so does not have these events (uses "hd", "hf", and "hu" as the only hook state events).
“BL”（FXS）包是一个简单的行包，因此没有这些事件（使用“hd”、“hf”和“hu”作为唯一的钩子状态事件）。
The "DO" (FXO) package, however, does have "rel" and "rlc" because in the ground-start case there is the ability to "release" the call as result of a tip-ground release. The signal "rel" is used if the PBX releases the call first (followed by S: hu from the call Agent to complete the release). Alternatively, the Call Agent can send the S: hu to initiate the release - followed by an "rlc" event from the media gateway to Call Agent when the PBX does the tip ground release. Although the loop-start trunks would not normally have this behavior (only applies to ground-start), the media gateway should emulate the behavior in the case of loop-start in order to allow the Call Agent a common interface.
然而，“DO”（FXO）软件包有“rel”和“rlc”，因为在地面启动情况下，由于tip地面释放，可以“释放”呼叫。如果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”（suspend）事件，以指示呼叫者挂机，并且如果被叫方在呼叫代理中断呼叫之前再次挂机，“res”。呼叫代理可以向发起端发送这些相同的信号，以向呼叫方指示挂机和挂机，而无需中断呼叫。*在正常操作期间，一旦呼叫建立，来自呼叫方（发起方）的挂机将产生“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.
网关可能具有基于每个DS0的可配置眩光位，该位可设置为指示网关是控制“交换机”还是非控制“交换机”。但是，一般来说，PBX是预配置的，或者可以配置为作为非控制交换机。在这种情况下，如果他们看到一个脱钩超过允许的眨眼长度，他们将连接一个接收器，上钩，等待新呼叫的数字。同时，PBX将在另一个中继上重试其原始呼叫。
If the gateway behaves like a controlling switch, when glare is detected, the gateway will wait for up to some timeout value (default value of 4 seconds) until the incoming off-hook changes to an on-hook state at which time it will start out-pulsing in the normal manner. If the timeout occurs before the state change to on-hook occurs, the gateway will send a release event to the Call Agent (a "rel(44)" event - cause code indicating glare).
如果网关的行为类似于控制开关，则当检测到眩光时，网关将等待某个超时值（默认值为4秒），直到传入的摘机状态变为挂机状态，此时它将以正常方式开始脉冲。如果超时发生在状态更改为on hook之前，网关将向呼叫代理发送一个释放事件（“rel（44）”事件-指示眩光的原因代码）。
When "rel(44)" is sent by the gateway, that is an indication to the Call Agent that the call is in the process of being released and that the Call Agent should give up on that trunk. However, the gateway may not actually want to send the on-hook at that time in order to avoid the possibility that the other end takes the on-hook as a wink. Instead, it may start a second timer and wait some longer period of time (e.g., 16 seconds or so) before releasing the trunk. If it receives an on-hook prior the timeout, it completes the release by going on-hook. If, on the other hand, the timer expires before the other end goes on-hook, it will simply go on-hook and wait for the other end to go on-hook. In any case, once both ends have returned to the on-hook state, an "rlc" event is sent to the Call Agent.
当网关发送“rel（44）”时，这表示呼叫代理正在释放呼叫，并且呼叫代理应该放弃该中继。然而，网关当时可能并不真正想要发送挂机，以避免另一端将挂机当作眨眼。相反，它可能会启动第二个计时器，并在释放中继之前等待更长的时间（例如，16秒左右）。如果它在超时之前收到挂机，则通过挂机完成释放。另一方面，如果计时器在另一端挂机之前过期，它将直接挂机并等待另一端挂机。在任何情况下，一旦两端都返回到挂机状态，就会向呼叫代理发送一个“rlc”事件。
In order to reduce the chances of glare, the gateway should try a ringing pre-trip test prior to sending ringing on a basic ground start trunk. If glare is detected on an outgoing seizure of a basic PBX trunk, the request for ringing should be "Nacked" (error code 401 - phone off-hook) to the Call Agent.
为了减少眩光的机会，网关应在基本地面启动中继线上发送振铃之前尝试振铃预跳闸测试。如果在基本PBX中继线传出时检测到眩光，则应将振铃请求“Nacked”（错误代码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 -> |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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.whatever.net MGCP 1.0
X: 0123456789AF
O: ms/sup (or dt/sup)
In the case of the "BL" package (basic PBX) the interface looks like a simplified line interface with the standard "hd" event for off-hook:
在“BL”包（基本PBX）的情况下，该接口看起来像一个简化的线路接口，带有标准的“hd”事件，用于摘机：
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: bl/hd
NTFY 3001 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
X: 0123456789AF
O: bl/hd
Another alternative would have been to use an embedded request in the RQNT that resulted in this notify and combine that request with step A3. Example - "ms" package:
另一种选择是在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))
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.whatever.net MGCP 1.0
X: 0123456789AF
Q:loop
R: ms/sup, ms/inf, ms/rel
This would result in both notifies occurring without requiring the RQNT in step A3.
这将导致两个通知都发生，而不需要步骤A3中的RQNT。
Step A2 The Call Agent sends an Ack:
步骤A2呼叫代理发送Ack：
200 3001 OK
2003001好
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.whatever.net MGCP 1.0
X: 0123456789B0
R: ms/inf, ms/rel
The Call Agent also asks to be told if the trunk gets released for some reason ("rel" event) in the process of call setup (release event may be due to some signaling error for example). For DTMF trunks (wink-start, immediate start and Basic PBX), the request is based on a digit map so looks a bit different:
呼叫代理还要求被告知中继线在呼叫设置过程中是否因某种原因被释放（“rel”事件）（例如，释放事件可能是由于某些信令错误）。对于DTMF中继（wink start、immediate start和Basic 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)
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
D: (xxxxxxx | x.[T#])
S: dt/dl
Note: the request to signal dial-tone may or may not be here depending on PBX interface requirement - bl/dl required for Basic PBX; dt/dl for some Immediate Start interfaces.
注：根据基本PBX所需的PBX接口要求（bl/dl），此处可能会发出拨号音信号，也可能不会发出拨号音信号；一些即时启动接口的dt/dl。
Step A4 The gateway responds with an ack:
步骤A4网关以ack响应：
200 2001 OK
200 2001好的
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.whatever.net MGCP 1.0
X: 0123456789B0
O: ms/inf(k0,5,5,5,1,2,3,4,s0)
In the case of a DTMF interface (including Basic PBX), it will look like the following:
对于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.whatever.net MGCP 1.0
X: 0123456789B0
O: d/5,d/5,d/5,d/1,d/2,d/3,d/4
Step A6 The Call Agent responds with an ack:
步骤A6呼叫代理用ack响应：
200 3002 OK
2003002好
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、 net MGCP 1.0 C:A74539499L:a:PCMU，s:off，e:on M:recvonly X:0123456789B1 R:ms/rel（或dt/rel或bl/hu）。
Step B2 The Gateway acks with a connection ID and provides the SDP information:
步骤B2网关确认连接ID并提供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=-A745394990在IP4128.96.41.1中s=-c=在IP4128.96.41.1中t=0 0 m=音频3456 RTP/AVP 0
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request:
步骤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
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=-A745394990在IP4128.96.41.1中s=-c=在IP4128.96.41.1中t=0 0 m=音频3456 RTP/AVP 0
Note that the call setup on the terminating trunk can be done with this CRCX, although in this call flow - it is shown later (step C1).
请注意，终接中继上的呼叫设置可以使用此CRCX完成，尽管在该呼叫流中-稍后将显示（步骤C1）。
Step B4 The terminating gateway, responds with an ack and its SDP information:
步骤B4：终端网关用ack及其SDP信息进行响应：
200 4001 OK I: 34738A
200 4001正常I:34738A
v=0 o=- A7453949499 0 IN IP4 47.123.34.33 s=- c=IN IP4 47.123.34.33 t=0 0 m= audio 3456 RTP/AVP 0
v=0 o=-A745394990在IP447.123.34.33中s=-c=在IP447.123.34.33中t=0 0 m=音频3456 RTP/AVP 0
Step B5 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
步骤B5呼叫代理使用连接模式receive only向发起网关发送修改连接请求，并包括来自终止网关的SDP信息和所选配置文件。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: recvonly
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
v=0 o=-A745394990在IP447.123.34.33中s=-c=在IP447.123.34.33中t=0 0 m=音频3456 RTP/AVP 0
Step B6 The Gateway Acks the modify connection request
步骤B6网关确认修改连接请求
200 2003 OK
2002002003OK
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 |
---------------------------------------------------------------------
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| C1 | RQNT [S: ms/sup, R: ms/oc, ms/rel, ms/ans] ->|
| C2 | <- Ack |
| C3 | <- NTFY [O:ms/oc(ms/sup)]|
| C4 | Ack -> |
| C5 | <- NTFY [O: ms/ans] |
| C6 | Ack -> |
| C7 | <- MDCX [M:sendrecv, S: ms/ans, R: ms/rel] |
| C8 | Ack -> |
| C9 | RQNT[R: ms/sus] -> |
| C10 | <- Ack |
---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the terminating gateway The setup request for an MF PBX interface (wink start or immediate start) will be the following:
步骤C1呼叫代理向终端网关发出设置请求。MF PBX接口（闪烁启动或立即启动）的设置请求如下：
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: ms/sup(addr(ko,5,5,5,1,2,3,4,s0))
R: ms/oc, ms/rel, ms/ans
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: ms/sup(addr(ko,5,5,5,1,2,3,4,s0))
R: ms/oc, ms/rel, ms/ans
Note that the result of the "sup" signal is the following sequence on the interface to the PBX:
注意，“sup”信号的结果是PBX接口上的以下顺序：
* off-hook -> PBX * wink -> PBX (for wink-start trunks; for immediate start this part of the sequence does is not included) * Digits sent to PBX
* 摘机->PBX*wink->PBX（对于wink启动中继；对于立即启动，不包括这部分序列）*发送到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:
对于DTMF PBX接口（基本PBX除外），唯一的区别是不包括MF开始和结束分隔符（k0和s0）：
RQNT 4002 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S: dt/sup(addr(5,5,5,1,2,3,4))
R: dt/oc, dt/rel, dt/ans
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.whatever.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
2004002好的
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之外，当数字已完成发送时，网关将通过指示操作已完成来通知该事实。
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))
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呼叫代理确认通知
200 1001 OK
2001001好的
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.whatever.net MGCP 1.0
X: 45375841
O: ms/ans (or dt/ans or bl/hd)
Step C6 The Call Agent acks
步骤C6呼叫代理确认
200 1002 OK
200 1002正常
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)
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网关确认请求
200 2004 OK
2002002004OK
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)
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网关确认请求
200 4003 OK
2004003好
The call is now setup.
呼叫现在已设置好。
Two cases are included here, one where the origination end initiates the release (section 5.1.2.1) and one where the termination end initiates the release (section 5.1.2.2).
此处包括两种情况，一种是发起端开始发布（第5.1.2.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).
下面的调用流显示了发起端发起“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] |
---------------------------------------------------------------------
--------------------------------------------------------------------
| 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] |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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)
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
2003005好
Step A3 The Call Agent sends a request to release the trunk. (For all but Basic PBX.)
步骤A3呼叫代理发送释放中继的请求。（适用于除基本PBX外的所有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.whatever.net MGCP 1.0
X: 45375843
S: ms/rel (or dt/rel)
R: ms/rlc (or dt/rlc)
For the Basic PBX ("BL" package), dial-tone is played
对于基本PBX（“BL”套餐），会播放拨号音
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: bl/dl
R: bl/hu
RQNT 4004 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375843
S: bl/dl
R: bl/hu
Step A4 The Gateways acks the request
步骤A4网关确认请求
200 4004 OK
2004004好
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.whatever.net MGCP 1.0
X: 45375843
O: ms/rlc (or dt/rlc)
In the case of Basic PBX, this is:
对于基本PBX，这是：
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375843
O: bl/hu
NTFY 1004 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375843
O: bl/hu
Step A6 The Call Agent returns an Ack
步骤A6呼叫代理返回Ack
200 1004 OK
2001004好
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.whatever.net MGCP 1.0
X: 45375844
I: 34738A
S: ms/rlc (or dt/rlc)
R: ms/sup (or dt/sup)
Or in the case of Basic PBX ("BL" package):
或对于基本PBX（“BL”包）：
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
R: bl/hd
DLCX 4005 ds/ds1-5/3@gw-o.whatever.net MGCP 1.0
X: 45375844
I: 34738A
R: bl/hd
Step A8 The Gateway Acks and provides performance information.
步骤A8网关确认并提供性能信息。
250 4005 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
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.whatever.net MGCP 1.0
X: 0123456789B3
I: 23474FE
R: ms/sup (or dt/sup or bl/hd)
Step A10 The gateway acks with performance information
步骤A10网关确认性能信息
250 2004 OK
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
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以外的所有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] -> |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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] -> |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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”的notify，用于挂起。
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接口的情况下，这将显示为“res”事件或“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确认请求。
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.
注意：这取决于呼叫代理是否要执行挂起/恢复处理。如果没有，呼叫代理可以简单地将“rel”与DLCX一起发送到两端。
Step A6 GW-t acks the request.
步骤A6 GW-t确认请求。
Step A7 An on-hook is received from the originating PBX resulting in a notify from GW-o with event "rel" ("hu" for Basic PBX interface).
步骤A7：从始发PBX接收到挂机，从而导致GW-o发出带有事件“rel”（“hu”表示基本PBX接口）的通知。
Step A8 The Call Agent "acks"
步骤A8呼叫代理“确认”
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确认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呼叫代理“确认”通知
Step A13 A delete connection is sent to the originating side (with signal "rlc" except in the case of the "BL" package).
步骤A13将删除连接发送到发起侧（信号为“rlc”，但“BL”包的情况除外）。
Step A14 GW-o returns an "ack" with performance information.
步骤A14 GW-o返回带有性能信息的“确认”。
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 |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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.whatever.net MGCP 1.0
X: 0123456789AF
O: do/rg
Step A2 The Call Agent sends an Ack:
步骤A2呼叫代理发送Ack：
Step B1 The Call Agent now requests that a receive-only connection be made.
步骤B1呼叫代理现在请求建立仅接收连接。
If the endpoint is running FXO ground-start, the call would also request detection of disconnect supervision from the PBX (R: do/rel) and should send an off-hook (S: do/hd) in response to ringing.
如果端点正在运行FXO ground start（FXO接地启动），则该呼叫还将请求检测来自PBX的断开连接监控（R:do/rel），并应发送断开连接（S:do/hd）以响应振铃。
Step B2 The Gateway acks with a connection ID and provides the SDP information.
步骤B2网关确认连接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呼叫代理使用连接模式receive only向发起网关发送修改连接请求，并包括来自终止网关的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
RQNT 4002 aaln/0@gw-t.whatever.net MGCP 1.0
X: 45375841
S: do/sup(addr(5,5,5,1,2,3,4))
R: do/oc
Note that the result of the "sup" signal is the following sequence on the interface to the PBX:
注意，“sup”信号的结果是PBX接口上的以下顺序：
* off-hook -> PBX * tip-ground <- PBX (for loop-start this step does not apply) * digits sent to PBX
* 摘机->PBX*尖端接地<-PBX（对于环路启动，此步骤不适用）*发送到PBX的数字
Step C2 The gateway responds with an ack:
步骤C2：网关以ack响应：
200 4002 OK
2004002好的
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.whatever.net MGCP 1.0
X: 45375841
O: do/oc(do/sup)
Step C4 The Call Agent acks the notify
步骤C4呼叫代理确认通知
200 1001 OK
2001001好的
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 ground start，则调用还将请求检测PBX的断开监控（R:do/rel）
Step C6 The Gateway acks the request
步骤C6网关确认请求
Step C7 If the endpoint is running FXO ground-start, the Call Agent sends a notification request to be told when the trunk to be released (R: do/rel). This step and step C8 are not needed if the endpoint is running FXO loop-start.
步骤C7如果端点正在运行FXO地面启动，则呼叫代理发送一个通知请求，告知何时释放中继（R:do/rel）。如果端点正在运行FXO loop start，则不需要此步骤和步骤C8。
Step C8 The gateway acks the request and the call is now setup.
步骤C8网关确认请求，呼叫现在已设置。
If the endpoint is running FXO loop-start, the PBX cannot initiate call release. In this case, call release is always initiated by the Media Gateway by going onhook. Disconnect supervision from the PBX is provided only for FXO ground-start. However, it does not matter whether the origination end or the termination end initiates the release. The call flows for either case are the same. Therefore, only the case where the origination end initiates the release is illustrated in this section.
如果端点正在运行FXO loop start，则PBX无法启动呼叫释放。在这种情况下，呼叫释放总是由媒体网关通过挂接启动。从PBX断开监控仅用于FXO接地起动。但是，发起端还是终止端发起发布并不重要。两种情况下的调用流都是相同的。因此，本节仅说明发起端发起发布的情况。
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| A1 | NTFY[O: do/rel] -> |
| A2 | <- Ack |
| A3 | RQNT [S: do/hu, R: do/rlc] -> |
| A4 | <- Ack |
| A5 | <- NTFY [O: do/rlc] |
| A6 | Ack -> |
| A7 | <- DLCX [S: hu, R: rg] |
| A8 | Ack [perf info] -> |
| A9 | DLCX [R: do/rg]-> |
| A10 | <- Ack [perf info] |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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.whatever.net MGCP 1.0
X: 45375842
O: do/rel(0)
Step A2 The Call Agent Acks the Notify
步骤A2呼叫代理确认通知
200 3005 OK
2003005好
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通过释放tip接地释放呼叫，然后向呼叫代理发送通知以指示释放完成。
Note that there is no ground signal in case of loop-start. However, this NTFY message is still generated as soon as hu signal is applied.
注意，环路启动时没有接地信号。但是，只要应用hu信号，仍会生成此NTFY消息。
Step A6 The Call Agent returns an Ack
步骤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网关确认并提供性能信息。
Step A9 The Call Agent sends a DLCX to the terminating gateway.
步骤A9呼叫代理向终端网关发送DLCX。
Step A10 The gateway acks with performance information
步骤A10网关确认性能信息
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 -> |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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”之前，呼叫代理已经发送了一个请求，使用隔离处理“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.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
Step A2 The Call Agent sends an Ack.
步骤A2呼叫代理发送Ack。
Step A3 Once the digits for the identification field are collected the gateway notifies the call agent:
步骤A3收集到标识字段的数字后，网关通知呼叫代理：
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
Step A4 The Call Agent responds with an ack.
步骤A4呼叫代理用ack响应。
Step A5 When the digits are collected for the address field, another notify is sent:
步骤A5收集地址字段的数字后，发送另一个通知：
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
NTFY 3003 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
Step A6 The Call Agent "acks"
步骤A6呼叫代理“确认”
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
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网关“确认”请求并提供连接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呼叫代理使用连接模式receive only向发起网关发送修改连接请求，并包括来自终止网关的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 -> |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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”之前，呼叫代理已经发送了一个请求，使用隔离处理“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.whatever.net MGCP 1.0
X: 0123456789B0
O: md/sup
Step A2 The Call Agent sends an Ack
步骤A2呼叫代理发送Ack
Step A3 The initial digit string contains the country address field:
步骤A3初始数字字符串包含国家/地区地址字段：
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,1,3,8,9,9,0,0,1,9,s0)
NTFY 3002 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,1,3,8,9,9,0,0,1,9,s0)
Step A4 The Call Agent responds with an ack
步骤A4呼叫代理用ack响应
Step A5 The Call Agent does processing on the country address field and sends a request to initiate further input (sends a continue wink):
步骤A5呼叫代理对国家/地区地址字段进行处理，并发送启动进一步输入的请求（发送继续闪烁）：
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/inf,md/rel
S: md/cwk
RQNT 2002 ds/*@mgw45.whatever.net MGCP 1.0
X: 0123456789B1
Q: loop
R: md/inf,md/rel
S: md/cwk
Step A6 The Gateway "acks" the request.
步骤A6网关“确认”请求。
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.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,0,0,4,0,8,5,5,5,1,2,3,4,s0)
Step A8 The Call Agent responds with an ack
步骤A8呼叫代理以ack响应
Step A9 When the digits are collected for the address field, another notify is sent:
步骤A9收集地址字段的数字后，将发送另一个通知：
NTFY 3004 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
NTFY 3004 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/inf(k0,5,1,2,5,5,5,4,5,6,7,s0)
Step A10 The Call Agent "acks"
步骤A10呼叫代理“确认”
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
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网关“确认”请求并提供连接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呼叫代理使用连接模式receive only向发起网关发送修改连接请求，并包括来自终止网关的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 |
---------------------------------------------------------------------
---------------------------------------------------------------------
| Steps | GW-o | CA | GW-t |
|---------------------------------------------------------------------|
| C1 | RQNT [S:sup, R:md/swk,md/oc, md/rel,md/awk, md/ans] ->|
| C2 | <- Ack |
| C3 | <- NTFY [O:md/swk)] |
| C4 | Ack -> |
| C5 | <- NTFY [O:md/oc(md/sup)]|
| C6 | Ack -> |
| C7 | <- NTFY [O:md/awk)] |
| C8 | Ack -> |
| C9 | <- RQNT[S:md/awk] |
| C10 | Ack -> |
| C11 | <- NTFY [O: md/ans] |
| C12 | Ack -> |
| C13 | <- MDCX [M:sendrecv, S: md/ans, R: md/rel] |
| C14 | Ack -> |
| C15 | RQNT [R: md/sus, md/rel] -> |
| C16 | <- Ack |
---------------------------------------------------------------------
Step C1 The Call Agent does a setup request to the terminating gateway The setup request for an MF EANA FGD interface will be the following:
步骤C1呼叫代理向终端网关发出设置请求。MF EANA FGD接口的设置请求如下：
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:
md/sup(ct(nda),addr(k0,5,5,5,5,2,2,1,2,3,4,s0),id(k0,0,5,5,5,1,
2,3,4,s2))
R: md/swk,md/oc,md/rel,md/awk,md/ans
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的来电显示数字*发送到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信号已经开始（传入的wink启动已经发生），即：
NTFY 3000 ds/ds1-3/6@mgw45.whatever.net MGCP 1.0
X: 0123456789B0
O: md/swk
NTFY 3000 ds/ds1-3/6@mgw45.whatever.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.whatever.net MGCP 1.0
X: 0123456789B0
O: md/oc(md/sup)
Step C6 The Call Agent "acks".
步骤C6呼叫代理“确认”。
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.whatever.net MGCP 1.0
X: 0123456789B0
O: md/awk
Step C8 The Call Agent "acks".
步骤C8呼叫代理“acks”。
Step C9 The acknowledge wink is passed to the originating gateway:
步骤C9：确认闪烁被传递到发起网关：
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
S: md/awk
R: md/rel
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375842
S: md/awk
R: md/rel
Step C10 GW-o "acks".
步骤C10 GW-o“确认”。
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.whatever.net MGCP 1.0
X: 0123456789B0
O: md/ans
Step C12 The Call Agent "acks".
步骤C12呼叫代理“确认”。
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 sent）
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的情况下，必须包括额外的数字字符串（国家地址和/或载波接入码），以便在不存在重叠发送的情况下，步骤C1如下所示：
RQNT 2001 ds/ds1-5/3@gw-t.whatever.net MGCP 1.0
X: 45375841
Q: loop
S:md/sup(ct(nta),ca(k0,1,3,8,9,9,0,0,1,0,s0),id(k0,
0,5,5,5,1,2,3,4,s0),addr(ko,0,1,1,3,8,1,2,3,4,7,6,5,s0))
R: md/swk,md/oc,md/rel,md/awk,md/ans
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.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))
R: md/swk,md/oc,md/rel,md/ans
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.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)
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网关“确认”请求。
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 -> |
---------------------------------------------------------------------
---------------------------------------------------------------------
| 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.whatever.net MGCP 1.0
X: 0123456789AF
O: l/hd
Step A2 The Call Agent sends an Ack:
步骤A2呼叫代理发送Ack：
200 3001 OK
2003001好
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
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好的
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.whatever.net MGCP 1.0
X: 0123456789B0
O: d/9,d/1,d/1
Step A6 The Call Agent responds with an ack:
步骤A6呼叫代理用ack响应：
200 3002 OK
2003002好
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、 net MGCP 1.0 C:A745394999 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并提供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=-A745394990在IP4128.96.41.1中s=-c=在IP4128.96.41.1中t=0 0 m=音频3456 RTP/AVP 0
Step B3 The Call Agent passes this SDP information to the terminating gateway (GW-t) as part of the connection request and does a call setup request at the same time:
步骤B3呼叫代理将此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))
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=-A745394990在IP4128.96.41.1中s=-c=在IP4128.96.41.1中t=0 0 m=音频3456 RTP/AVP 0
As a result of this request, the following signaling interactions will occur between GW-t and the Switched Circuit Network (SCN - in this case, the E911 tandem):
由于该请求，GW-t和交换电路网络（SCN-在本例中为E911串联）之间将发生以下信令交互：
* Off-hook -> SCN * Wink <- SCN * k0,9,1,1,s2 -> SCN * Off-hook <- SCN * k0,0,8,3,4,5,6,7,8,s0
* 摘机->SCN*Wink<-SCN*k0,9,1,1，s2->SCN*摘机--SCN*k0,0,8,3,4,5,6,7,8，s0
Note that off-hook from the SCN is part of the protocol (a request for the caller ID) and does not provide an indication of whether the operator answered or not.
请注意，来自SCN的摘机是协议的一部分（呼叫者ID请求），不提供操作员是否应答的指示。
Step B4 The terminating gateway, responds with an ack and its SDP information:
步骤B4：终端网关用ack及其SDP信息进行响应：
200 4001 OK I: 34738A
200 4001正常I:34738A
v=0 o=- A7453949499 0 IN IP4 47.123.34.33 s=- c=IN IP4 47.123.34.33 t=0 0 m= audio 3456 RTP/AVP 0
v=0 o=-A745394990在IP447.123.34.33中s=-c=在IP447.123.34.33中t=0 0 m=音频3456 RTP/AVP 0
Step B5 The Call Agent will get a further notify when outpulsing of all of the digits is complete.
步骤B5当所有数字的输出完成时，呼叫代理将获得进一步的通知。
NTFY 3003 aaln/1@gw-o.whatever.net MGCP 1.0
NTFY 3003 aaln/1@gw-o、 net MGCP 1.0
X: 45375840 O: oc(sup)
X:45375840 O:oc（辅助）
Step B6 The Call Agent returns an "ack"
步骤B6呼叫代理返回“ack”
200 3003 OK
2003003好
Step B7 Call Agent sends a modify connection request with connection mode receive-only to the origination gateway and includes the SDP information with the selected profile from the termination gateway.
步骤B7呼叫代理向发起网关发送仅接收连接模式的修改连接请求，并包括来自终止网关的具有所选简档的SDP信息。
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: sendrecv
MDCX 2003 ds/ds1-3/6@gw-o.whatever.net MGCP 1.0
C: A7453949499
I: 34738A
M: sendrecv
v=0 o=- A7453949499 0 IN IP4 47.123.34.33 s=- c=IN IP4 47.123.34.33 t=0 0 m= audio 3456 RTP/AVP 0
v=0 o=-A745394990在IP447.123.34.33中s=-c=在IP447.123.34.33中t=0 0 m=音频3456 RTP/AVP 0
Step B8 The Gateway Acks the modify connection request
步骤B8网关确认修改连接请求
200 2003 OK
2002002003OK
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.
其中一些软件包的来源是弗莱明·安德烈森（Flemming Andreasen）、伟德兆思科系统（Wai-Tak Siu-Cisco Systems）和唐·斯坦维克（Don Stanwyck-IP Unity）。特别感谢Joe Clark，Telcordia Technologies提供的CAS接口专业知识。还要感谢所有评审人员的所有评论，包括但不限于以下人员：Charles Eckel，Cisco Systems；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.和S.Pickett，“媒体网关控制协议（MGCP）1.0版”，RFC 27052999年10月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] Bellcore, Compatibility Information for Feature Group D Switched Access Service, TR-NPL-000258, Issue 1, October 1985.
[3] Bellcore，《功能组D交换接入服务的兼容性信息》，TR-NPL-000258，1985年10月第1期。
[4] Bellcore, Interoffice LATA Switching Systems Generic Requirements (LSSGR): Verification Connections (25-05-0903), TR-TSY-000531, Issue 2, July 1987.
[4] Bellcore，办公室间LATA交换系统通用要求（LSSGR）：验证连接（25-05-0903），TR-TSY-000531，第2期，1987年7月。
[5] Bellcore, LSSGR: Signaling for Analog Interfaces, GR-506-CORE, Issue 1, June 1996.
[5] Bellcore，LSSGR：模拟接口信令，GR-506-CORE，第1期，1996年6月。
[6] PacketCableTM PSTN Gateway Call Signaling Protocol Specification, Pkt-SP-TGCP-I01-991201
[6] PacketCableTM PSTN网关呼叫信令协议规范，Pkt-SP-TGCP-I01-991201
Author's Address
作者地址
Bill Foster 170 West Tasman Dr San Jose, CA, 95134
比尔·福斯特170西塔斯曼博士，加利福尼亚州圣何塞，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.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。