Network Working Group M. Arango
Request for Comments: 2705 RSL COM
Category: Informational A. Dugan
I. Elliott
Level3 Communications
C. Huitema
Telcordia
S. Pickett
Vertical Networks
October 1999
Network Working Group M. Arango
Request for Comments: 2705 RSL COM
Category: Informational A. Dugan
I. Elliott
Level3 Communications
C. Huitema
Telcordia
S. Pickett
Vertical Networks
October 1999
Media Gateway Control Protocol (MGCP) Version 1.0
媒体网关控制协议（MGCP）1.0版
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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 ITF-T SG16 who are currently working on a potential successor to this protocol.
本文件发布供社区参考。它描述了目前正在许多产品中部署的协议。实施者应了解IETF Megaco工作组和ITF-T SG16的发展情况，他们目前正在研究该协议的潜在后续协议。
Abstract
摘要
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
本文档描述了用于从外部呼叫控制元件控制IP语音（VoIP）网关的应用程序编程接口和相应的协议（MGCP）。MGCP采用呼叫控制体系结构，其中呼叫控制“智能”位于网关之外，并由外部呼叫控制元素处理。
The document is structured in 6 main sections:
本文件分为6个主要部分：
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* 引言介绍了基本假设以及与其他协议（如H.323、RTSP、SAP或SIP）的关系。
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP: Notifications Request, Notification, Create Connection, Modify Connection, Delete Connection, AuditEndpoint, AuditConnection and RestartInProgress.
* 接口部分介绍了MGCP的概念概述，介绍了命名约定、会话描述协议SDP的使用以及组成MGCP的过程：通知请求、通知、创建连接、修改连接、删除连接、AuditEndpoint、AuditConnection和重新启动进程。
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* 协议描述部分介绍了基于简单文本格式的MGCP编码以及UDP上的传输过程。
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* 安全部分介绍了MGCP的安全要求及其对IP安全服务（IPSEC）的使用。
* The event packages section provides an initial definition of packages and event names.
* “事件包”部分提供包和事件名称的初始定义。
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0.
* 结合SGCP 1.1和IPDC创建MGCP 1.0时所做更改的说明。
Table of Contents
目录
1. Introduction .............................................. 5
1.1. Relation with the H.323 standards .................... 7
1.2. Relation with the IETF standards ..................... 8
1.3. Definitions .......................................... 9
2. Media Gateway Control Interface ........................... 9
2.1. Model and naming conventions. ........................ 10
2.1.1. Types of endpoints .............................. 10
2.1.1.1. Digital channel (DS0) ...................... 11
2.1.1.2. Analog line ................................ 11
2.1.1.3. Annoucement server access point ............ 12
2.1.1.4. Interactive Voice Response access point .... 12
2.1.1.5. Conference bridge access point ............. 13
2.1.1.6. Packet relay ............................... 13
2.1.1.7. Wiretap access point ....................... 14
2.1.1.8. ATM "trunk side" interface. ................ 14
2.1.2. Endpoint identifiers ............................ 15
2.1.3. Calls and connections ........................... 17
2.1.3.1. Names of calls ............................. 20
2.1.3.2. Names of connections ....................... 20
2.1.3.3. Management of resources, attributes of ..... 20
2.1.3.4. Special case of local connections .......... 23
2.1.4. Names of Call Agents and other entities ......... 23
2.1.5. Digit maps ...................................... 24
2.1.6. Names of events ................................. 26
2.2. Usage of SDP ......................................... 29
2.3. Gateway Control Commands ............................. 30
1. Introduction .............................................. 5
1.1. Relation with the H.323 standards .................... 7
1.2. Relation with the IETF standards ..................... 8
1.3. Definitions .......................................... 9
2. Media Gateway Control Interface ........................... 9
2.1. Model and naming conventions. ........................ 10
2.1.1. Types of endpoints .............................. 10
2.1.1.1. Digital channel (DS0) ...................... 11
2.1.1.2. Analog line ................................ 11
2.1.1.3. Annoucement server access point ............ 12
2.1.1.4. Interactive Voice Response access point .... 12
2.1.1.5. Conference bridge access point ............. 13
2.1.1.6. Packet relay ............................... 13
2.1.1.7. Wiretap access point ....................... 14
2.1.1.8. ATM "trunk side" interface. ................ 14
2.1.2. Endpoint identifiers ............................ 15
2.1.3. Calls and connections ........................... 17
2.1.3.1. Names of calls ............................. 20
2.1.3.2. Names of connections ....................... 20
2.1.3.3. Management of resources, attributes of ..... 20
2.1.3.4. Special case of local connections .......... 23
2.1.4. Names of Call Agents and other entities ......... 23
2.1.5. Digit maps ...................................... 24
2.1.6. Names of events ................................. 26
2.2. Usage of SDP ......................................... 29
2.3. Gateway Control Commands ............................. 30
2.3.1. EndpointConfiguration ........................... 32
2.3.2. NotificationRequest ............................. 33
2.3.3. CreateConnection ................................ 38
2.3.4. ModifyConnection ................................ 44
2.3.5. DeleteConnection (from the Call Agent) .......... 46
2.3.6. DeleteConnection (from the VoIP gateway) ........ 51
2.3.7. DeleteConnection (multiple connections, from the 51
2.3.8. Audit Endpoint .................................. 52
2.3.9. Audit Connection ................................ 55
2.3.10. Restart in progress ............................ 56
2.4. Return codes and error codes. ........................ 58
2.5. Reason Codes ......................................... 61
3. Media Gateway Control Protocol ............................ 61
3.1. General description .................................. 62
3.2. Command Header ....................................... 62
3.2.1. Command line .................................... 62
3.2.1.1. Coding of the requested verb ............... 63
3.2.1.2. Transaction Identifiers .................... 63
3.2.1.3. Coding of the endpoint identifiers and ..... 64
3.2.1.4. Coding of the protocol version ............. 65
3.2.2. Parameter lines ................................. 65
3.2.2.1. Response Acknowledgement ................... 68
3.2.2.2. Local connection options ................... 68
3.2.2.3. Capabilities ............................... 70
3.2.2.4. Connection parameters ...................... 71
3.2.2.5. Reason Codes ............................... 72
3.2.2.6. Connection mode ............................ 73
3.2.2.7. Coding of event names ...................... 73
3.2.2.8. RequestedEvents ............................ 74
3.2.2.9. SignalRequests ............................. 76
3.2.2.10. ObservedEvent ............................. 76
3.2.2.11. RequestedInfo ............................. 76
3.2.2.12. QuarantineHandling ........................ 77
3.2.2.13. DetectEvents .............................. 77
3.2.2.14. EventStates ............................... 77
3.2.2.15. RestartMethod ............................. 78
3.2.2.16. Bearer Information ........................ 78
3.3. Format of response headers ........................... 78
3.4. Formal syntax description of the protocol ............ 81
3.5. Encoding of the session description .................. 86
3.5.1. Usage of SDP for an audio service ............... 86
3.5.2. Usage of SDP in a network access service ........ 87
3.5.3. Usage of SDP for ATM connections ................ 90
3.5.4. Usage of SDP for local connections .............. 91
3.6. Transmission over UDP ................................ 91
3.6.1. Providing the At-Most-Once functionality ........ 91
3.6.2. Transaction identifiers and three ways handshake. 92
3.6.3. Computing retransmission timers ................. 93
2.3.1. EndpointConfiguration ........................... 32
2.3.2. NotificationRequest ............................. 33
2.3.3. CreateConnection ................................ 38
2.3.4. ModifyConnection ................................ 44
2.3.5. DeleteConnection (from the Call Agent) .......... 46
2.3.6. DeleteConnection (from the VoIP gateway) ........ 51
2.3.7. DeleteConnection (multiple connections, from the 51
2.3.8. Audit Endpoint .................................. 52
2.3.9. Audit Connection ................................ 55
2.3.10. Restart in progress ............................ 56
2.4. Return codes and error codes. ........................ 58
2.5. Reason Codes ......................................... 61
3. Media Gateway Control Protocol ............................ 61
3.1. General description .................................. 62
3.2. Command Header ....................................... 62
3.2.1. Command line .................................... 62
3.2.1.1. Coding of the requested verb ............... 63
3.2.1.2. Transaction Identifiers .................... 63
3.2.1.3. Coding of the endpoint identifiers and ..... 64
3.2.1.4. Coding of the protocol version ............. 65
3.2.2. Parameter lines ................................. 65
3.2.2.1. Response Acknowledgement ................... 68
3.2.2.2. Local connection options ................... 68
3.2.2.3. Capabilities ............................... 70
3.2.2.4. Connection parameters ...................... 71
3.2.2.5. Reason Codes ............................... 72
3.2.2.6. Connection mode ............................ 73
3.2.2.7. Coding of event names ...................... 73
3.2.2.8. RequestedEvents ............................ 74
3.2.2.9. SignalRequests ............................. 76
3.2.2.10. ObservedEvent ............................. 76
3.2.2.11. RequestedInfo ............................. 76
3.2.2.12. QuarantineHandling ........................ 77
3.2.2.13. DetectEvents .............................. 77
3.2.2.14. EventStates ............................... 77
3.2.2.15. RestartMethod ............................. 78
3.2.2.16. Bearer Information ........................ 78
3.3. Format of response headers ........................... 78
3.4. Formal syntax description of the protocol ............ 81
3.5. Encoding of the session description .................. 86
3.5.1. Usage of SDP for an audio service ............... 86
3.5.2. Usage of SDP in a network access service ........ 87
3.5.3. Usage of SDP for ATM connections ................ 90
3.5.4. Usage of SDP for local connections .............. 91
3.6. Transmission over UDP ................................ 91
3.6.1. Providing the At-Most-Once functionality ........ 91
3.6.2. Transaction identifiers and three ways handshake. 92
3.6.3. Computing retransmission timers ................. 93
3.6.4. Piggy backing ................................... 94
3.6.5. Provisional responses ........................... 94
4. States, failover and race conditions. ..................... 95
4.1. Basic Asumptions ..................................... 95
4.2. Security, Retransmission, and Detection of Lost ...... 96
4.3. Race conditions ...................................... 99
4.3.1. Quarantine list ................................. 99
4.3.2. Explicit detection ..............................103
4.3.3. Ordering of commands, and treatment of disorder .104
4.3.4. Fighting the restart avalanche ..................105
4.3.5. Disconnected Endpoints ..........................107
1. A "disconnected" timer is initialized to a random value, .107
2. The gateway then waits for either the end of this timer, .107
3. When the "disconnected" timer elapses, when a command is .107
4. If the "disconnected" procedure still left the endpoint ..107
5. Security requirements .....................................108
5.1. Protection of media connections ......................109
6. Event packages and end point types ........................109
6.1. Basic packages .......................................110
6.1.1. Generic Media Package ...........................110
6.1.2. DTMF package ....................................112
6.1.3. MF Package ......................................113
6.1.4. Trunk Package ...................................114
6.1.5. Line Package ....................................116
6.1.6. Handset emulation package .......................119
6.1.7. RTP Package .....................................120
6.1.8. Network Access Server Package ...................121
6.1.9. Announcement Server Package .....................122
6.1.10. Script Package .................................122
6.2. Basic endpoint types and profiles ....................123
7. Versions and compatibility ................................124
7.1. Differences between version 1.0 and draft 0.5 ........124
7.2. Differences between draft-04 and draft-05 ............125
7.3. Differences between draft-03 and draft-04 ............125
7.4. Differences between draft-02 and draft-03 ............125
7.5. Differences between draft-01 and draft-02 ............126
7.6. The making of MGCP from IPDC and SGCP ................126
7.7. Changes between MGCP and initial versions of SGCP ....126
8. Security Considerations ...................................128
9. Acknowledgements ..........................................128
10. References ................................................129
11. Authors' Addresses ........................................130
12. Appendix A: Proposed "MoveConnection" command .............132
12.1. Proposed syntax modification ........................133
13. Full Copyright Statement ..................................134
3.6.4. Piggy backing ................................... 94
3.6.5. Provisional responses ........................... 94
4. States, failover and race conditions. ..................... 95
4.1. Basic Asumptions ..................................... 95
4.2. Security, Retransmission, and Detection of Lost ...... 96
4.3. Race conditions ...................................... 99
4.3.1. Quarantine list ................................. 99
4.3.2. Explicit detection ..............................103
4.3.3. Ordering of commands, and treatment of disorder .104
4.3.4. Fighting the restart avalanche ..................105
4.3.5. Disconnected Endpoints ..........................107
1. A "disconnected" timer is initialized to a random value, .107
2. The gateway then waits for either the end of this timer, .107
3. When the "disconnected" timer elapses, when a command is .107
4. If the "disconnected" procedure still left the endpoint ..107
5. Security requirements .....................................108
5.1. Protection of media connections ......................109
6. Event packages and end point types ........................109
6.1. Basic packages .......................................110
6.1.1. Generic Media Package ...........................110
6.1.2. DTMF package ....................................112
6.1.3. MF Package ......................................113
6.1.4. Trunk Package ...................................114
6.1.5. Line Package ....................................116
6.1.6. Handset emulation package .......................119
6.1.7. RTP Package .....................................120
6.1.8. Network Access Server Package ...................121
6.1.9. Announcement Server Package .....................122
6.1.10. Script Package .................................122
6.2. Basic endpoint types and profiles ....................123
7. Versions and compatibility ................................124
7.1. Differences between version 1.0 and draft 0.5 ........124
7.2. Differences between draft-04 and draft-05 ............125
7.3. Differences between draft-03 and draft-04 ............125
7.4. Differences between draft-02 and draft-03 ............125
7.5. Differences between draft-01 and draft-02 ............126
7.6. The making of MGCP from IPDC and SGCP ................126
7.7. Changes between MGCP and initial versions of SGCP ....126
8. Security Considerations ...................................128
9. Acknowledgements ..........................................128
10. References ................................................129
11. Authors' Addresses ........................................130
12. Appendix A: Proposed "MoveConnection" command .............132
12.1. Proposed syntax modification ........................133
13. Full Copyright Statement ..................................134
This document describes an abstract application programming interface and a corresponding protocol (MGCP) for controlling Telephony Gateways from external call control elements called media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. Example of gateways are:
本文档描述了一个抽象的应用程序编程接口和相应的协议（MGCP），用于从称为媒体网关控制器或呼叫代理的外部呼叫控制元素控制电话网关。电话网关是一种网络元件，它提供电话电路上承载的音频信号与通过互联网或其他分组网络承载的数据分组之间的转换。网关的示例包括：
* Trunking gateways, that interface between the telephone network and a Voice over IP network. Such gateways typically manage a large number of digital circuits.
* 中继网关，电话网络和IP语音网络之间的接口。此类网关通常管理大量数字电路。
* Voice over ATM gateways, which operate much the same way as voice over IP trunking gateways, except that they interface to an ATM network.
* ATM语音网关，其运行方式与IP语音中继网关基本相同，只是它们与ATM网络连接。
* Residential gateways, that provide a traditional analog (RJ11) interface to a Voice over IP network. Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band wireless devices
* 住宅网关，为IP语音网络提供传统的模拟（RJ11）接口。住宅网关的示例包括电缆调制解调器/电缆机顶盒、xDSL设备、宽带无线设备
* Access gateways, that provide a traditional analog (RJ11) or digital PBX interface to a Voice over IP network. Examples of access gateways include small-scale voice over IP gateways.
* 接入网关，为IP语音网络提供传统的模拟（RJ11）或数字PBX接口。接入网关的示例包括小型IP语音网关。
* Business gateways, that provide a traditional digital PBX interface or an integrated "soft PBX" interface to a Voice over IP network.
* 业务网关，为IP语音网络提供传统的数字PBX接口或集成的“软PBX”接口。
* Network Access Servers, that can attach a "modem" to a telephone circuit and provide data access to the Internet. We expect that, in the future, the same gateways will combine Voice over IP services and Network Access services.
* 网络访问服务器，可将“调制解调器”连接到电话线路，并提供对Internet的数据访问。我们预计，在未来，相同的网关将结合IP语音服务和网络访问服务。
* Circuit switches, or packet switches, which can offer a control interface to an external call control element.
* 电路交换机或分组交换机，可为外部呼叫控制元件提供控制接口。
MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. The MGCP assumes that these call control elements, or Call Agents, will synchronize with each other to send coherent commands to the gateways under their control. MGCP does not define a mechanism for synchronizing Call Agents. MGCP is, in essence, a master/slave protocol, where the gateways are expected to execute commands sent by the Call Agents. In consequence, this document specifies in great detail the expected behavior of the gateways, but
MGCP采用呼叫控制体系结构，其中呼叫控制“智能”位于网关之外，并由外部呼叫控制元素处理。MGCP假定这些呼叫控制元素或呼叫代理将彼此同步，以向其控制下的网关发送一致的命令。MGCP未定义同步呼叫代理的机制。MGCP本质上是一种主/从协议，其中网关应执行呼叫代理发送的命令。因此，本文档详细说明了网关的预期行为，但是
only specify those parts of a call agent implementation, such as timer management, that are mandated for proper operation of the protocol.
仅指定呼叫代理实现的那些部分，如计时器管理，这些部分是协议正常运行所必需的。
MGCP assumes a connection model where the basic constructs are endpoints and connections. Endpoints are sources or sinks of data and could be physical or virtual. Examples of physical endpoints are:
MGCP假设一个连接模型，其中基本构造是端点和连接。端点是数据的源或汇，可以是物理的，也可以是虚拟的。物理端点的示例包括：
* An interface on a gateway that terminates a trunk connected to a PSTN switch (e.g., Class 5, Class 4, etc.). A gateway that terminates trunks is called a trunk gateway.
* 网关上的一种接口，用于终止连接到PSTN交换机（如5级、4级等）的中继。终止中继的网关称为中继网关。
* An interface on a gateway that terminates an analog POTS connection to a phone, key system, PBX, etc. A gateway that terminates residential POTS lines (to phones) is called a residential gateway.
* 网关上的一种接口，用于终止与电话、钥匙系统、PBX等的模拟POTS连接。用于终止住宅POTS线路（与电话）的网关称为住宅网关。
An example of a virtual endpoint is an audio source in an audio-content server. Creation of physical endpoints requires hardware installation, while creation of virtual endpoints can be done by software.
虚拟端点的一个示例是音频内容服务器中的音频源。物理端点的创建需要硬件安装，而虚拟端点的创建可以通过软件完成。
Connections may be either point to point or multipoint. A point to point connection is an association between two endpoints with the purpose of transmitting data between these endpoints. Once this association is established for both endpoints, data transfer between these endpoints can take place. A multipoint connection is established by connecting the endpoint to a multipoint session.
连接可以是点对点或多点。点对点连接是两个端点之间的关联，目的是在这些端点之间传输数据。一旦为两个端点建立了此关联，就可以在这些端点之间进行数据传输。通过将端点连接到多点会话来建立多点连接。
Connections can be established over several types of bearer networks:
可以通过几种类型的承载网络建立连接：
* Transmission of audio packets using RTP and UDP over a TCP/IP network.
* 通过TCP/IP网络使用RTP和UDP传输音频数据包。
* Transmission of audio packets using AAL2, or another adaptation layer, over an ATM network.
* 通过ATM网络使用AAL2或另一适配层传输音频数据包。
* Transmission of packets over an internal connection, for example the TDM backplane or the interconnection bus of a gateway. This is used, in particular, for "hairpin" connections, connections that terminate in a gateway but are immediately rerouted over the telephone network.
* 通过内部连接（例如TDM背板或网关的互连总线）传输数据包。这尤其用于“发夹”连接，即终止于网关但立即通过电话网络重新路由的连接。
For point-to-point connections the endpoints of a connection could be in separate gateways or in the same gateway.
对于点对点连接，连接的端点可以位于单独的网关中，也可以位于同一网关中。
MGCP is designed as an internal protocol within a distributed system that appears to the outside as a single VoIP gateway. This system is composed of a Call Agent, that may or may not be distributed over several computer platforms, and of a set of gateways, including at least one "media gateway" that perform the conversion of media signals between circuits and packets, and at least one "signalling gateway" when connecting to an SS7 controlled network. In a typical configuration, this distributed gateway system will interface on one side with one or more telephony (i.e. circuit) switches, and on the other side with H.323 conformant systems, as indicated in the following table:
MGCP被设计为分布式系统内的内部协议，在外部看来，它是一个单一的VoIP网关。该系统由呼叫代理（可能分布在多个计算机平台上，也可能不分布在多个计算机平台上）和一组网关组成，包括至少一个在电路和分组之间执行媒体信号转换的“媒体网关”，以及连接到SS7控制网络时的至少一个“信令网关”。在典型配置中，该分布式网关系统将一边与一个或多个电话（即电路）交换机接口，另一边与符合H.323标准的系统接口，如下表所示：
___________________________________________________________________
| Functional| Phone | Terminating | H.323 conformant |
| Plane | switch | Entity | systems |
|___________|____________|_________________|_______________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through H.225/RAS and|
| | SS7/ISUP | | H.225/Q.931. |
|___________|____________|_________________|_______________________|
| | | | Possible negotiation |
| | | | of logical channels |
| | | | and transmission |
| | | | parameters through |
| | | | H.245 with the call |
| | | | agent. |
|___________|____________|_________________|_______________________|
| | | Internal | |
| | | synchronization| |
| | | through MGCP | |
|___________|____________|_________________|_______________________|
| Bearer | Connection| Telephony | Transmission of VOIP |
| Data | through | gateways | data using RTP |
| Transport | high speed| | directly between the |
| Plane | trunk | | H.323 station and the|
| | groups | | gateway. |
|___________|____________|_________________|_______________________|
___________________________________________________________________
| Functional| Phone | Terminating | H.323 conformant |
| Plane | switch | Entity | systems |
|___________|____________|_________________|_______________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through H.225/RAS and|
| | SS7/ISUP | | H.225/Q.931. |
|___________|____________|_________________|_______________________|
| | | | Possible negotiation |
| | | | of logical channels |
| | | | and transmission |
| | | | parameters through |
| | | | H.245 with the call |
| | | | agent. |
|___________|____________|_________________|_______________________|
| | | Internal | |
| | | synchronization| |
| | | through MGCP | |
|___________|____________|_________________|_______________________|
| Bearer | Connection| Telephony | Transmission of VOIP |
| Data | through | gateways | data using RTP |
| Transport | high speed| | directly between the |
| Plane | trunk | | H.323 station and the|
| | groups | | gateway. |
|___________|____________|_________________|_______________________|
In the MGCP model, the gateways focus on the audio signal translation function, while the Call Agent handles the signaling and call processing functions. As a consequence, the Call Agent implements the "signaling" layers of the H.323 standard, and presents itself as an "H.323 Gatekeeper" or as one or more "H.323 Endpoints" to the H.323 systems.
在MGCP模型中，网关专注于音频信号转换功能，而呼叫代理处理信令和呼叫处理功能。因此，呼叫代理实现H.323标准的“信令”层，并将自己呈现为H.323系统的“H.323网守”或一个或多个“H.323端点”。
While H.323 is the recognized standard for VoIP terminals, the IETF has also produced specifications for other types of multi-media applications. These other specifications include:
虽然H.323是公认的VoIP终端标准，但IETF也为其他类型的多媒体应用制定了规范。这些其他规格包括：
* the Session Description Protocol (SDP), RFC 2327,
* 会话描述协议（SDP），RFC2327，
* the Session Announcement Protocol (SAP),
* 会话公告协议（SAP），
* the Session Initiation Protocol (SIP),
* 会话启动协议（SIP），
* the Real Time Streaming Protocol (RTSP), RFC 2326.
* 实时流协议（RTSP），RFC2326。
The latter three specifications are in fact alternative signaling standards that allow for the transmission of a session description to an interested party. SAP is used by multicast session managers to distribute a multicast session description to a large group of recipients, SIP is used to invite an individual user to take part in a point-to-point or unicast session, RTSP is used to interface a server that provides real time data. In all three cases, the session description is described according to SDP; when audio is transmitted, it is transmitted through the Real-time Transport Protocol, RTP.
后三个规范实际上是替代信令标准，允许将会话描述传输给相关方。多播会话管理器使用SAP将多播会话描述分发给一大群收件人，SIP用于邀请单个用户参与点对点或单播会话，RTSP用于连接提供实时数据的服务器。在所有三种情况下，根据SDP描述会话描述；当音频传输时，它通过实时传输协议RTP传输。
The distributed gateway systems and MGCP will enable PSTN telephony users to access sessions set up using SAP, SIP or RTSP. The Call Agent provides for signaling conversion, according to the following table:
分布式网关系统和MGCP将使PSTN电话用户能够访问使用SAP、SIP或RTSP设置的会话。呼叫代理根据下表提供信令转换：
_____________________________________________________________________
| Functional| Phone | Terminating | IETF conforming systems|
| Plane | switch | Entity | |
|___________|____________|_________________|_________________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through SAP, SIP or |
| | SS7/ISUP | | RTSP. |
|___________|____________|_________________|_________________________|
| | | | Negotiation of session |
| | | | description parameters |
| | | | through SDP (telephony |
| | | | gateway terminated but |
| | | | passed via the call |
| | | | agent to and from the |
| | | | IETF conforming system)|
|___________|____________|_________________|_________________________|
| | | Internal | |
| | | synchronization| |
| | | through MGCP | |
|___________|____________|_________________|_________________________|
| Bearer | Connection| Telephony | Transmission of VoIP |
| Data | through | gateways | data using RTP, |
| Transport | high speed| | directly between the |
| Plane | trunk | | remote IP end system |
| | groups | | and the gateway. |
|___________|____________|_________________|_________________________|
_____________________________________________________________________
| Functional| Phone | Terminating | IETF conforming systems|
| Plane | switch | Entity | |
|___________|____________|_________________|_________________________|
| Signaling | Signaling | Call agent | Signaling exchanges |
| Plane | exchanges | | with the call agent |
| | through | | through SAP, SIP or |
| | SS7/ISUP | | RTSP. |
|___________|____________|_________________|_________________________|
| | | | Negotiation of session |
| | | | description parameters |
| | | | through SDP (telephony |
| | | | gateway terminated but |
| | | | passed via the call |
| | | | agent to and from the |
| | | | IETF conforming system)|
|___________|____________|_________________|_________________________|
| | | Internal | |
| | | synchronization| |
| | | through MGCP | |
|___________|____________|_________________|_________________________|
| Bearer | Connection| Telephony | Transmission of VoIP |
| Data | through | gateways | data using RTP, |
| Transport | high speed| | directly between the |
| Plane | trunk | | remote IP end system |
| | groups | | and the gateway. |
|___________|____________|_________________|_________________________|
The SDP standard has a pivotal status in this architecture. We will see in the following description that we also use it to carry session descriptions in MGCP.
SDP标准在该体系结构中具有举足轻重的地位。我们将在下面的描述中看到，我们还使用它在MGCP中进行会话描述。
Trunk: A communication channel between two switching systems. E.g., a DS0 on a T1 or E1 line.
中继线：两个交换系统之间的通信通道。例如，T1或E1线路上的DS0。
The interface functions provide for connection control and endpoint control. Both use the same system model and the same naming conventions.
接口函数提供连接控制和端点控制。两者都使用相同的系统模型和相同的命名约定。
The MGCP assumes a connection model where the basic constructs are endpoints and connections. Connections are grouped in calls. One or more connections can belong to one call. Connections and calls are set up at the initiative of one or several Call Agents.
MGCP假设一个连接模型，其中基本构造是端点和连接。连接在调用中分组。一个或多个连接可以属于一个呼叫。连接和呼叫由一个或多个呼叫代理主动建立。
In the introduction, we presented several classes of gateways. Such classifications, however, can be misleading. Manufacturers can arbitrarily decide to provide several types of services in a single packaging. A single product could well, for example, provide some trunk connections to telephony switches, some primary rate connections and some analog line interfaces, thus sharing the characteristics of what we described in the introduction as "trunking", "access" and "residential" gateways. MGCP does not make assumptions about such groupings. We simply assume that media gateways support collections of endpoints. The type of the endpoint determines its functionalities. Our analysis, so far, has led us to isolate the following basic endpoint types:
在引言中，我们介绍了几类网关。然而，这样的分类可能会产生误导。制造商可以任意决定在一个包装中提供几种类型的服务。例如，单个产品可以提供一些到电话交换机的中继连接、一些主要速率连接和一些模拟线路接口，从而共享我们在介绍中描述的“中继”、“接入”和“住宅”网关的特征。MGCP不对此类分组进行假设。我们只是假设媒体网关支持端点集合。端点的类型决定其功能。到目前为止，我们的分析已使我们分离出以下基本端点类型：
* Digital channel (DS0),
* 数字信道（DS0），
* Analog line,
* 模拟线，
* Annoucement server access point,
* 通知服务器访问点，
* Interactive Voice Response access point,
* 交互式语音响应接入点，
* Conference bridge access point,
* 会议桥接入点，
* Packet relay,
* 分组中继，
* Wiretap access point,
* 窃听接入点，
* ATM "trunk side" interface.
* ATM“中继端”接口。
In this section, we will develop the expected behavior of such end points.
在本节中，我们将开发这些端点的预期行为。
This list is not limitative. There may be other types of endpoints defined in the future, for example test endpoint that could be used to check network quality, or frame-relay endpoints that could be used to managed audio channels multiplexed over a frame-relay virtual circuit.
这个清单并没有限制性。将来可能会定义其他类型的端点，例如可用于检查网络质量的测试端点，或可用于通过帧中继虚拟电路多路复用的受管理音频信道的帧中继端点。
Digital channels provide an 8Khz*8bit service. Such channels are found in trunk and ISDN interfaces. They are typically part of digital multiplexes, such as T1, E1, T3 or E3 interfaces. Media gateways that support such channels are capable of translating the digital signals received on the channel, which may be encoded according to A or mu-law, using either the complete set of 8 bits or only 7 of these bits, into audio packets. When the media gateway also supports a NAS service, the gateway shall be capable of receiving either audio-encoded data (modem connection) or binary data (ISDN connection) and convert them into data packets.
数字信道提供8Khz*8bit服务。这种信道存在于中继和ISDN接口中。它们通常是数字多路复用的一部分，如T1、E1、T3或E3接口。支持此类信道的媒体网关能够将在信道上接收的数字信号转换为音频分组，该数字信号可以使用8位的完整集合或仅使用其中的7位，根据或mu法则进行编码。当媒体网关还支持NAS服务时，网关应能够接收音频编码数据（调制解调器连接）或二进制数据（ISDN连接），并将其转换为数据包。
+-------
+------------+|
(channel) ===|DS0 endpoint| -------- Connections
+------------+|
+-------
+-------
+------------+|
(channel) ===|DS0 endpoint| -------- Connections
+------------+|
+-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway.
媒体网关应该能够在端点和分组网络之间，或者在端点和同一网关中的其他端点之间建立多个连接。来自这些连接的信号应根据本文件后面规定的连接“模式”进行混合。端点支持的连接的精确数量是网关的一个特征，并且实际上可能根据网关内的资源分配而变化。
In some cases, digital channels are used to carry signalling. This is the case for example of SS7 "F" links, or ISDN "D" channels. Media gateways that support these signalling functions shall be able to send and receive the signalling packets to and from a call agent, using the "back haul" procedures defined by the SIGTRAN working group of the IETF. Digital channels are sometimes used in conjunction with channel associated signalling, such as "MF R2". Media gateways that support these signalling functions shall be able to detect and produce the corresponding signals, such as for example "wink" or "A", according to the event signalling and reporting procedures defined in MGCP.
在某些情况下，数字信道用于传输信号。例如，SS7“F”链路或ISDN“D”信道就是这种情况。支持这些信令功能的媒体网关应能够使用IETF SIGTRAN工作组定义的“回程”程序向呼叫代理发送和接收信令包。数字信道有时与信道相关信令（如“MF R2”）一起使用。支持这些信令功能的媒体网关应能够根据MGCP中定义的事件信令和报告程序检测并产生相应的信号，例如“wink”或“A”。
Analog lines can be used either as a "client" interface, providing service to a classic telephone unit, or as a "service" interface, allowing the gateway to send and receive analog calls. When the media gateway also supports a NAS service, the gateway shall be capable of receiving audio-encoded data (modem connection) and convert them into data packets.
模拟线路既可以用作“客户端”接口，为传统电话单元提供服务，也可以用作“服务”接口，允许网关发送和接收模拟呼叫。当媒体网关还支持NAS服务时，网关应能够接收音频编码数据（调制解调器连接），并将其转换为数据包。
+-------
+---------------+|
(line) ===|analog endpoint| -------- Connections
+---------------+|
+-------
+-------
+---------------+|
(line) ===|analog endpoint| -------- Connections
+---------------+|
+-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The audio signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway. A typical gateway should however be able to support two or three connections per endpoint, in order to provide services such as "call waiting" or "three ways calling".
媒体网关应该能够在端点和分组网络之间，或者在端点和同一网关中的其他端点之间建立多个连接。来自这些连接的音频信号应根据本文件后面规定的连接“模式”进行混合。端点支持的连接的精确数量是网关的一个特征，并且实际上可能根据网关内的资源分配而变化。然而，一个典型的网关应该能够支持每个端点两个或三个连接，以便提供诸如“呼叫等待”或“三路呼叫”之类的服务。
An announcement server endpoint provides acces to an announcement service. Under requests from the call agent, the announcement server will "play" a specified announcement. The requests from the call agent will follow the event signalling and reporting procedures defined in MGCP.
公告服务器终结点提供对公告服务的访问。在呼叫代理的请求下，公告服务器将“播放”指定的公告。来自呼叫代理的请求将遵循MGCP中定义的事件信令和报告程序。
+----------------------+
| Announcement endpoint| -------- Connection
+----------------------+
+----------------------+
| Announcement endpoint| -------- Connection
+----------------------+
A given announcement endpoint is not supposed to support more than one connection at a time. If several connections were established to the same endpoint, then the same announcements would be played simultaneously over all the connections.
给定的公告端点一次不应支持多个连接。如果在同一端点上建立了多个连接，那么将在所有连接上同时播放相同的公告。
Connections to an announcement server are typically oneway, or "half duplex" -- the announcement server is not expected to listen the audio signals from the connection.
到公告服务器的连接通常是单向的，或“半双工”——公告服务器不需要监听来自连接的音频信号。
An Interactive Voice Response (IVR) endpoint provides acces to an IVR service. Under requests from the call agent, the IVR server will "play" announcements and tones, and will "listen" to responses from the user. The requests from the call agent will follow the event signalling and reporting procedures defined in MGCP.
交互式语音应答（IVR）端点提供对IVR服务的访问。在呼叫代理的请求下，IVR服务器将“播放”通知和铃声，并“收听”用户的响应。来自呼叫代理的请求将遵循MGCP中定义的事件信令和报告程序。
+-------------+
| IVR endpoint| -------- Connection
+-------------+
+-------------+
| IVR endpoint| -------- Connection
+-------------+
A given IVR endpoint is not supposed to support more than one connection at a time. If several connections were established to the same endpoint, then the same tones and announcements would be played simultaneously over all the connections.
给定的IVR端点一次不应支持多个连接。如果在同一端点上建立了多个连接，那么将在所有连接上同时播放相同的音调和公告。
A conference bridge endpoint is used to provide access to a specific conference.
会议网桥端点用于提供对特定会议的访问。
+-------
+--------------------------+|
|Conference bridge endpoint| -------- Connections
+--------------------------+|
+-------
+-------
+--------------------------+|
|Conference bridge endpoint| -------- Connections
+--------------------------+|
+-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway.
媒体网关应该能够在端点和分组网络之间，或者在端点和同一网关中的其他端点之间建立多个连接。来自这些连接的信号应根据本文件后面规定的连接“模式”进行混合。端点支持的连接的精确数量是网关的一个特征，并且实际上可能根据网关内的资源分配而变化。
A packet relay endpoint is a specific form of conference bridge, that typically only supports two connections. Packets relays can be found in firewalls between a protected and an open network, or in transcoding servers used to provide interoperation between incompatible gateways, for example gateways that do not support compatible compression algorithms, or gateways that operate over different transmission networks such as IP and ATM.
分组中继端点是一种特定形式的会议网桥，通常只支持两个连接。包中继可以在受保护网络和开放网络之间的防火墙中找到，或者在用于提供不兼容网关之间互操作的转码服务器中找到，例如不支持兼容压缩算法的网关，或者在不同传输网络（如IP和ATM）上运行的网关。
+-------
+---------------------+ |
|Packet relay endpoint| 2 connections
+---------------------+ |
+-------
+-------
+---------------------+ |
|Packet relay endpoint| 2 connections
+---------------------+ |
+-------
A wiretap access point provides access to a wiretap service, providing either a recording or a life playback of a connection.
wiretap接入点提供对wiretap服务的访问，提供连接的录音或生活回放。
+-----------------+
| Wiretap endpoint| -------- Connection
+-----------------+
+-----------------+
| Wiretap endpoint| -------- Connection
+-----------------+
A given wiretap endpoint is not supposed to support more than one connection at a time. If several connections were established to the same endpoint, then the recording or playback would mix the audio signals received on this connections.
给定的窃听端点一次不应支持多个连接。如果在同一端点上建立了多个连接，则录制或回放将混合在该连接上接收的音频信号。
Connections to an wiretap endpoint are typically oneway, or "half duplex" -- the wiretap server is not expected to signal its presence in a call.
到wiretap端点的连接通常是单向的，或“半双工”——wiretap服务器不需要在呼叫中发出信号。
2.1.1.8. ATM "trunk side" interface.
2.1.1.8. ATM“中继端”接口。
ATM "trunk side" endpoints are typically found when one or several ATM permanent virtual circuits are used as a replacement for the classic "TDM" trunks linking switches. When ATM/AAL2 is used, several trunks or channels are multiplexed on a single virtual circuit; each of these trunks correspond to a single endpoint.
当使用一个或多个ATM永久虚拟电路替代传统的“TDM”中继链路交换机时，通常会找到ATM“中继端”端点。当使用ATM/AAL2时，在单个虚拟电路上多路复用多个中继或信道；每个中继都对应于一个端点。
+-------
+------------------+|
(channel) = |ATM trunk endpoint| -------- Connections
+------------------+|
+-------
+-------
+------------------+|
(channel) = |ATM trunk endpoint| -------- Connections
+------------------+|
+-------
Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections shall be mixed according to the connection "mode", as specified later in this document. The precise number of connections that an endpoint support is a characteristic of the gateway, and may in fact vary according with the allocation of resource within the gateway.
媒体网关应该能够在端点和分组网络之间，或者在端点和同一网关中的其他端点之间建立多个连接。来自这些连接的信号应根据本文件后面规定的连接“模式”进行混合。端点支持的连接的精确数量是网关的一个特征，并且实际上可能根据网关内的资源分配而变化。
Endpoints identifiers have two components that both are case insensitive:
端点标识符有两个不区分大小写的组件：
* the domain name of the gateway that is managing the endpoint,
* 管理终结点的网关的域名，
* a local name within that gateway,
* 该网关中的本地名称，
The syntax of the local name depends on the type of endpoint being named. However, the local name for each of these types is naturally hierarchical, beginning with a term which identifies the physical gateway containing the given endpoint and ending in a term which specifies the individual endpoint concerned. With this in mind, the following rules for construction and interpretation of the Entity Name field for these entity types MUST be supported:
本地名称的语法取决于要命名的端点的类型。但是，每种类型的本地名称都是自然分层的，从标识包含给定端点的物理网关的术语开始，到指定相关的单个端点的术语结束。考虑到这一点，必须支持以下规则来构造和解释这些实体类型的实体名称字段：
1) The individual terms of the naming path MUST be separated by a single slash ("/", ASCII 2F hex).
1) 命名路径的各个术语必须用一个斜杠（“/”，ASCII 2F十六进制）分隔。
2) The individual terms are character strings composed of letters, digits or other printable characters, with the exception of characters used as delimitors ("/", "@"), characters used for wildcarding ("*", "$") and white spaces.
2) 单个术语是由字母、数字或其他可打印字符组成的字符串，但用作定界符（“/”、“@”）的字符、用于通配符（“*”、“$”）的字符和空格除外。
3) Wild-carding is represented either by an asterisk ("*") or a dollar sign ("$") for the terms of the naming path which are to be wild-carded. Thus, if the full naming path looks like
3) 对于要进行通配符的命名路径，通配符由星号（*）或美元符号（$）表示。因此，如果完整的命名路径如下
term1/term2/term3
第1条/第2条/第3条
then the Entity Name field looks like this depending on which terms are wild-carded:
然后，实体名称字段看起来如下所示，具体取决于通配符：
*/term2/term3 if term1 is wild-carded
term1/*/term3 if term2 is wild-carded
term1/term2/* if term3 is wild-carded
term1/*/* if term2 and term3 are wild-carded,
etc.
*/term2/term3 if term1 is wild-carded
term1/*/term3 if term2 is wild-carded
term1/term2/* if term3 is wild-carded
term1/*/* if term2 and term3 are wild-carded,
etc.
In each of these examples a dollar sign could have appeared instead of an asterisk.
在这些例子中，每一个都可能出现一个美元符号而不是星号。
4) A term represented by an asterisk is to be interpreted as: "use ALL values of this term known within the scope of the Media Gateway". A term represented by a dollar sign is to be interpreted as: "use ANY ONE value of this term known within the scope of the Media Gateway". The description of a specific command may add further criteria for selection within the general rules given here.
4) 用星号表示的术语应解释为：“使用媒体网关范围内已知的该术语的所有值”。美元符号表示的术语应解释为：“使用媒体网关范围内已知的该术语的任何一个值”。特定命令的描述可在此处给出的一般规则中添加更多选择标准。
If the Media Gateway controls multiple physical gateways, the first term of the naming MUST identify the physical gateway containing the desired entity. If the Media Gateway controls only a single physical gateway, the first term of the naming string MAY identify that physical gateway, depending on local practice. A local name that is composed of only a wildcard character refers to either all (*) or any ($) endpoints within the media gateway.
如果媒体网关控制多个物理网关，则命名的第一个术语必须标识包含所需实体的物理网关。如果媒体网关仅控制单个物理网关，则根据本地实践，命名字符串的第一项可以标识该物理网关。仅由通配符组成的本地名称引用媒体网关中的所有（*）或任何（$）端点。
In the case of trunking gateways, endpoints are trunk circuits linking a gateway to a telephone switch. These circuits are typically grouped into a digital multiplex, that is connected to the gateway by a physical interface. Such circuits are named in three contexts:
对于中继网关，端点是将网关连接到电话交换机的中继电路。这些电路通常组合成数字多路复用器，通过物理接口连接到网关。此类回路在三种上下文中命名：
* In the ISUP protocol, trunks are grouped into trunk groups, identified by the SS7 point codes of the switches that the group connects. Circuits within a trunk group are identified by a circuit number (CIC in ISUP).
* 在ISUP协议中，中继被分组为中继组，由组连接的交换机的SS7点代码标识。中继线组内的电路由电路编号（ISUP中的CIC）标识。
* In the gateway configuration files, physical interfaces are typically identified by the name of the interface, an arbitrary text string. When the interface multiplexes several circuits, individual circuits are typically identified by a circuit number.
* 在网关配置文件中，物理接口通常由接口的名称（任意文本字符串）标识。当接口多路复用多个电路时，单个电路通常由电路编号标识。
* In MGCP, the endpoints are identified by an endpoint identifier.
* 在MGCP中，端点由端点标识符标识。
The Call Agents use configuration databases to map ranges of circuit numbers within an ISUP trunk group to corresponding ranges of circuits in a multiplex connected to a gateway through a physical interface. The gateway will be identified, in MGCP, by a domain name. The local name will be structured to encode both the name of the physical interface, for example X35V3+A4, and the circuit number within the multiplex connected to the interface, for example 13. The circuit number will be separated from the name of the interface by a fraction bar, as in:
呼叫代理使用配置数据库将ISUP中继组内的电路号范围映射到通过物理接口连接到网关的多路复用中的相应电路范围。在MGCP中，网关将通过域名进行标识。本地名称的结构将对物理接口的名称（例如X35V3+A4）和连接到接口的多路复用器内的电路号（例如13）进行编码。电路编号将通过分栏与接口名称分开，如所示：
X35V3+A4/13
X35V3+A4/13
Other types of endpoints will use different conventions. For example, in gateways were physical interfaces by construction only control one circuit, the circuit number will be omitted. The exact syntax of such names should be specified in the corresponding server specification.
其他类型的端点将使用不同的约定。例如，在网关的物理接口中，通过构造只控制一个电路，电路号将被省略。此类名称的确切语法应在相应的服务器规范中指定。
Connections are created on the call agent on each endpoint that will be involved in the "call." In the classic example of a connection between two "DS0" endpoints (EP1 and EP2), the call agents controlling the end points will establish two connections (C1 and C2):
在“呼叫”涉及的每个端点上的呼叫代理上创建连接。在两个“DS0”端点（EP1和EP2）之间连接的经典示例中，控制端点的呼叫代理将建立两个连接（C1和C2）：
+---+ +---+
(channel1) ===|EP1|--(C1)--... ...(C2)--|EP2|===(channel2)
+---+ +---+
+---+ +---+
(channel1) ===|EP1|--(C1)--... ...(C2)--|EP2|===(channel2)
+---+ +---+
Each connection will be designated locally by a connection identifier, and will be characterized by connection attributes.
每个连接将由连接标识符在本地指定，并由连接属性表征。
When the two endpoints are located on gateways that are managed by the same call agent, the creation is done via the three following steps:
当两个端点位于由同一呼叫代理管理的网关上时，将通过以下三个步骤完成创建：
1) The call agent asks the first gateway to "create a connection" on the first endpoint. The gateway allocates resources to that connection, and respond to the command by providing a "session description." The session description contains the information necessary for a third party to send packets towards the newly created connection, such as for example IP address, UDP port, and packetization parameters.
1) 呼叫代理要求第一个网关在第一个端点上“创建连接”。网关为该连接分配资源，并通过提供“会话描述”响应命令。会话描述包含第三方向新创建的连接发送数据包所需的信息，例如IP地址、UDP端口和打包参数。
2) The call agent then asks the second gateway to "create a connection" on the second endpoint. The command carries the "session description" provided by the first gateway. The gateway allocates resources to that connection, and respond to the command by providing its own "session description."
2) 呼叫代理然后要求第二个网关在第二个端点上“创建连接”。该命令携带第一个网关提供的“会话描述”。网关将资源分配给该连接，并通过提供自己的“会话描述”来响应该命令
3) The call agent uses a "modify connection" command to provide this second "session description" to the first endpoint. Once this is done, communication can proceed in both directions.
3) 调用代理使用“修改连接”命令向第一个端点提供第二个“会话描述”。一旦完成，通信可以在两个方向上进行。
When the two endpoints are located on gateways that are managed by the different call agents, these two call agents shall exchange information through a call-agent to call-agent signalling protocol, in order to synchronize the creation of the connection on the two endpoints.
当两个端点位于由不同呼叫代理管理的网关上时，这两个呼叫代理应通过呼叫代理到呼叫代理信令协议交换信息，以便在两个端点上同步连接的创建。
Once established, the connection parameters can be modified at any time by a "modify connection" command. The call agent may for example instruct the gateway to change the compression algorithm used on a connection, or to modify the IP address and UDP port to which data should be sent, if a connection is "redirected."
一旦建立，可以随时通过“修改连接”命令修改连接参数。呼叫代理例如可以指示网关改变连接上使用的压缩算法，或者如果连接被“重定向”，则指示网关修改数据应该发送到的IP地址和UDP端口
The call agent removes a connection by sending to the gateway a "delete connection" command. The gateway may also, under some circumstances, inform a gateway that a connection could not be sustained.
呼叫代理通过向网关发送“删除连接”命令来删除连接。在某些情况下，网关还可以通知网关连接无法维持。
The following diagram provides a view of the states of a connection, as seen from the gateway:
下图提供了从网关看到的连接状态视图：
Create connection
received
|
V
+-------------------+
|resource allocation|-(failed)-+
+-------------------+ |
| (connection refused)
(successful)
|
v
+----------->+
| |
| +-------------------+
| | remote session |
| | description |----------(yes)--------+
| | available ? | |
| +-------------------+ |
| | |
| (no) |
| | |
| +-----------+ +------+
| +--->| half open |------> Delete <-------| open |<----------+
| | | (wait) | Connection |(wait)| |
| | +-----------+ received +------+ |
| | | | | |
| | Modify Connection | Modify Connection |
| | received | received |
| | | | | |
| | +--------------------+ | +--------------------+ |
| | |assess modification | | |assess modification | |
| | +--------------------+ | +--------------------+ |
| | | | | | | |
| |(failed) (successful) | (failed) (successful) |
| | | | | | | |
| +<---+ | | +-------------+-------+
| | |
+<-------------------+ |
|
+-----------------+
| Free connection |
| resources. |
| Report. |
+-----------------+
|
V
Create connection
received
|
V
+-------------------+
|resource allocation|-(failed)-+
+-------------------+ |
| (connection refused)
(successful)
|
v
+----------->+
| |
| +-------------------+
| | remote session |
| | description |----------(yes)--------+
| | available ? | |
| +-------------------+ |
| | |
| (no) |
| | |
| +-----------+ +------+
| +--->| half open |------> Delete <-------| open |<----------+
| | | (wait) | Connection |(wait)| |
| | +-----------+ received +------+ |
| | | | | |
| | Modify Connection | Modify Connection |
| | received | received |
| | | | | |
| | +--------------------+ | +--------------------+ |
| | |assess modification | | |assess modification | |
| | +--------------------+ | +--------------------+ |
| | | | | | | |
| |(failed) (successful) | (failed) (successful) |
| | | | | | | |
| +<---+ | | +-------------+-------+
| | |
+<-------------------+ |
|
+-----------------+
| Free connection |
| resources. |
| Report. |
+-----------------+
|
V
One of the attributes of each connection is the "call identifier."
每个连接的属性之一是“调用标识符”
Calls are identified by unique identifiers, independent of the underlying platforms or agents. These identifiers are created by the Call Agent. They are treated in MGCP as unstructured octet strings.
调用由唯一标识符标识，独立于底层平台或代理。这些标识符由呼叫代理创建。它们在MGCP中被视为非结构化八位组字符串。
Call identifiers are expected to be unique within the system, or at a minimum, unique within the collection of Call Agents that control the same gateways. When a Call Agent builds several connections that pertain to the same call, either on the same gateway or in different gateways, these connections that belong to the same call share the same call-id. This identifier can then be used by accounting or management procedures, which are outside the scope of MGCP.
呼叫标识符在系统中是唯一的，或者至少在控制相同网关的呼叫代理集合中是唯一的。当呼叫代理在同一网关或不同网关上构建与同一呼叫相关的多个连接时，属于同一呼叫的这些连接共享相同的呼叫id。然后，该标识符可由MGCP范围之外的记帐或管理过程使用。
Connection identifiers are created by the gateway when it is requested to create a connection. They identify the connection within the context of an endpoint. They are treated in MGCP as unstructured octet strings. The gateway should make sure that a proper waiting period, at least 3 minutes, elapses between the end of a connection that used this identifier and its use in a new connection for the same endpoint. (Gateways may decide to use identifiers that are unique within the context of the gateway.)
当请求网关创建连接时，网关将创建连接标识符。它们标识端点上下文中的连接。它们在MGCP中被视为非结构化八位组字符串。网关应确保在使用此标识符的连接结束和在同一端点的新连接中使用此标识符之间经过适当的等待时间（至少3分钟）。（网关可能决定使用在网关上下文中唯一的标识符。）
Many types of resources will be associated to a connection, such as specific signal processing functions or packetization functions. Generally, these resources fall in two categories:
许多类型的资源将与连接相关联，例如特定的信号处理功能或打包功能。通常，这些资源分为两类：
1) Externally visible resources, that affect the format of "the bits on the network" and must be communicated to the second endpoint involved in the connection.
1) 外部可见资源，影响“网络上的位”的格式，必须与连接中涉及的第二个端点通信。
2) Internal resources, that determine which signal is being sent over the connection and how the received signals are processed by the endpoint.
2) 内部资源，用于确定通过连接发送的信号以及端点如何处理接收到的信号。
The resources allocated to a connection, and more generally the handling of the connection, are chosen by the gateway under instructions from the call agent. The call agent will provide these instructions by sending two set of parameters to the gateway:
分配给连接的资源，以及更一般的连接处理，由网关根据呼叫代理的指示进行选择。呼叫代理将通过向网关发送两组参数来提供这些指示：
1) The local directives instruct the gateway on the choice of resources that should be used for a connection,
1) 本地指令指示网关选择用于连接的资源，
2) When available, the "session description" provided by the other end of the connection.
2) 可用时，连接另一端提供的“会话描述”。
The local directives specify such parameters as the mode of the connection (e.g. send only, send-receive), preferred coding or packetization methods, usage of echo cancellation or silence suppression. (A detailed list can be found in the specification of the LocalConnectionOptions parameter of the CreateConnection command.) For each of these parameters, the call agent can either specify a value, a range of value, or no value at all. This allow various implementations to implement various level of control, from a very tight control where the call agent specifies minute details of the connection handling to a very loose control where the call agent only specifies broad guidelines, such as the maximum bandwidth, and let the gateway choose the detailed values.
本地指令指定诸如连接模式（例如，仅发送、发送-接收）、首选编码或打包方法、回声消除或静音抑制的使用等参数。（详细列表可在CreateConnection命令的LocalConnectionOptions参数的规范中找到。）对于这些参数中的每个参数，调用代理可以指定一个值、一个值的范围，或者根本不指定任何值。这允许各种实现实现不同级别的控制，从非常严格的控制（其中呼叫代理指定连接处理的详细信息）到非常松散的控制（其中呼叫代理仅指定广泛的指导原则，例如最大带宽），并让网关选择详细的值。
Based on the value of the local directives, the gateway will determine the resources allocated to the connection. When this is possible, the gateway will choose values that are in line with the remote session description - but there is no absolute requirement that the parameters be exactly the same.
网关将根据本地指令的值确定分配给连接的资源。如果这是可能的，网关将选择与远程会话描述一致的值-但没有绝对要求参数完全相同。
Once the resource have been allocated, the gateway will compose a "session description" that describes the way it intends to receive packets. Note that the session description may in some cases present a range of values. For example, if the gateway is ready to accept one of several compression algorithm, it can provide a list of these accepted algorithms.
一旦分配了资源，网关将组成一个“会话描述”，描述其接收数据包的方式。请注意，会话描述在某些情况下可能会显示一系列值。例如，如果网关准备接受几种压缩算法中的一种，它可以提供这些已接受算法的列表。
Local Directives
(from call agent 1)
|
V
+-------------+
| resources |
| allocation |
| (gateway 1) |
+-------------+
| |
V |
Local |
Parameters V
| Session
| Description Local Directives
| | (from call agent 2)
| +---> Transmission----+ |
| (CA to CA) | |
| V V
| +-------------+
| | resources |
| | allocation |
| | (gateway 2) |
| +-------------+
| | |
| | V
| | Local
| | Parameters
| Session
| Description
| +---- Transmission<---+
| | (CA to CA)
V V
+-------------+
| modification|
| (gateway 1) |
+-------------+
|
V
Local
Parameters
Local Directives
(from call agent 1)
|
V
+-------------+
| resources |
| allocation |
| (gateway 1) |
+-------------+
| |
V |
Local |
Parameters V
| Session
| Description Local Directives
| | (from call agent 2)
| +---> Transmission----+ |
| (CA to CA) | |
| V V
| +-------------+
| | resources |
| | allocation |
| | (gateway 2) |
| +-------------+
| | |
| | V
| | Local
| | Parameters
| Session
| Description
| +---- Transmission<---+
| | (CA to CA)
V V
+-------------+
| modification|
| (gateway 1) |
+-------------+
|
V
Local
Parameters
-- Information flow: local directives & session descriptions --
--信息流：本地指令和会话描述--
Large gateways include a large number of endpoints which are often of different types. In some networks, we may often have to set-up connections between endpoints that are located within the same gateway. Examples of such connections may be:
大型网关包括大量端点，这些端点通常具有不同的类型。在某些网络中，我们可能经常需要在位于同一网关内的端点之间建立连接。此类连接的示例包括：
* Connecting a trunk line to a wiretap device,
* 将干线连接到窃听设备，
* Connecting a call to an Interactive Voice-Response unit,
* 将呼叫连接到交互式语音响应单元，
* Connecting a call to a Conferencing unit,
* 将呼叫连接到会议单元，
* Routing a call from on endpoint to another, something often described as a "hairpin" connection.
* 将呼叫从一个端点路由到另一个端点，这通常被称为“发夹”连接。
Local connections are much simpler to establish than network connections. In most cases, the connection will be established through some local interconnecting device, such as for example a TDM bus.
建立本地连接比建立网络连接简单得多。在大多数情况下，将通过一些本地互连设备建立连接，例如TDM总线。
When two endpoints are managed by the same gateway, it is possible to specify the connection in a single command that conveys the name of the two endpoints that will be connected. The command is essentially a "Create Connection" command which includes the name of the second endpoint in lieu of the "remote session description."
当两个端点由同一网关管理时，可以在单个命令中指定连接，该命令传递将要连接的两个端点的名称。该命令本质上是一个“创建连接”命令，其中包含第二个端点的名称，而不是“远程会话描述”
The media gateway control protocol has been designed to allow the implementation of redundant Call Agents, for enhanced network reliability. This means that there is no fixed binding between entities and hardware platforms or network interfaces.
媒体网关控制协议的设计允许实现冗余呼叫代理，以增强网络可靠性。这意味着实体和硬件平台或网络接口之间没有固定的绑定。
Reliability can be improved by the following precautions:
可通过以下预防措施提高可靠性：
* Entities such as endpoints or Call Agents are identified by their domain name, not their network addresses. Several addresses can be associated with a domain name. If a command or a response cannot be forwarded to one of the network addresses, implementations should retry the transmission using another address.
* 端点或呼叫代理等实体由其域名而不是网络地址标识。一个域名可以关联多个地址。如果命令或响应无法转发到其中一个网络地址，则应使用另一个地址重试传输。
* Entities may move to another platform. The association between a logical name (domain name) and the actual platform are kept in the domain name service. Call Agents and Gateways should keep track of the time-to-live of the record they read from the DNS. They should query the DNS to refresh the information if the time to live has expired.
* 实体可以移动到另一个平台。逻辑名称（域名）和实际平台之间的关联保留在域名服务中。呼叫代理和网关应该跟踪从DNS读取的记录的生存时间。如果生存时间已过，他们应该查询DNS以刷新信息。
In addition to the indirection provided by the use of domain names and the DNS, the concept of "notified entity" is central to reliability and fail-over in MGCP. The "notified entity" for an endpoint is the Call Agent currently controlling that endpoint. At any point in time, an endpoint has one, and only one, "notified entity" associated with it, and when the endpoint needs to send a command to the Call Agent, it MUST send the command to the current "notified entity" for which endpoint(s) the command pertains. Upon startup, the "notified entity" MUST be set to a provisioned value. Most commands sent by the Call Agent include the ability to explicitly name the "notified entity" through the use of a "NotifiedEntity" parameter. The "notified entity" will stay the same until either a new "NotifiedEntity" parameter is received or the endpoint reboots. If the "notified entity" for an endpoint is empty or has not been set explicitly, the "notified entity" will then default to the source address of the last connection handling command or notification request received for the endpoint. Auditing will thus not change the "notified entity."
除了使用域名和DNS提供的间接性之外，“通知实体”的概念对于MGCP的可靠性和故障转移至关重要。端点的“通知实体”是当前控制该端点的调用代理。在任何时间点，端点都有一个且只有一个与之关联的“通知实体”，并且当端点需要向呼叫代理发送命令时，它必须将该命令发送到该命令所属端点的当前“通知实体”。启动时，必须将“通知实体”设置为已设置的值。调用代理发送的大多数命令都能够通过使用“NotifiedEntity”参数显式命名“NotifiedEntity”。在收到新的“NotifiedEntity”参数或端点重新启动之前，“NotifiedEntity”将保持不变。如果端点的“通知实体”为空或未显式设置，“通知实体”将默认为该端点收到的最后一个连接处理命令或通知请求的源地址。因此，审计不会改变“通知实体”
The Call Agent can ask the gateway to collect digits dialed by the user. This facility is intended to be used with residential gateways to collect the numbers that a user dials; it may also be used with trunking gateways and access gateways alike, to collect the access codes, credit card numbers and other numbers requested by call control services.
呼叫代理可以要求网关收集用户拨打的数字。该设施旨在与住宅网关一起使用，以收集用户拨打的号码；它还可以与中继网关和接入网关一起使用，以收集接入代码、信用卡号码和呼叫控制服务请求的其他号码。
An alternative procedure is for the gateway to notify the Call Agent of the dialed digits, as soon as they are dialed. However, such a procedure generates a large number of interactions. It is preferable to accumulate the dialed numbers in a buffer, and to transmit them in a single message.
另一种方法是网关在拨号后立即通知呼叫代理所拨打的数字。然而，这样的过程会产生大量的交互。最好在缓冲区中累积拨号号码，并在单个消息中传输它们。
The problem with this accumulation approach, however, is that it is hard for the gateway to predict how many numbers it needs to accumulate before transmission. For example, using the phone on our desk, we can dial the following numbers:
然而，这种累积方法的问题是，网关很难预测在传输之前需要累积多少个数字。例如，使用桌上的电话，我们可以拨打以下号码：
_______________________________________________________
| 0 | Local operator |
| 00 | Long distance operator |
| xxxx | Local extension number |
| 8xxxxxxx | Local number |
| #xxxxxxx | Shortcut to local number at|
| | other corporate sites |
| *xx | Star services |
| 91xxxxxxxxxx | Long distance number |
| 9011 + up to 15 digits| International number |
|________________________|_____________________________|
_______________________________________________________
| 0 | Local operator |
| 00 | Long distance operator |
| xxxx | Local extension number |
| 8xxxxxxx | Local number |
| #xxxxxxx | Shortcut to local number at|
| | other corporate sites |
| *xx | Star services |
| 91xxxxxxxxxx | Long distance number |
| 9011 + up to 15 digits| International number |
|________________________|_____________________________|
The solution to this problem is to load the gateway with a digit map that correspond to the dial plan. This digit map is expressed using a syntax derived from the Unix system command, egrep. For example, the dial plan described above results in the following digit map:
此问题的解决方案是使用与拨号计划对应的数字映射加载网关。此数字映射使用从Unix系统命令egrep派生的语法表示。例如，上述拨号计划会产生以下数字映射：
(0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
（0T | 00T |[1-7]xxx | 8xxxxxx | xxxxxx |*xx | 91xxxxxxxxx | 9011x.T）
The formal syntax of the digit map is described by the DigitMap rule in the formal syntax description of the protocol (section 3.4). A Digit-Map, according to this syntax, is defined either by a "string" or by a list of strings. Each string in the list is an alternative numbering scheme, specified either as a set of digits or timers, or as regular expression. A gateway that detects digits, letters or timers will:
数字映射的形式语法由协议的形式语法描述中的DigitMap规则描述（第3.4节）。根据这种语法，数字映射由“字符串”或字符串列表定义。列表中的每个字符串都是可选的编号方案，指定为一组数字或计时器，或者指定为正则表达式。检测数字、字母或计时器的网关将：
1) Add the event parameter code as a token to the end of an internal state variable called the "current dial string"
1) 将事件参数代码作为令牌添加到名为“当前拨号字符串”的内部状态变量的末尾
2) Apply the current dial string to the digit map table, attempting a match to each regular expression in the Digit Map in lexical order
2) 将当前拨号字符串应用于数字映射表，尝试按词汇顺序匹配数字映射中的每个正则表达式
3) If the result is under-qualified (partially matches at least one entry in the digit map), do nothing further.
3) 如果结果不合格（部分匹配数字映射中的至少一个条目），则不做进一步操作。
If the result matches, or is over-qualified (i.e. no further digits could possibly produce a match), send the current digit string to the Call Agent. A match, in this specification, can be either a "perfect match," exactly matching one of the specified alternatives, or an impossible match, which occur when the dial string does not match any of the alternative. Unexpected timers, for example, can cause "impossible matches." Both perfect matches and impossible matches trigger notification of the accumulated digits.
如果结果匹配，或是过度合格（即没有其他数字可能产生匹配），则将当前数字字符串发送给呼叫代理。在本规范中，匹配可以是“完美匹配”，与指定的备选方案中的一个完全匹配，也可以是不可能的匹配，当拨号字符串与任何备选方案不匹配时会出现这种情况。例如，意外计时器可能导致“不可能匹配”。完全匹配和不可能匹配都会触发累积数字的通知。
Digit maps are provided to the gateway by the Call Agent, whenever the Call Agent instructs the gateway to listen for digits.
每当呼叫代理指示网关监听数字时，呼叫代理就会向网关提供数字映射。
The concept of events and signals is central to MGCP. A Call Agent may ask to be notified about certain events occurring in an endpoint, e.g. off-hook events, and a call agent may request certain signals to be applied to an endpoint, e.g. dial-tone.
事件和信号的概念是MGCP的核心。呼叫代理可以请求被通知端点中发生的某些事件，例如摘机事件，并且呼叫代理可以请求向端点应用某些信号，例如拨号音。
Events and signals are grouped in packages within which they share the same namespace which we will refer to as event names in the following. Packages are groupings of the events and signals supported by a particular type of endpoint. For instance, one package may support a certain group of events and signals for analog access lines, and another package may support another group of events and signals for video lines. One or more packages may exist for a given endpoint-type.
事件和信号被分组在包中，在包中它们共享相同的名称空间，我们将在下文中称之为事件名称。包是特定类型端点支持的事件和信号的分组。例如，一个包可以支持用于模拟接入线的某一组事件和信号，而另一个包可以支持用于视频线的另一组事件和信号。给定端点类型可能存在一个或多个包。
Event names are case insensitive and are composed of two logical parts, a package name and an event name. Both names are strings of letters, hyphens and digits, with the restriction that hyphens shall never be the first or last characters in a name. Package or event names are not case sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered equal.
事件名称不区分大小写，由两个逻辑部分组成，一个包名和一个事件名。这两个名称都是由字母、连字符和数字组成的字符串，但限制连字符不能是名称中的第一个或最后一个字符。包或事件名称不区分大小写-诸如“hu”、“hu”、“hu”或“hu”等值应视为相等。
Examples of package names are "D" (DTMF), "M" (MF), "T" (Trunk) or "L" (Line). Examples of event names can be "hu" (off hook or "hang-up" transition), "hf" (flash hook) or "0" (the digit zero).
包名称的示例有“D”（DTMF）、“M”（MF）、“T”（主干）或“L”（行）。事件名称的示例可以是“hu”（摘机或“挂起”转换）、“hf”（flashhook）或“0”（数字零）。
In textual representations, the package name, when present, is separated from the event name by a slash ("/"). The package name is in fact optional. Each endpoint-type has a default package associated with it, and if the package name is excluded from the event name, the default package name for that endpoint-type is assumed. For example, for an analog access line, the following two event names are equal:
在文本表示中，包名（如果存在）与事件名之间用斜杠（“/”）分隔。包名称实际上是可选的。每个端点类型都有一个与之关联的默认包，如果包名称从事件名称中排除，则假定该端点类型的默认包名称。例如，对于模拟访问线，以下两个事件名称相等：
l/dl dial-tone in the line package for an analog access line.
模拟接入线路的线路包中的l/dl拨号音。
dl dial-tone in the line package (default) for an analog access line.
模拟接入线路的线路包（默认）中的dl拨号音。
This document defines a basic set of package names and event names. Additional package names and event names can be registered with the IANA. A package definition shall define the name of the package, and the definition of each event belonging to the package. The event definition shall include the precise name of the event (i.e., the code used in MGCP), a plain text definition of the event, and, when appropriate, the precise definition of the corresponding signals, for example the exact frequencies of audio signal such as dial tones or DTMF tones.
本文档定义了一组基本的包名称和事件名称。可以向IANA注册其他包名和事件名。包定义应定义包的名称，以及属于包的每个事件的定义。事件定义应包括事件的准确名称（即MGCP中使用的代码）、事件的纯文本定义，以及相应信号的准确定义（如拨号音或DTMF音等音频信号的准确频率）。
In addition, implementers can gain experience by using experimental packages. The names of experimental packages must start with the two characters "x-"; the IANA shall not register package names that start with these characters.
此外，实现者可以通过使用实验包获得经验。实验包的名称必须以两个字符“x-”开头；IANA不得注册以这些字符开头的程序包名称。
Digits, or letters, are supported in many packages, notably "DTMF" and "MF". Digits and letters are defined by the rules "Digit" and "Letter" in the definition of digit maps. This definition refers to the digits (0 to 9), to the asterisk or star ("*") and orthotrope, number or pound sign ("#"), and to the letters "A", "B", "C" and "D", as well as the timer indication "T". These letters can be combined in "digit string" that represent the keys that a user punched on a dial. In addition, the letter "X" can be used to represent all digits, and the sign "$" can be used in wildcard notations. The need to easily express the digit strings has a consequence on the form of event names:
许多软件包都支持数字或字母，尤其是“DTMF”和“MF”。数字和字母由数字地图定义中的“数字”和“字母”规则定义。该定义指数字（0至9）、星号或星号（*）和数字、数字或磅号（#））、字母“A”、“B”、“C”和“D”，以及计时器指示“T”。这些字母可以组合成“数字串”，代表用户在拨号盘上打出的键。此外，字母“X”可用于表示所有数字，符号“$”可用于通配符符号。需要方便地表示数字字符串对事件名称的形式有影响：
An event name that does not denote a digit should always contain at least one character that is neither a digit, nor one of the letters A, B, C, D, T or X. (Such names should not contain the special signs "*", "#", "/" or "$".)
不表示数字的事件名称应始终包含至少一个既不是数字也不是字母a、B、C、D、T或X之一的字符。（此类名称不应包含特殊符号“*”、“#”、“/”或“$”）
A Call Agent may often have to ask a gateway to detect a group of events. Two conventions can be used to denote such groups:
呼叫代理通常必须请求网关检测一组事件。可使用两种约定来表示此类组：
* The wildcard convention can be used to detect any event belonging to a package, or a given event in many packages, or event any event in any package supported by the gateway.
* 通配符约定可用于检测属于包的任何事件，或多个包中的给定事件，或网关支持的任何包中的任何事件。
* The regular expression Range notation can be used to detect a range of digits.
* 正则表达式范围表示法可用于检测数字范围。
The star sign (*) can be used as a wildcard instead of a package name, and the keyword "all" can be used as a wildcard instead of an event name:
星号（*）可以用作通配符而不是包名称，关键字“all”可以用作通配符而不是事件名称：
A name such as "foo/all" denotes all events in package "foo" A name such as "*/bar" denotes the event "bar" in any package supported by the gateway The names "*" or "*/all" denote all events supported by the gate way.
“foo/all”等名称表示包“foo”中的所有事件“*/bar”等名称表示网关支持的任何包中的事件“bar”“*”或“*/all”等名称表示网关支持的所有事件。
The call agent can ask a gateway to detect a set of digits or letters either by individually describing those letters, or by using the "range" notation defined in the syntax of digit strings. For example, the call agent can:
呼叫代理可以要求网关检测一组数字或字母，方法是单独描述这些字母，或使用数字字符串语法中定义的“范围”符号。例如，呼叫代理可以：
Use the letter "x" to denote "any letter or digit." Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound sign.
使用字母“x”表示“任何字母或数字”。使用符号“[0-9#]”表示数字0至9和磅符号。
In some cases, Call Agents will request the gateway to generate or detect events on connections rather than on the end point itself. For example, gateways may be asked to provide a ringback tone on a connection. When an event shall be applied on a connection, the name of the connection is added to the name of the event, using an "at" sign (@) as a delimiter, as in:
在某些情况下，呼叫代理将请求网关在连接上而不是在端点本身上生成或检测事件。例如，可能会要求网关在连接上提供回铃音。当事件应用于连接时，连接的名称将添加到事件名称中，使用“at”符号（@）作为分隔符，如：
G/rt@0A3F58
G/rt@0A3F58
The wildcard character "*" (star) can be used to denote "all connections". When this convention is used, the gateway will generate or detect the event on all the connections that are connected to the endpoint. An example of this convention could be:
通配符“*”（星形）可用于表示“所有连接”。使用此约定时，网关将在连接到端点的所有连接上生成或检测事件。这项公约的一个例子可以是：
R/qa@*
R/qa@*
The wildcard character "$" can be used to denote "the current connection." It should only be used by the call agent, when the event notification request is "encapsulated" within a command creation or modification command. When this convention is used, the gateway will generate or detect the event on the connection that is currently being created or modified. An example of this convention is:
通配符“$”可用于表示“当前连接”。只有当事件通知请求“封装”在命令创建或修改命令中时，才应由调用代理使用。使用此约定时，网关将生成或检测当前正在创建或修改的连接上的事件。这项公约的一个例子是：
G/rt@$
G/rt@$
The connection id, or a wildcard replacement, can be used in conjunction with the "all packages" and "all events" conventions. For example, the notation:
连接id或通配符替换可以与“所有包”和“所有事件”约定结合使用。例如，符号：
*/all@*
*/all@*
can be used to designate all events on all connections.
可用于指定所有连接上的所有事件。
Events and signals are described in packages. The package description must provide, for each events, the following informations:
事件和信号在包中描述。对于每个事件，包说明必须提供以下信息：
* The description of the event and its purpose, which should mean the actual signal that is generated by the client (i.e., xx ms FSK tone) as well as the resulting user observed result (i.e., MW light on/off).
* 事件描述及其目的，应指客户端产生的实际信号（即xx ms FSK音调）以及由此产生的用户观察结果（即MW灯开/关）。
* The detailed characteristics of the event, such as for example frequencies and amplitude of audio signals, modulations and repetitions,
* 事件的详细特征，例如音频信号的频率和振幅、调制和重复，
* The typical and maximum duration of the event.
* 事件的典型和最长持续时间。
Signals are divided into different types depending on their behavior:
信号根据其行为分为不同类型：
* On/off (OO) Once applied, these signals last forever until they are turned off. This may happen either as the result of an event or a new SignalRequests (see later).
* 开/关（OO）一旦应用，这些信号将一直持续到关闭为止。这可能是一个事件的结果，也可能是一个新的信号请求（见下文）。
* Time-out (TO) Once applied, these signals last until they are either turned off (by an event or SignalRequests) or a signal specific period of time has elapsed. Depending on package specifications, a signal that times out may generate an "operation complete" event.
* 超时（TO）一旦应用，这些信号将一直持续到它们被关闭（通过事件或信号请求）或经过特定的信号时间段为止。根据包装规格，超时的信号可能会产生“操作完成”事件。
* Brief (BR) The duration of these signals is so short, that they stop on their own. If an event occurs the signal will not stop, however if a new SignalRequests is applied, the signal will stop. (Note: this point should be debated. One could make a case that events such as strings of DTMF digits should in fact be allowed to complete.)
* 这些信号的持续时间很短，它们会自行停止。如果发生事件，信号将不会停止，但是如果应用了新的信号请求，信号将停止。（注：这一点值得商榷。人们可以提出一个理由，即事实上应该允许DTMF数字串之类的事件完成。）
TO signals are normally used to alert the endpoints' users, to signal them that they are expected to perform a specific action, such as hang down the phone (ringing). Transmission of these signals should typically be interrupted as soon as the first of the requested events has been produced.
TO信号通常用于向端点的用户发出警报，向他们发出信号，表示希望他们执行特定操作，例如挂断电话（铃声）。这些信号的传输通常应在第一个请求事件产生后立即中断。
Package descriptions should describe, for all signals, their type (OO, TO, BR). They should also describe the maximum duration of the TO signals.
对于所有信号，包描述应描述其类型（OO、TO、BR）。它们还应描述TO信号的最大持续时间。
The Call Agent uses the MGCP to provision the gateways with the description of connection parameters such as IP addresses, UDP port and RTP profiles. These descriptions will follow the conventions delineated in the Session Description Protocol which is now an IETF proposed standard, documented in RFC 2327.
呼叫代理使用MGCP为网关提供连接参数的描述，如IP地址、UDP端口和RTP配置文件。这些描述将遵循会话描述协议中描述的约定，会话描述协议现在是IETF提议的标准，记录在RFC 2327中。
SDP allows for description of multimedia conferences. This version limits SDP usage to the setting of audio circuits and data access circuits. The initial session descriptions contain the description of exactly one media, of type "audio" for audio connections, "nas" for data access.
SDP允许描述多媒体会议。此版本将SDP的使用限制为音频电路和数据访问电路的设置。初始会话描述仅包含一种媒体的描述，音频连接类型为“音频”，数据访问类型为“nas”。
This section describes the commands of the MGCP. The service consists of connection handling and endpoint handling commands. There are nine commands in the protocol:
本节介绍MGCP的命令。该服务由连接处理和端点处理命令组成。协议中有九个命令：
* The Call Agent can issue an EndpointConfiguration command to a gateway, instructing the gateway about the coding characteristics expected by the "line-side" of the endpoint.
* 呼叫代理可以向网关发出EndpointConfiguration命令，指示网关端点的“线路端”所期望的编码特性。
* The Call Agent can issue a NotificationRequest command to a gateway, instructing the gateway to watch for specific events such as hook actions or DTMF tones on a specified endpoint .
* 呼叫代理可以向网关发出NotificationRequest命令，指示网关监视指定端点上的特定事件，如挂钩动作或DTMF音。
* The gateway will then use the Notify command to inform the Call Agent when the requested events occur.
* 然后，网关将使用Notify命令在请求的事件发生时通知呼叫代理。
* The Call Agent can use the CreateConnection command to create a connection that terminates in an "endpoint" inside the gateway.
* 调用代理可以使用CreateConnection命令创建一个连接，该连接终止于网关内的“端点”。
* The Call Agent can use the ModifyConnection command to change the parameters associated to a previously established connection.
* 呼叫代理可以使用ModifyConnection命令更改与先前建立的连接关联的参数。
* The Call Agent can use the DeleteConnection command to delete an existing connection. The DeleteConnection command may also be used by a gateway to indicate that a connection can no longer be sustained.
* 呼叫代理可以使用DeleteConnection命令删除现有连接。网关也可以使用DeleteConnection命令来指示连接无法继续。
* The Call Agent can use the AuditEndpoint and AuditConnection commands to audit the status of an "endpoint" and any connections associated with it. Network management beyond the capabilities provided by these commands are generally desirable, e.g. information about the status of the gateway. Such capabilities are expected to be supported by the use of the Simple Network Management Protocol (SNMP) and definition of a MIB which is outside the scope of this specification.
* 调用代理可以使用AuditEndpoint和AuditConnection命令来审核“端点”及其关联的任何连接的状态。通常，除了这些命令提供的功能外，还需要网络管理，例如有关网关状态的信息。通过使用简单网络管理协议（SNMP）和定义本规范范围之外的MIB，这些功能有望得到支持。
* The Gateway can use the RestartInProgress command to notify the Call Agent that the gateway, or a group of endpoints managed by the gateway, is being taken out of service or is being placed back in service.
* 网关可以使用RestartInProgress命令通知呼叫代理网关或由网关管理的一组端点正在停止服务或重新投入服务。
These services allow a controller (normally, the Call Agent) to instruct a gateway on the creation of connections that terminate in an "endpoint" attached to the gateway, and to be informed about events occurring at the endpoint. An endpoint may be for example:
这些服务允许控制器（通常是呼叫代理）指示网关创建以连接到网关的“端点”终止的连接，并通知在端点发生的事件。端点可以是例如：
* A specific trunk circuit, within a trunk group terminating in a gateway,
* 在网关中终止的中继组内的特定中继电路，
* A specific announcement handled by an announcement server.
* 由公告服务器处理的特定公告。
Connections are grouped into "calls". Several connections, that may or may not belong to the same call, can terminate in the same endpoint . Each connection is qualified by a "mode" parameter, which can be set to "send only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), "conference" (confrnce), "data", "inactive" (inactive), "loopback", "continuity test" (conttest), "network loop back" (netwloop) or "network continuity test" (netwtest).
连接被分组为“调用”。可能属于或不属于同一调用的多个连接可以在同一端点终止。每个连接都由一个“mode”参数限定，该参数可以设置为“仅发送”（仅发送）、“仅接收”（仅接收）、“发送/接收”（发送/接收）（确认）、“会议”（确认）、“数据”、“非活动”（非活动）、“环回”、“连续性测试”（conttest）、“网络环回”（netwloop）或“网络连续性测试”（netwtest）。
The handling of the audio signals received on these connections is determined by the mode parameters:
通过这些连接接收的音频信号的处理由模式参数决定：
* Audio signals received in data packets through connections in "receive", "conference" or "send/receive" mode are mixed and sent to the endpoint.
* 在“接收”、“会议”或“发送/接收”模式下通过连接在数据包中接收的音频信号被混合并发送到端点。
* Audio signals originating from the endpoint are transmitted over all the connections whose mode is "send", "conference" or "send/receive."
* 来自端点的音频信号通过模式为“发送”、“会议”或“发送/接收”的所有连接进行传输
* In addition to being sent to the endpoint, audio signals received in data packets through connections in "conference" mode are replicated to all the other connections whose mode is "conference."
* 除了发送到端点之外，通过“会议”模式下的连接在数据包中接收的音频信号被复制到模式为“会议”的所有其他连接
The "loopback" and "continuity test" modes are used during maintenance and continuity test operations. There are two flavors of continuity test, one specified by ITU and one used in the US. In the first case, the test is a loopback test. The originating switch will send a tone (the go tone) on the bearer circuit and expect the terminating switch to loopback the circuit. If the originating switch sees the same tone returned (the return tone), the COT has passed. If not, the COT has failed. In the second case, the go and return tones are different. The originating switch sends a certain go tone. The terminating switch detects the go tone, it asserts a different return tone in the backwards direction. When the originating switch detects the return tone, the COT is passed. If the originating switch never detects the return tone, the COT has failed.
“环回”和“连续性测试”模式在维护和连续性测试操作期间使用。有两种类型的连续性测试，一种由ITU指定，另一种在美国使用。在第一种情况下，测试是环回测试。始发交换机将在承载电路上发送一个音调（go音调），并期望终端交换机回送该电路。如果始发交换机看到相同的返回音（返回音），则COT已通过。如果没有，则COT出现故障。在第二种情况下，go和return音调不同。始发开关发送特定的go音调。终端开关检测到go音调，它在向后方向上断言不同的返回音调。当始发开关检测到回音时，COT通过。如果始发开关从未检测到回音，则COT出现故障。
If the mode is set to "loopback", the gateway is expected to return the incoming signal from the endpoint back into that same endpoint. This procedure will be used, typically, for testing the continuity of trunk circuits according to the ITU specifications.
如果模式设置为“环回”，则网关应将输入信号从端点返回到同一端点。本程序通常用于根据ITU规范测试中继电路的连续性。
If the mode is set to "continuity test", the gateway is informed that the other end of the circuit has initiated a continuity test procedure according to the GR specification. The gateway will place the circuit in the transponder mode required for dual-tone continuity tests.
如果模式设置为“导通性测试”，则网关将被告知电路的另一端已根据GR规范启动导通性测试程序。网关将使电路处于双音连续性测试所需的收发器模式。
If the mode is set to "network loopback", the audio signals received from the connection will be echoed back on the same connection.
如果模式设置为“网络环回”，则从连接接收的音频信号将在同一连接上回响。
If the mode is set to "network continuity test", the gateway will process the packets received from the connection according to the transponder mode required for dual-tone continuity test, and send the processed signal back on the connection.
如果模式设置为“网络连续性测试”，网关将根据双音连续性测试所需的应答器模式处理从连接接收的数据包，并将处理后的信号发送回连接。
The EndpointConfiguration commands are used to specify the encoding of the signals that will be received by the endpoint. For example, in certain international telephony configurations, some calls will carry mu-law encoded audio signals, while other will use A-law. The Call Agent will use the EndpointConfiguration command to pass this information to the gateway. The configuration may vary on a call by call basis, but can also be used in the absence of any connection.
EndpointConfiguration命令用于指定端点将接收的信号的编码。例如，在某些国际电话配置中，一些呼叫将携带mu-law编码的音频信号，而另一些呼叫将使用A-law。呼叫代理将使用EndpointConfiguration命令将此信息传递给网关。配置可能会因呼叫而异，但也可以在没有任何连接的情况下使用。
ReturnCode <-- EndpointConfiguration( EndpointId, BearerInformation)
ReturnCode<--EndpointConfiguration（EndpointId，BearerInformation）
EndpointId is the name for the endpoint in the gateway where EndpointConfiguration executes, as defined in section 2.1.1. The "any of" wildcard convention shall not be used. If the "all of" wildcard convention is used, the command applies to all the endpoint whose name matches the wildcard.
EndpointId是执行EndpointConfiguration的网关中端点的名称，如第2.1.1节所定义。不得使用“任意”通配符约定。如果使用“全部”通配符约定，则该命令将应用于名称与通配符匹配的所有端点。
BearerInformation is a parameter defining the coding of the data received from the line side. These information is encoded as a list of sub-parameters. The only sub-parameter defined in this version of the specification is the encoding method, whose values can be set to "A-law" and "mu-law".
承载信息是定义从线路侧接收的数据编码的参数。这些信息被编码为子参数列表。本规范版本中定义的唯一子参数是编码方法，其值可以设置为“A-law”和“mu-law”。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
The NotificationRequest commands are used to request the gateway to send notifications upon the occurrence of specified events in an endpoint. For example, a notification may be requested for when a gateway detects that an endpoint is receiving tones associated with fax communication. The entity receiving this notification may decide to use a different type of encoding method in the connections bound to this endpoint.
NotificationRequest命令用于请求网关在端点中发生指定事件时发送通知。例如，当网关检测到端点正在接收与传真通信相关联的音调时，可以请求通知。接收此通知的实体可能决定在绑定到此端点的连接中使用不同类型的编码方法。
ReturnCode
<-- NotificationRequest( EndpointId,
[NotifiedEntity,]
[RequestedEvents,]
RequestIdentifier,
[DigitMap,]
[SignalRequests,]
[QuarantineHandling,]
[DetectEvents,]
[encapsulated EndpointConfiguration])
ReturnCode
<-- NotificationRequest( EndpointId,
[NotifiedEntity,]
[RequestedEvents,]
RequestIdentifier,
[DigitMap,]
[SignalRequests,]
[QuarantineHandling,]
[DetectEvents,]
[encapsulated EndpointConfiguration])
EndpointId is the name for the endpoint in the gateway where NotificationRequest executes, as defined in section 2.1.1.
EndpointId是网关中执行NotificationRequest的端点的名称，如第2.1.1节所定义。
NotifiedEntity is an optional parameter that specifies where the notifications should be sent. When this parameter is absent, the notifications should be sent to the originator of the NotificationRequest.
NotifiedEntity是一个可选参数，用于指定通知应发送到的位置。如果缺少此参数，则应将通知发送给NotificationRequest的发起人。
RequestIdentifier is used to correlate this request with the notifications that it triggers.
RequestIdentifier用于将此请求与其触发的通知相关联。
RequestedEvents is a list of events that the gateway is requested to detect and report. Such events include, for example, fax tones, continuity tones, or on-hook transition. To each event is associated an action, which can be:
RequestedEvents是请求网关检测和报告的事件列表。例如，此类事件包括传真音调、连续性音调或挂机转换。每个事件都关联一个操作，该操作可以是：
* Notify the event immediately, together with the accumulated list of observed events,
* 立即通知事件以及观察到的事件的累积列表，
* Swap audio,
* 交换音频，
* Accumulate the event in an event buffer, but don't notify yet,
* 在事件缓冲区中累积事件，但不通知，
* Accumulate according to Digit Map,
* 根据数字地图进行累加，
* Keep Signal(s) active,
* 保持信号处于激活状态，
* process the Embedded Notification Request,
* 处理嵌入的通知请求，
* Ignore the event.
* 忽略事件。
Some actions can be combined. In particular:
有些行动可以结合起来。特别地：
* The "swap audio" action can be combined with "Notify", "Accumulate" and "Ignore."
* “交换音频”操作可以与“通知”、“累积”和“忽略”组合使用
* The "keep signal active" action can be combined with "Notify", "Accumulate", "Accumulate according to Digit Map", "Ignore" and "Embedded Notification Request."
* “保持信号激活”操作可与“通知”、“累积”、“根据数字映射累积”、“忽略”和“嵌入式通知请求”组合
* The "Embedded Notification Request" can be combined with "Accumulate" and with "Keep signals active." It can also be combined with Notify, if the gateway is allowed to issue several Notify commands in response to a single Notification request.
* “嵌入式通知请求”可以与“累积”和“保持信号处于活动状态”相结合。如果允许网关针对单个通知请求发出多个Notify命令，则还可以与Notify相结合。
In addition to the requestedEvents parameter specified in the command, some profiles of MGCP have introduced the concept of "persistent events." According to such profiles, the persistent event list is configured in the endpoint, by means outside the scope of MGCP. The basic MGCP specification does not specify any persistent event.
除了命令中指定的requestedEvents参数外，MGCP的一些配置文件还引入了“持久事件”的概念。根据这些配置文件，持久事件列表在端点中通过MGCP范围之外的方式进行配置。基本MGCP规范没有指定任何持久性事件。
If a persistent event is not included in the list of RequestedEvents, and the event occurs, the event will be detected anyway, and processed like all other events, as if the persistent event had been requested with a Notify action. Thus, informally, persistent events can be viewed as always being implicitly included in the list of RequestedEvents with an action to Notify, although no glare detection, etc., will be performed.
如果RequestedEvents列表中未包含持久性事件，并且该事件发生，则该事件仍将被检测到，并与所有其他事件一样进行处理，就像持久性事件是通过Notify操作请求的一样。因此，非正式地说，持久性事件可以被视为总是隐式地包括在请求事件列表中，并具有要通知的操作，尽管不会执行眩光检测等。
Non-persistent events are those events explicitly included in the RequestedEvents list. The (possibly empty) list of requested events completely replaces the previous list of requested events. In addition to the persistent events, only the events specified in the requested events list will be detected by the endpoint. If a persistent event is included in the RequestedEvents list, the action specified will then replace the default action associated with the event for the life of the RequestedEvents list, after which the default action is restored. For example, if "Ignore off-hook" was specified, and a new request without any off-hook instructions were received, the default "Notify off-hook" operation then would be restored. A given event MUST NOT appear more than once in a RequestedEvents.
非持久性事件是那些明确包含在RequestedEvents列表中的事件。请求的事件列表（可能为空）完全替换先前请求的事件列表。除了持久事件外，端点将仅检测请求的事件列表中指定的事件。如果RequestedEvents列表中包含持久性事件，则指定的操作将在RequestedEvents列表的生命周期内替换与该事件关联的默认操作，然后恢复默认操作。例如，如果指定了“忽略摘机”，并且接收到没有任何摘机指令的新请求，那么将恢复默认的“通知摘机”操作。给定事件在RequestedEvents中不得出现多次。
The gateway will detect the union of the persistent events and the requested events. If an event is not specified in either list, it will be ignored.
网关将检测持久事件和请求事件的联合。如果两个列表中均未指定事件，则将忽略该事件。
The Swap Audio action can be used when a gateway handles more than one active connection on an endpoint. This will be the case for three-way calling, call waiting, and possibly other feature scenarios. In order to avoid the round-trip to the Call Agent when just changing which connection is attached to the audio functions of the endpoint, the NotificationRequest can map an event (usually hook flash, but could be some other event) to a local function swap audio, which selects the "next" connection in a round robin fashion. If there is only one connection, this action is effectively a no-op.
当网关处理端点上的多个活动连接时，可以使用交换音频操作。三路呼叫、呼叫等待以及其他可能的功能场景都是如此。为了避免在仅更改连接到端点的音频函数时调用代理的往返，NotificationRequest可以将事件（通常是挂钩闪烁，但可能是其他事件）映射到本地函数交换音频，以循环方式选择“下一个”连接。如果只有一个连接，则此操作实际上是禁止操作的。
If signal(s) are desired to start when an event being looked for occurs, the "Embedded NotificationRequest" action can be used. The embedded NotificationRequest may include a new list of RequestedEvents, SignalRequests and a new digit map as well. The semantics of the embedded NotificationRequest is as if a new NotificationRequest was just received with the same NotifiedEntity, and RequestIdentifier. When the "Embedded NotificationRequest" is activated, the "current dial string" will be cleared; the list of observed events and the quarantine buffer will be unaffected.
如果需要在正在查找的事件发生时启动信号，则可以使用“嵌入式NotificationRequest”操作。嵌入式NotificationRequest还可以包括新的RequestedEvents列表、SignalRequests和新的数字映射。嵌入式NotificationRequest的语义就好像刚收到一个新的NotificationRequest，它具有相同的NotificationIdentity和RequestIdentifier。当“嵌入式通知请求”被激活时，“当前拨号串”将被清除；观察到的事件列表和隔离缓冲区将不受影响。
MGCP implementations shall be able to support at least one level of embedding. An embedded NotificationRequest that respects this limitation shall not contain another Embedded NotificationRequest.
MGCP实现应能够支持至少一个嵌入级别。遵守此限制的嵌入式NotificationRequest不得包含其他嵌入式NotificationRequest。
DigitMap is an optional parameter that allows the Call Agent to provision the gateways with a digit map according to which digits will be accumulated. If this optional parameter is absent, the previously defined value is retained. This parameter must be defined, either explicitly or through a previous command, if the RequestedEvent parameters contain an request to "accumulate according to the digit map." The collection of these digits will result in a digit string. The digit string is initialized to a null string upon reception of the NotificationRequest, so that a subsequent notification only returns the digits that were collected after this request. Digits that were accumulated according to the digit map are reported as any other accumulated event, in the order in which they occur. It is therefore possible that other events be accumulated may be found in between the list of digits.
DigitMap是一个可选参数，它允许呼叫代理为网关提供一个数字映射，根据该映射将累积哪些数字。如果缺少此可选参数，则保留先前定义的值。如果RequestedEvent参数包含“根据数字映射累加”的请求，则必须显式或通过上一个命令定义此参数。这些数字的集合将生成数字字符串。收到NotificationRequest后，数字字符串被初始化为空字符串，因此后续通知仅返回此请求之后收集的数字。根据数字映射累积的数字按其发生顺序报告为任何其他累积事件。因此，可能会在数字列表之间发现其他累积事件。
SignalRequests is a parameter that contains the set of signals that the gateway is asked to apply to the endpoint, such as, for example ringing, or continuity tones. Signals are identified by their name, which is an event name, and may be qualified by parameters.
SignalRequests是一个参数，包含要求网关应用于端点的信号集，例如铃声或连续性铃声。信号通过其名称（事件名称）进行标识，并可通过参数进行限定。
The action triggered by the SignalRequests is synchronized with the collection of events specified in the RequestedEvents parameter. For example, if the NotificationRequest mandates "ringing" and the event request ask to look for an "off-hook" event, the ringing shall stop as soon as the gateway detect an off hook event. The formal definition is that the generation of all "Time Out" signals shall stop as soon as one of the requested events is detected, unless the "Keep signals active" action is associated to the specified event.
由SignalRequests触发的操作与RequestedEvents参数中指定的事件集合同步。例如，如果NotificationRequest强制要求“振铃”，而事件请求要求查找“摘机”事件，则只要网关检测到摘机事件，振铃就会停止。正式定义是，所有“超时”信号的生成应在检测到一个请求的事件时立即停止，除非“保持信号活动”动作与指定事件相关。
The specific definition of actions that are requested via these SignalRequests, such as the duration of and frequency of a DTMF digit, is out side the scope of MGCP. This definition may vary from location to location and hence from gateway to gateway.
通过这些信号请求请求的操作的具体定义，如DTMF数字的持续时间和频率，超出了MGCP的范围。此定义可能因位置而异，因此也可能因网关而异。
The RequestedEvents and SignalRequests refer to the same event definitions. In one case, the gateway is asked to detect the occurrence of the event, and in the other case it is asked to generate it. The specific events and signals that a given endpoint can detect or perform are determined by the list of event packages that are supported by that end point. Each package specifies a list of events and actions that can be detected or performed. A gateway that is requested to detect or perform an event belonging to a package that is not supported by the specified endpoint shall return an error. When the event name is not qualified by a package name, the default package name for the end point is assumed. If the event name is not registered in this default package, the gateway shall return an error.
RequestedEvents和SignalRequests引用相同的事件定义。在一种情况下，要求网关检测事件的发生，在另一种情况下，要求网关生成事件。给定端点可以检测或执行的特定事件和信号由该端点支持的事件包列表确定。每个包指定一个可以检测或执行的事件和操作的列表。被请求检测或执行属于指定端点不支持的包的事件的网关应返回错误。如果事件名称未由包名称限定，则假定端点的默认包名称。如果此默认包中未注册事件名称，网关将返回错误。
The Call Agent can send a NotificationRequest whose requested signal list is empty. It will do so for example when tone generation should stop.
呼叫代理可以发送请求信号列表为空的NotificationRequest。例如，当音调生成停止时，它会这样做。
The optional QuarantineHandling parameter specifies the handling of "quarantine" events, i.e. events that have been detected by the gateway before the arrival of this NotificationRequest command, but have not yet been notified to the Call Agent. The parameter provides a set of handling options:
可选的QuarantineHandling参数指定“隔离”事件的处理，即网关在此NotificationRequest命令到达之前已检测到但尚未通知呼叫代理的事件。该参数提供一组处理选项：
* whether the quarantined events should be processed or discarded (the default is to process them.)
* 应处理还是丢弃隔离事件（默认情况下是处理它们。）
* whether the gateway is expected to generate at most one notification (step by step), or multiple notifications (loop), in response to this request (the default is exactly one.)
* 网关应最多生成一个通知（逐步）还是多个通知（循环），以响应此请求（默认值正好是一个）
When the parameter is absent, the default value is assumed.
如果缺少该参数，则假定默认值。
We should note that the quarantine-handling parameter also governs the handling of events that were detected but not yet notified when the command is received.
我们应该注意，隔离处理参数还控制在接收命令时检测到但尚未通知的事件的处理。
DetectEvents is an optional parameter that specifies a list of events that the gateway is requested to detect during the quarantine period. When this parameter is absent, the events that should be detected in the quarantine period are those listed in the last received DetectEvents list. In addition, the gateway should also detect the events specified in the request list, including those for which the "ignore" action is specified.
DetecteEvents是一个可选参数，用于指定隔离期间请求网关检测的事件列表。如果不存在此参数，则应在隔离期间检测到的事件是上次接收到的DetectEvents列表中列出的事件。此外，网关还应检测请求列表中指定的事件，包括指定“忽略”操作的事件。
Some events and signals, such as the in-line ringback or the quality alert, are performed or detected on connections terminating in the end point rather than on the endpoint itself. The structure of the event names allow the Call Agent to specify the connection (or connections) on which the events should be performed or detected.
某些事件和信号（如在线回铃或质量警报）在端点终止的连接上执行或检测，而不是在端点本身上。事件名称的结构允许调用代理指定应在其上执行或检测事件的连接。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the NotificationRequest, with the exception of the EndpointId, which is not replicated.
该命令可能携带一个封装的EndpointConfiguration命令，该命令将应用于同一端点。当此命令存在时，EndpointConfiguration命令的参数将插入NotificationRequest的正常参数之后，EndpointId除外，它不会被复制。
The encapsulated EndpointConfiguration command shares the fate of the NotificationRequest command. If the NotificationRequest is rejected, the EndpointConfiguration is not executed.
封装的EndpointConfiguration命令共享NotificationRequest命令的命运。如果NotificationRequest被拒绝，则不会执行EndpointConfiguration。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary. .NH 3 Notifications
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。NH 3通知
Notifications are sent via the Notify command and are sent by the gateway when the observed events occur.
通知通过Notify命令发送，并在观察到的事件发生时由网关发送。
ReturnCode <-- Notify( EndpointId, [NotifiedEntity,] RequestIdentifier, ObservedEvents)
ReturnCode<--Notify（EndpointId、[NotifiedEntity、]RequestIdentifier、observeEvents）
EndpointId is the name for the endpoint in the gateway which is issuing the Notify command, as defined in section 2.1.1. The identifier should be a fully qualified endpoint identifier, including the domain name of the gateway. The local part of the name shall not use the wildcard convention.
EndpointId是网关中发出Notify命令的端点的名称，如第2.1.1节所定义。标识符应该是完全限定的端点标识符，包括网关的域名。名称的本地部分不得使用通配符约定。
NotifiedEntity is an optional parameter that identifies the entity to which the notifications is sent. This parameter is equal to the last received value of the NotifiedEntity parameter. The parameter is absent if there was no such parameter in the triggering request. The notification is sent to the "current notified entity" or, if no such entity was ever specified, to the address from which the request was received.
NotifiedEntity是一个可选参数，用于标识向其发送通知的实体。此参数等于NotifiedEntity参数的上次接收值。如果触发请求中没有此类参数，则该参数不存在。通知发送至“当前被通知实体”，或者，如果从未指定此类实体，则发送至接收请求的地址。
RequestIdentifier is parameter that repeats the RequestIdentifier parameter of the NotificationRequest that triggered this notification. It is used to correlate this notification with the request that triggered it.
RequestIdentifier是重复触发此通知的NotificationRequest的RequestIdentifier参数的参数。它用于将此通知与触发它的请求相关联。
ObservedEvents is a list of events that the gateway detected. A single notification may report a list of events that will be reported in the order in which they were detected. The list may only contain the identification of events that were requested in the RequestedEvents parameter of the triggering NotificationRequest. It will contain the events that were either accumulated (but not notified) or treated according to digit map (but no match yet), and the final event that triggered the detection or provided a final match in the digit map.
ObservedEvents是网关检测到的事件列表。单个通知可以报告事件列表，这些事件将按检测顺序报告。该列表可能仅包含在触发NotificationRequest的RequestedEvents参数中请求的事件的标识。它将包含累积（但未通知）或根据数字地图处理（但尚未匹配）的事件，以及触发检测或在数字地图中提供最终匹配的最终事件。
ReturnCode is a parameter returned by the call agent. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是呼叫代理返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
This command is used to create a connection between two endpoints.
此命令用于在两个端点之间创建连接。
ReturnCode,
ConnectionId,
[SpecificEndPointId,]
[LocalConnectionDescriptor,]
[SecondEndPointId,]
[SecondConnectionId]
<--- CreateConnection(CallId,
EndpointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
Mode,
[{RemoteConnectionDescriptor |
SecondEndpointId}, ]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode,
ConnectionId,
[SpecificEndPointId,]
[LocalConnectionDescriptor,]
[SecondEndPointId,]
[SecondConnectionId]
<--- CreateConnection(CallId,
EndpointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
Mode,
[{RemoteConnectionDescriptor |
SecondEndpointId}, ]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
A connection is defined by its endpoints. The input parameters in CreateConnection provide the data necessary to build a gateway's "view" of a connection.
连接由其端点定义。CreateConnection中的输入参数提供构建网关连接“视图”所需的数据。
CallId is a globally unique parameter that identifies the call (or session) to which this connection belongs. Connections that belong to the same call share the same call-id. The call-id can be used to identify calls for reporting and accounting purposes. It does not affect the handling of connections by the gateway.
CallId是一个全局唯一的参数，用于标识此连接所属的调用（或会话）。属于同一呼叫的连接共享同一个呼叫id。呼叫id可用于识别呼叫，以便进行报告和记帐。它不会影响网关对连接的处理。
EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes. The EndpointId can be fully-specified by assigning a value to the parameter EndpointId in the function call or it may be under-specified by using the "anyone" wildcard convention. If the endpoint is underspecified, the endpoint identifier will be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response.
EndpointId是执行CreateConnection的网关中连接端点的标识符。可以通过在函数调用中为参数EndpointId指定一个值来完全指定EndpointId，也可以通过使用“任何人”通配符约定来指定它。如果端点未指定，则网关将分配端点标识符，并在响应的SpecificEndPointId参数中返回其完整值。
The NotifiedEntity is an optional parameter that specifies where the Notify or DeleteConnection commands should be sent. If the parameter is absent, the Notify or DeleteConnection commands should be sent to the last received Notified Entity, or to originator of the CreateConnection command if no Notified Entity was ever received for the end point.
NotifiedEntity是一个可选参数，用于指定Notify或DeleteConnection命令的发送位置。如果该参数不存在，则应将Notify或DeleteConnection命令发送给最后一个收到通知的实体，或发送给CreateConnection命令的发起人（如果端点从未收到通知的实体）。
LocalConnectionOptions is a parameter used by the Call Agent to direct the handling of the connection by the gateway. The fields contained in LocalConnectionOptions are the following:
LocalConnectionOptions是呼叫代理用来指导网关处理连接的参数。LocalConnectionOptions中包含的字段如下所示：
* Encoding Method,
* 编码方法，
* Packetization period,
* 打包期，
* Bandwidth,
* 带宽，
* Type of Service,
* 服务类型，
* Usage of echo cancellation,
* 回音消除的使用，
* Usage of silence suppression or voice activity detection,
* 使用静音抑制或语音活动检测，
* Usage of signal level adaptation and noise level reduction, or "gain control."
* 使用信号电平自适应和噪声电平降低，或“增益控制”
* Usage of reservation service,
* 使用预约服务，
* Usage of RTP security,
* RTP安全性的使用，
* Type of network used to carry the connection.
* 用于承载连接的网络类型。
This set of field can be completed by vendor specific optional or mandatory extensions. The encoding of the first three fields, when they are present, will be compatible with the SDP and RTP profiles:
这组字段可以通过特定于供应商的可选或强制扩展来完成。前三个字段的编码（如果存在）将与SDP和RTP配置文件兼容：
* The encoding method shall be specified by using one or several valid encoding names, as defined in the RTP AV Profile or registered with the IANA.
* 编码方法应通过使用RTP AV配置文件中定义的或IANA注册的一个或多个有效编码名称来指定。
* The packetization period is encoded as either the length of time in milliseconds represented by the media in a packet, as specified in the "ptime" parameter of SDP, or as a range value, specifying both the minimum and maximum acceptable packetization periods.
* 打包周期编码为SDP的“ptime”参数中指定的数据包中媒体表示的时间长度（毫秒），或范围值，指定最小和最大可接受打包周期。
* The bandwidth is encoded as either a single value or a range, expressed as an integer number of kilobit per seconds.
* 带宽编码为单个值或范围，表示为每秒千比特的整数。
For each of the first three fields, the Call Agent has three options:
对于前三个字段中的每个字段，Call Agent都有三个选项：
* It may state exactly one value, which the gateway will then use for the connection,
* 它可能只声明一个值，然后网关将使用该值进行连接，
* It may provide a loose specification, such as a list of allowed encoding methods or a range of packetization periods,
* 它可能提供松散的规范，例如允许的编码方法列表或打包周期范围，
* It may simply provide a bandwidth indication, leaving the choice of encoding method and packetization period to the gateway.
* 它可以简单地提供带宽指示，将编码方法和打包周期的选择留给网关。
The bandwidth specification shall not contradict the specification of encoding methods and packetization period. If an encoding method is specified, then the gateway is authorized to use it, even if it results in the usage of a larger bandwidth than specified.
带宽规格不得与编码方法和打包周期的规格相矛盾。如果指定了编码方法，则网关有权使用该方法，即使其使用的带宽大于指定的带宽。
The LocalConnectionOptions parameter may be absent in the case of a data call.
在数据调用的情况下，LocalConnectionOptions参数可能不存在。
The Type of Service specifies the class of service that will be used for the connection. When the connection is transmitted over an IP network, the parameters encodes the 8-bit type of service value parameter of the IP header. When the Type of Service is not specified, the gateway shall use a default or configured value.
服务类型指定将用于连接的服务类别。当通过IP网络传输连接时，参数对IP报头的8位服务值参数类型进行编码。未指定服务类型时，网关应使用默认值或配置值。
The gateways can be instructed to perform a reservation, for example using RSVP, on a given connection. When a reservation is needed, the call agent will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service." The
可以指示网关在给定连接上执行保留，例如使用RSVP。当需要预订时，呼叫代理将指定应使用的预订配置文件，即“受控负载”或“保证服务”
absence of reservation can be indicated by asking for the "best effort" service, which is the default value of this parameter. When reservation has been asked on a connection, the gateway will:
没有预订可以通过请求“尽力而为”服务来表示，这是此参数的默认值。当在连接上请求保留时，网关将：
* start emitting RSVP "PATH" messages if the connection is in "send-only", "send-receive", "conference", "network loop back" or "network continuity test" mode (if a remote connection descriptor has been received,)
* 如果连接处于“仅发送”、“发送-接收”、“会议”、“网络环回”或“网络连续性测试”模式（如果已接收到远程连接描述符），则开始发出RSVP“PATH”消息
* start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the connection is in "receive-only", "send-receive", "conference", "network loop back" or "network continuity test" mode.
* 如果连接处于“仅接收”、“发送-接收”、“会议”、“网络环回”或“网络连续性测试”模式，则在收到“路径”消息后立即开始发送RSVP“RESV”消息。
The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period.
RSVP滤波器将根据连接的特性进行推导。RSVP资源配置文件将从连接的带宽和打包周期中推导出来。
By default, the telephony gateways always perform echo cancellation. However, it is necessary, for some calls, to turn off these operations. The echo cancellation parameter can have two values, "on" (when the echo cancellation is requested) and "off" (when it is turned off.)
默认情况下，电话网关始终执行回音消除。但是，对于某些呼叫，有必要关闭这些操作。回声消除参数可以有两个值，“开”（当请求回声消除时）和“关”（当它关闭时）
The telephony gateways may perform gain control, in order to adapt the level of the signal. However, it is necessary, for example for modem calls, to turn off this function. The gain control parameter may either be specified as "automatic", or as an explicit number of decibels of gain. The default is to not perform gain control, which is equivalent to specifying a gain of 0 decibels.
电话网关可以执行增益控制，以适应信号的电平。但是，必须关闭此功能，例如，对于调制解调器呼叫。增益控制参数可以指定为“自动”，也可以指定为明确的增益分贝数。默认情况下，不执行增益控制，这相当于指定0分贝的增益。
The telephony gateways may perform voice activity detection, and avoid sending packets during periods of silence. However, it is necessary, for example for modem calls, to turn off this detection. The silence suppression parameter can have two values, "on" (when the detection is requested) and "off" (when it is turned off.) The default is "off."
电话网关可执行语音活动检测，并避免在静默期间发送分组。但是，例如，对于调制解调器呼叫，必须关闭此检测。静音抑制参数可以有两个值，“开”（当检测被请求时）和“关”（当它被关闭时）。默认值为“关”
The Call agent can request the gateway to enable encryption of the audio Packets. It does so by providing an key specification, as specified in RFC 2327. By default, encryption is not used.
呼叫代理可以请求网关启用音频数据包的加密。它通过提供RFC 2327中规定的密钥规范来实现。默认情况下，不使用加密。
The Call Agent may instruct the gateway to prepare the connection on a specified type of network. The type of network is encoded as in the "connection-field" parameter of the SDP standard. Possible values are IN (Internet), ATM and LOCAL. The parameter is optional; if absent, the network is determined by the type of gateway.
呼叫代理可以指示网关在指定类型的网络上准备连接。网络类型按照SDP标准的“连接字段”参数进行编码。可能的值包括（Internet）、ATM和本地。该参数是可选的；如果没有，网络由网关的类型决定。
RemoteConnectionDescriptor is the connection descriptor for the remote side of a connection, on the other side of the IP network. It includes the same fields as in the LocalConnectionDescriptor, i.e. the fields that describe a session according to the SDP standard. This parameter may have a null value when the information for the remote end is not known yet. This occurs because the entity that builds a connection starts by sending a CreateConnection to one of the two gateways involved in it. For the first CreateConnection issued, there is no information available about the other side of the connection. This information may be provided later via a ModifyConnection call. In the case of data connections (mode=data), this parameter describes the characteristics of the data connection.
RemoteConnectionDescriptor是IP网络另一端连接的远程端的连接描述符。它包括与LocalConnectionDescriptor中相同的字段，即根据SDP标准描述会话的字段。当远程端的信息未知时，此参数可能具有空值。发生这种情况的原因是，构建连接的实体首先向其中涉及的两个网关之一发送CreateConnection。对于发出的第一个CreateConnection，没有关于连接另一端的可用信息。稍后可通过ModifyConnection调用提供此信息。对于数据连接（模式=数据），此参数描述数据连接的特征。
The SecondEndpointId can be used instead of the RemoteConnectionDescriptor to establish a connection between two endpoints located on the same gateway. The connection is by definition a local connection. The SecondEndpointId can be fully-specified by assigning a value to the parameter SecondEndpointId in the function call or it may be under-specified by using the "anyone" wildcard convention. If the secondendpoint is underspecified, the second endpoint identifier will be assigned by the gateway and its complete value returned in the SecondEndPointId parameter of the response.
可以使用SecondEndpointId而不是RemoteConnectionDescriptor在位于同一网关上的两个端点之间建立连接。根据定义，该连接是本地连接。可以通过在函数调用中为参数SecondEndpointId赋值来完全指定SecondEndpointId，也可以通过使用“任何人”通配符约定来指定它。如果未指定secondendpoint，则网关将分配第二个端点标识符，并在响应的SecondEndPointId参数中返回其完整值。
Mode indicates the mode of operation for this side of the connection. The mode are "send", "receive", "send/receive", "conference", "data", "inactive", "loopback", "continuity test", "network loop back" or "network continuity test." The expected handling of these modes is specified in the introduction of the "Gateway Handling Function" section. Some end points may not be capable of supporting all modes. If the command specifies a mode that the endpoint cannot support, and error shall be returned.
Mode（模式）表示连接这一侧的操作模式。模式为“发送”、“接收”、“发送/接收”、“会议”、“数据”、“非活动”、“环回”、“连续性测试”、“网络环回”或“网络连续性测试”。这些模式的预期处理在“网关处理功能”一节的介绍中有详细说明。某些端点可能无法支持所有模式。如果命令指定了端点无法支持的模式，则应返回错误。
The gateway returns a ConnectionId, that uniquely identifies the connection within one endpoint, and a LocalConnectionDescriptor, which is a session description that contains information about addresses and RTP ports, as defined in SDP. The LocalConnectionDescriptor is not returned in the case of data connections. The SpecificEndPointId is an optional parameter that identifies the responding endpoint. It can be used when the EndpointId argument referred to a "any of" wildcard name. When a SpecificEndPointId is returned, the Call Agent should use it as the EndpointId value is successive commands referring to this call.
网关返回一个ConnectionId（唯一标识一个端点内的连接）和一个LocalConnectionDescriptor（包含SDP中定义的地址和RTP端口信息的会话描述）。对于数据连接，不会返回LocalConnectionDescriptor。SpecificEndPointId是标识响应端点的可选参数。当EndpointId参数引用“任意”通配符名称时，可以使用它。返回SpecificEndPointId时，调用代理应该使用它，因为EndpointId值是引用此调用的连续命令。
When a SecondEndpointId is specified, the command really creates two connections that can be manipulated separately through ModifyConnection and DeleteConnection commands. The response to the creation provides a SecondConnectionId parameter that identifies the second connection.
当指定SecondEndpointId时，该命令实际上创建了两个连接，可以通过ModifyConnection和DeleteConnection命令分别操作这两个连接。对创建的响应提供了一个SecondConnectionId参数，用于标识第二个连接。
After receiving a "CreateConnection" request that did not include a RemoteConnectionDescriptor parameter, a gateway is in an ambiguous situation. Because it has exported a LocalConnectionDescriptor parameter, it can potentially receive packets. Because it has not yet received the RemoteConnectionDescriptor parameter of the other gateway, it does not know whether the packets that it receives have been authorized by the Call Agent. It must thus navigate between two risks, i.e. clipping some important announcements or listening to insane data. The behavior of the gateway is determined by the value of the Mode parameter:
收到不包含RemoteConnectionDescriptor参数的“CreateConnection”请求后，网关处于不明确的状态。由于它已导出LocalConnectionDescriptor参数，因此可能会接收数据包。因为它尚未接收到另一个网关的RemoteConnectionDescriptor参数，所以它不知道它接收的数据包是否已被呼叫代理授权。因此，它必须在两种风险之间导航，即剪辑一些重要的公告或收听疯狂的数据。网关的行为由模式参数的值决定：
* If the mode was set to ReceiveOnly, the gateway should accept the voice signals and transmit them through the endpoint.
* 如果模式设置为ReceiveOnly，网关应接受语音信号并通过端点传输。
* If the mode was set to Inactive, Loopback, Continuity Test, the gateway should refuse the voice signals.
* 如果模式设置为非活动、环回、连续性测试，网关应拒绝语音信号。
* If the mode was set to Network Loopback or Network Continuity Test, the gateway should perform the expected echo or Response.
* 如果模式设置为网络环回或网络连续性测试，网关应执行预期的回音或响应。
Note that the mode values SendReceive, Conference, Data and SendOnly don't make sense in this situation. They should be treated as errors, and the command should be rejected (Error code 517).
请注意，模式值SendReceive、Conference、Data和SendOnly在这种情况下没有意义。它们应被视为错误，并且该命令应被拒绝（错误代码517）。
The command may optionally contain an encapsulated Notification Request command, in which case a RequestIdentifier parameter will be present, as well as, optionally, the RequestedEvents DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The encapsulated NotificationRequest is executed simultaneously with the creation of the connection. For example, when the Call Agent wants to initiate a call to an residential gateway, it should:
该命令可以可选地包含封装的通知请求命令，在这种情况下，将出现RequestIdentifier参数，还可以可选地包含RequestedEvents DigitMap、SignalRequests、QuarantineHandling和DetecteEvents参数。封装的NotificationRequest在创建连接的同时执行。例如，当呼叫代理想要发起对住宅网关的呼叫时，它应该：
* ask the residential gateway to prepare a connection, in order to be sure that the user can start speaking as soon as the phone goes off hook,
* 请住宅网关准备一个连接，以确保用户可以在电话挂断后立即开始通话，
* ask the residential gateway to start ringing,
* 要求住宅网关开始鸣响，
* ask the residential gateway to notify the Call Agent when the phone goes off-hook.
* 当电话挂断时，请住宅网关通知呼叫代理。
This can be accomplished in a single CreateConnection command, by also transmitting the RequestedEvent parameters for the off hook event, and the SignalRequest parameter for the ringing signal.
这可以通过单个CreateConnection命令来实现，也可以通过传输摘机事件的RequestedEvent参数和振铃信号的SignalRequest参数来实现。
When these parameters are present, the creation and the NotificationRequests should be synchronized, which means that bothshould be accepted, or both refused. In our example, the CreateConnection may be refused if the gateway does not have sufficient resources, or cannot get adequate resources from the local network access, and the off-hook Notification-Request can be refused in the glare condition, if the user is already off-hook. In this example, the phone should not ring if the connection cannot be established, and the connection should not be established if the user is already off hook.
当这些参数存在时，创建和通知请求应该同步，这意味着两者都应该被接受，或者两者都被拒绝。在我们的示例中，如果网关没有足够的资源，或者无法从本地网络访问获得足够的资源，则可能会拒绝CreateConnection，如果用户已经脱离连接，则在眩光条件下可以拒绝脱离连接的通知请求。在本例中，如果无法建立连接，则手机不应响铃；如果用户已脱离连接，则不应建立连接。
The NotifiedEntity parameter, if present, applies to both the CreateConnection and the NotificationRequest command. It defines the new "notified entity" for the endpoint.
NotifiedEntity参数（如果存在）同时应用于CreateConnection和NotificationRequest命令。它为端点定义了新的“通知实体”。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the CreateConnection with the exception of the EndpointId, which is not replicated. The EndpointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
该命令可能携带一个封装的EndpointConfiguration命令，该命令将应用于同一端点。存在此命令时，EndpointConfiguration命令的参数将插入CreateConnection的正常参数之后，EndpointId除外，该参数不会被复制。EndpointConfiguration命令可以与封装的NotificationRequest命令一起封装。
The encapsulated EndpointConfiguration command shares the fate of the CreateConnection command. If the CreateConnection is rejected, the EndpointConfiguration is not executed.
封装的EndpointConfiguration命令共享CreateConnection命令的命运。如果CreateConnection被拒绝，则不会执行EndpointConfiguration。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
This command is used to modify the characteristics of a gateway's "view" of a connection. This "view" of the call includes both the local connection descriptors as well as the remote connection descriptor.
此命令用于修改网关连接“视图”的特征。该调用的“视图”包括本地连接描述符和远程连接描述符。
ReturnCode,
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode,
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
The parameters used are the same as in the CreateConnection command, with the addition of a ConnectionId that identifies the connection within the endpoint. This parameter is returned by the CreateConnection function, as part of the local connection descriptor. It uniquely identifies the connection within the context of the endpoint.
使用的参数与CreateConnection命令中的参数相同，只是添加了一个ConnectionId，用于标识端点内的连接。此参数由CreateConnection函数返回，作为本地连接描述符的一部分。它唯一地标识端点上下文中的连接。
The EndpointId should be a fully qualified endpoint identifier. The local name shall not use the wildcard convention.
EndpointId应该是完全限定的端点标识符。本地名称不得使用通配符约定。
The ModifyConnection command can be used to affect parameters of a connection in the following ways:
ModifyConnection命令可用于通过以下方式影响连接的参数：
* Provide information about the other end of the connection, through the RemoteConnectionDescriptor.
* 通过RemoteConnectionDescriptor提供有关连接另一端的信息。
* Activate or deactivate the connection, by changing the value of the Mode parameter. This can occur at any time during the connection, with arbitrary parameter values.
* 通过更改模式参数的值来激活或停用连接。这可以在连接过程中的任何时候发生，参数值可以是任意的。
* Change the sending parameters of the connection, for example by switching to a different coding scheme, changing the packetization period, or modifying the handling of echo cancellation.
* 更改连接的发送参数，例如通过切换到不同的编码方案、更改分组周期或修改回声消除的处理。
Connections can only be activated if the RemoteConnectionDescriptor has been provided to the gateway. The receive only mode, however, can be activated without the provision of this descriptor.
只有向网关提供了RemoteConnectionDescriptor，才能激活连接。但是，可以在不提供此描述符的情况下激活仅接收模式。
The command will only return a LocalConnectionDescriptor if the local connection parameters, such as RTP ports, were modified. (Usage of this feature is actually for further study.)
如果修改了本地连接参数（如RTP端口），则该命令将仅返回LocalConnectionDescriptor。（此功能的使用实际上是为了进一步研究。）
The command may optionally contain an encapsulated Notification Request command, in which case a RequestIdentifier parameter will be present, as well as, optionnally, the RequestedEvents DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The
该命令可以可选地包含封装的通知请求命令，在这种情况下，将出现RequestIdentifier参数，以及可选的RequestedEvents DigitMap、SignalRequests、QuarantineHandling和DetecteEvents参数。这个
encapsulated NotificationRequest is executed simultaneously with the modification of the connection. For example, when a connection is accepted, the calling gateway should be instructed to place the circuit in send-receive mode and to stop providing ringing tones.
封装的NotificationRequest在修改连接的同时执行。例如，当连接被接受时，应指示呼叫网关将电路置于发送-接收模式并停止提供铃声。
This can be accomplished in a single ModifyConnection command, by also transmitting the RequestedEvent parameters, for the on hook event, and an empty SignalRequest parameter, to stop the provision of ringing tones.
这可以通过单个ModifyConnection命令完成，也可以通过传输挂机事件的RequestedEvent参数和空的SignalRequest参数来停止提供铃声。
When these parameters are present, the modification and the NotificationRequests should be synchronized, which means that both should be accepted, or both refused. The NotifiedEntity parameter, if present, applies to both the ModifyConnection and the NotificationRequest command.
当这些参数存在时，修改和通知请求应该同步，这意味着两者都应该被接受，或者两者都被拒绝。NotifiedEntity参数（如果存在）同时应用于ModifyConnection和NotificationRequest命令。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the ModifyConnection with the exception of the EndpointId, which is not replicated. The EndpointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
该命令可能携带一个封装的EndpointConfiguration命令，该命令将应用于同一端点。存在此命令时，EndpointConfiguration命令的参数将插入ModifyConnection的正常参数之后，EndpointId除外，该参数不会被复制。EndpointConfiguration命令可以与封装的NotificationRequest命令一起封装。
The encapsulated EndpointConfiguration command shares the fate of the ModifyConnection command. If the ModifyConnection is rejected, the EndpointConfiguration is not executed.
封装的EndpointConfiguration命令共享ModifyConnection命令的命运。如果ModifyConnection被拒绝，则不会执行EndpointConfiguration。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
This command is used to terminate a connection. As a side effect, it collects statistics on the execution of the connection.
此命令用于终止连接。作为一个副作用，它收集连接执行的统计信息。
ReturnCode, Connection-parameters <-- DeleteConnection(CallId, EndpointId, ConnectionId, [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration])
ReturnCode，连接参数<--DeleteConnection（CallId，EndpointId，ConnectionId，[封装的NotificationRequest，][封装的EndpointConfiguration]）
The endpoint identifier, in this form of the DeleteConnection command, shall be fully qualified. Wildcard conventions shall not be used.
这种形式的DeleteConnection命令中的端点标识符应完全合格。不得使用通配符约定。
In the general case where a connection has two ends, this command has to be sent to both gateways involved in the connection. Some connections, however, may use IP multicast. In this case, they can be deleted individually.
在连接有两端的一般情况下，此命令必须发送到连接中涉及的两个网关。但是，某些连接可能使用IP多播。在这种情况下，可以单独删除它们。
After the connection has been deleted, any loopback that has been requested for the connection should be cancelled. When all connections to an endpoint have been deleted, that endpoint should be placed in inactive mode.
删除连接后，应取消为连接请求的任何环回。删除与端点的所有连接后，该端点应处于非活动模式。
In response to the DeleteConnection command, the gateway returns a list of parameters that describe the status of the connection. These parameters are:
作为对DeleteConnection命令的响应，网关返回描述连接状态的参数列表。这些参数是：
Number of packets sent:
发送的数据包数：
The total number of RTP data packets transmitted by the sender since starting transmission on this connection. The count is not reset if the sender changes its synchronization source identifier (SSRC, as defined in RTP), for example as a result of a Modify command. The value is zero if the connection was set in "receive only" mode.
自在此连接上开始传输以来，发送方传输的RTP数据包总数。如果发送方更改其同步源标识符（SSRC，如RTP中所定义），例如由于修改命令，则不会重置计数。如果连接设置为“仅接收”模式，则该值为零。
Number of octets sent:
发送的八位字节数：
The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission on this connection. The count is not reset if the sender changes its SSRC identifier, for example as a result of a ModifyConnection command. The value is zero if the connection was set in "receive only" mode.
自在该连接上开始传输以来，发送方在RTP数据包中传输的有效负载八位字节总数（即，不包括报头或填充）。如果发送方更改其SSRC标识符（例如，由于ModifyConnection命令），则不会重置计数。如果连接设置为“仅接收”模式，则该值为零。
Number of packets received:
收到的数据包数：
The total number of RTP data packets received by the sender since starting reception on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode.
自此连接上开始接收以来，发送方接收的RTP数据包总数。如果发送方使用了多个值，则计数包括从不同SSRC接收的数据包。如果连接设置为“仅发送”模式，则该值为零。
Number of octets received:
收到的八位字节数：
The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode.
自在该连接上开始传输以来，发送方在RTP数据包中传输的有效负载八位字节总数（即，不包括报头或填充）。如果发送方使用了多个值，则计数包括从不同SSRC接收的数据包。如果连接设置为“仅发送”模式，则该值为零。
Number of packets lost:
丢失的数据包数：
The total number of RTP data packets that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. The count includes packets received from different SSRC, if the sender used several values. Thus packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The count includes packets received from different SSRC, if the sender used several values. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. This parameter is omitted if the connection was set in "data" mode.
自接收开始以来已丢失的RTP数据包总数。该数字被定义为预期的数据包数量减去实际接收的数据包数量，其中接收的数据包数量包括任何延迟或重复的数据包。如果发送方使用了多个值，则计数包括从不同SSRC接收的数据包。因此，延迟到达的数据包不被视为丢失，如果存在重复数据包，则丢失可能为负。如果发送方使用了多个值，则计数包括从不同SSRC接收的数据包。预期的数据包数定义为接收到的扩展的最后一个序列号，如下面定义的，减去接收到的初始序列号。如果发送方使用了多个值，则计数包括从不同SSRC接收的数据包。如果连接设置为“仅发送”模式，则该值为零。如果连接设置为“数据”模式，则忽略此参数。
Interarrival jitter:
到达间隔抖动：
An estimate of the statistical variance of the RTP data packet interarrival time measured in milliseconds and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. Detailed computation algorithms are found in RFC 1889. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. This parameter is omitted if the connection was set in "data" mode.
RTP数据包到达间隔时间的统计方差估计值，以毫秒为单位，表示为无符号整数。到达间抖动J被定义为一对分组的接收器处的分组间隔与发送器处的分组间隔之差D的平均偏差（平滑绝对值）。详细的计算算法见RFC1889。如果发送方使用了多个值，则计数包括从不同SSRC接收的数据包。如果连接设置为“仅发送”模式，则该值为零。如果连接设置为“数据”模式，则忽略此参数。
Average transmission delay:
平均传输延迟：
An estimate of the network latency, expressed in milliseconds. This is the average value of the difference between the NTP timestamp indicated by the senders of the RTCP messages and the NTP timestamp of the receivers, measured when this messages are received. The average is obtained by summing all the estimates, then dividing by the number of RTCP messages that have been received. This parameter is omitted if the connection was set in "data" mode. When the gateway's clock is not synchronized by NTP, the latency value can be computed as one half of the round trip delay, as measured through RTCP. When the gateway cannot compute the one way delay or the round trip delay, the parameter conveys a null value.
网络延迟的估计值，以毫秒为单位。这是RTCP消息的发送方指示的NTP时间戳与接收方的NTP时间戳之间差值的平均值，在接收该消息时测量。将所有估计值相加，然后除以已接收的RTCP消息数，即可获得平均值。如果连接设置为“数据”模式，则忽略此参数。当网关时钟未通过NTP同步时，延迟值可计算为通过RTCP测量的往返延迟的一半。当网关无法计算单向延迟或往返延迟时，该参数传递空值。
For a detailed definition of these variables, refer to RFC 1889.
有关这些变量的详细定义，请参阅RFC 1889。
When the connection was set up over an ATM network, the meaning of these parameters may change:
当通过ATM网络建立连接时，这些参数的含义可能会改变：
Number of packets sent: The total number of ATM cells transmitted since starting transmission on this connection.
发送的数据包数：自此连接上开始传输以来传输的ATM信元总数。
Number of octets sent: The total number of payload octets transmitted in ATM cells.
发送的八位字节数：ATM信元中传输的有效负载八位字节总数。
Number of packets received: The total number of ATM cells received since starting reception on this connection.
接收的数据包数：自此连接上开始接收以来接收的ATM信元总数。
Number of octets received: The total number of payload octets received in ATM cells.
接收的八位字节数：ATM信元中接收的有效负载八位字节总数。
Number of packets lost: Should be determined as the number of cell losts, or set to zero if the adaptation layer does not enable the gateway to assess losses.
丢失的数据包数量：应确定为小区丢失的数量，如果适配层不允许网关评估丢失，则应将其设置为零。
Interarrival jitter: Should be understood as the interarrival jitter between ATM cells.
到达间隔抖动：应理解为ATM信元之间的到达间隔抖动。
Average transmission delay: The gateway may not be able to assess this parameter over an ATM network. It could simply report a null value.
平均传输延迟：网关可能无法通过ATM网络评估此参数。它可以简单地报告一个空值。
When the connection was set up over an LOCAL interconnect, the meaning of these parameters is defined as follows:
当通过本地互连建立连接时，这些参数的含义定义如下：
Number of packets sent: Not significant.
发送的数据包数：不重要。
Number of octets sent: The total number of payload octets transmitted over the local connection.
发送的八位字节数：通过本地连接传输的有效负载八位字节总数。
Number of packets received: Not significant.
接收的数据包数：不重要。
Number of octets received: The total number of payload octets received over the connection.
接收的八位字节数：通过连接接收的有效负载八位字节总数。
Number of packets lost: Not significant. A value of zero is assumed.
丢失的数据包数：不显著。假定值为零。
Interarrival jitter: Not significant. A value of zero is assumed.
到达间隔抖动：不显著。假定值为零。
Average transmission delay: Not significant. A value of zero is assumed.
平均传输延迟：不显著。假定值为零。
The standard set of connection parameters can be extended by the creation of extension parameters.
可以通过创建扩展参数来扩展标准连接参数集。
The command may optionally contain an encapsulated Notification Request command, in which case a RequestIdentifier parameter will be present, as well as, optionnally, the RequestedEvents DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters. The encapsulated NotificationRequest is executed simultaneously with the deletion of the connection. For example, when a user hang-up is notified, the gateway should be instructed to delete the connection and to start looking for an off hook event.
该命令可以可选地包含封装的通知请求命令，在这种情况下，将出现RequestIdentifier参数，以及可选的RequestedEvents DigitMap、SignalRequests、QuarantineHandling和DetecteEvents参数。封装的NotificationRequest在删除连接的同时执行。例如，当通知用户挂断时，应指示网关删除连接并开始查找脱离连接的事件。
This can be accomplished in a single DeleteConnection command, by also transmitting the RequestedEvent parameters, for the off hook event, and an empty SignalRequest parameter.
这可以通过一个DeleteConnection命令来完成，也可以通过传输摘机事件的RequestedEvent参数和空的SignalRequest参数来完成。
When these parameters are present, the DeleteConnection and the NotificationRequests should be synchronized, which means that both should be accepted, or both refused.
当这些参数存在时，DeleteConnection和NotificationRequests应该同步，这意味着两者都应该被接受，或者两者都被拒绝。
The command may carry an encapsulated EndpointConfiguration command, that will apply to the same endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the DeleteConnection with the exception of the EndpointId, which is not replicated. The EndpointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
该命令可能携带一个封装的EndpointConfiguration命令，该命令将应用于同一端点。存在此命令时，EndpointConfiguration命令的参数将插入DeleteConnection的正常参数之后，EndpointId除外，该参数不会被复制。EndpointConfiguration命令可以与封装的NotificationRequest命令一起封装。
The encapsulated EndpointConfiguration command shares the fate of the DeleteConnection command. If the DeleteConnection is rejected, the EndpointConfiguration is not executed.
封装的EndpointConfiguration命令共享DeleteConnection命令的命运。如果拒绝DeleteConnection，则不会执行EndpointConfiguration。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
In some circumstances, a gateway may have to clear a connection, for example because it has lost the resource associated with the connection, or because it has detected that the endpoint no longer is capable or willing to send or receive voice. The gateway terminates the connection by using a variant of the DeleteConnection command:
在某些情况下，网关可能必须清除连接，例如，因为它丢失了与连接相关联的资源，或者因为它检测到端点不再能够或愿意发送或接收语音。网关使用DeleteConnection命令的变体终止连接：
ReturnCode, <-- DeleteConnection( CallId, EndpointId, ConnectionId, Reason-code, Connection-parameters)
ReturnCode，<--DeleteConnection（CallId、EndpointId、ConnectionId、原因码、连接参数）
In addition to the call, endpoint and connection identifiers, the gateway will also send the call's parameters that would have been returned to the Call Agent in response to a DeleteConnection command. The reason code indicates the cause of the disconnection.
除了调用、端点和连接标识符之外，网关还将发送调用的参数，这些参数将返回给调用代理以响应DeleteConnection命令。原因代码指示断开的原因。
ReturnCode is a parameter returned by the call agent. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是呼叫代理返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
A variation of the DeleteConnection function can be used by the Call Agent to delete multiple connections at the same time. The command can be used to delete all connections that relate to a Call for an endpoint:
调用代理可以使用DeleteConnection函数的变体同时删除多个连接。该命令可用于删除与端点调用相关的所有连接：
ReturnCode, <-- DeleteConnection( CallId, EndpointId)
返回代码，<--DeleteConnection（CallId，EndpointId）
It can also be used to delete all connections that terminate in a given endpoint:
它还可用于删除在给定端点终止的所有连接：
ReturnCode, <-- DeleteConnection( EndpointId)
返回代码，<--DeleteConnection（端点ID）
Finally, Call Agents can take advantage of the hierarchical naming structure of endoints to delete all the connections that belong to a group of endpoints. In this case, the "local name" component of the EndpointID will be specified using the "all value" wildcarding convention. The "any value" convention shall not be used. For example, if endpoints names are structured as the combination of a physical interface name and a circuit number, as in "X35V3+A4/13",
最后，调用代理可以利用endoint的分层命名结构删除属于一组端点的所有连接。在这种情况下，将使用“所有值”通配符约定指定EndpointID的“本地名称”组件。不得使用“任何价值”公约。例如，如果端点名称的结构是物理接口名称和电路编号的组合，如“X35V3+A4/13”，
the Call Agent may replace the circuit number by a wild card character "*", as in "X35V3+A4/*". This "wildcard" command instructs the gateway to delete all the connections that where attached to circuits connected to the physical interface "X35V3+A4".
呼叫代理可以用通配符“*”替换电路号，如“X35V3+A4/*”中所示。此“通配符”命令指示网关删除连接到物理接口“X35V3+A4”的电路的所有连接。
After the connections have been deleted, the endpoint should be placed in inactive mode. Any loopback that has been requested for the connections should be cancelled.
删除连接后，应将端点置于非活动模式。应取消为连接请求的任何环回。
This command does not return any individual statistics or call parameters.
此命令不返回任何单个统计信息或调用参数。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
The AuditEndPoint command can be used by the Call Agent to find out the status of a given endpoint.
调用代理可以使用AuditEndPoint命令来查找给定端点的状态。
ReturnCode,
EndPointIdList|{
[RequestedEvents,]
[DigitMap,]
[SignalRequests,]
[RequestIdentifier,]
[NotifiedEntity,]
[ConnectionIdentifiers,]
[DetectEvents,]
[ObservedEvents,]
[EventStates,]
[BearerInformation,]
[RestartReason,]
[RestartDelay,]
[ReasonCode,]
[Capabilities]}
<--- AuditEndPoint(EndpointId,
[RequestedInfo])
ReturnCode,
EndPointIdList|{
[RequestedEvents,]
[DigitMap,]
[SignalRequests,]
[RequestIdentifier,]
[NotifiedEntity,]
[ConnectionIdentifiers,]
[DetectEvents,]
[ObservedEvents,]
[EventStates,]
[BearerInformation,]
[RestartReason,]
[RestartDelay,]
[ReasonCode,]
[Capabilities]}
<--- AuditEndPoint(EndpointId,
[RequestedInfo])
The EndpointId identifies the endpoint that is being audited. The "all of" wildcard convention can be used to start auditing of a group of endpoints. If this convention is used, the gateway should return the list of endpoint identifiers that match the wildcard in the EndPointIdList parameter. It shall not return any parameter specific to one of these endpoints.
EndpointId标识正在审核的端点。“全部”通配符约定可用于开始审核一组端点。如果使用此约定，网关应返回与EndPointIdList参数中的通配符匹配的端点标识符列表。它不应返回特定于这些端点之一的任何参数。
When a non-wildcard EndpointId is specified, the (possibly empty) RequestedInfo parameter describes the information that is requested for the EndpointId specified. The following endpoint info can be audited with this command:
指定非通配符EndpointId时，RequestedInfo参数（可能为空）描述为指定的EndpointId请求的信息。可以使用此命令审核以下端点信息：
RequestedEvents, DigitMap, SignalRequests, RequestIdentifier, NotifiedEntity, ConnectionIdentifiers, DetectEvents, ObservedEvents, EventStates, RestartReason, RestartDelay, ReasonCode, and Capabilities.
RequestedEvents、DigitMap、SignalRequests、RequestIdentifier、NotifiedEntity、ConnectionIdentifiers、DetectedEvents、ObservedEvents、EventState、RestartReason、RestartDelay、ReasonCode和功能。
The response will in turn include information about each of the items for which auditing info was requested:
回复将依次包括有关要求审核信息的每个项目的信息：
* RequestedEvents: The current value of RequestedEvents the endpoint is using including the action associated with each event. Persistent events are included in the list.
* RequestedEvents：端点正在使用的RequestedEvents的当前值，包括与每个事件关联的操作。持久性事件包括在列表中。
* DigitMap: the digit map the endpoint is currently using.
* DigitMap：端点当前使用的数字映射。
* SignalRequests: A list of the; Time-Out signals that are currently active, On/Off signals that are currently "on" for the endpoint (with or without parameter), and any pending Brief signals. Time-Out signals that have timed-out, and currently playing Brief signals are not included.
* SignalRequests：请求的列表；当前处于活动状态的超时信号、端点当前处于“开启”状态的开/关信号（带或不带参数）以及任何挂起的简短信号。已超时的超时信号和当前播放的简短信号不包括在内。
* RequestIdentifier, the RequestIdentifier for the last Notification Request received by this endpoint (includes NotificationRequest encapsulated in Connection handling primitives). If no notification request has been received, the value zero will be returned.
* RequestIdentifier，此端点接收的最后一个通知请求的RequestIdentifier（包括封装在连接处理原语中的NotificationRequest）。如果未收到通知请求，则返回值零。
* QuarantineHandling, the QuarantineHandling for the last NotificationRequest received by this endpoint.
* QuarantineHandling，此终结点接收的最后一个NotificationRequest的隔离处理。
* DetectEvents, the list of events that are currently detected in quarantine mode.
* DetecteEvents，当前在隔离模式下检测到的事件列表。
* NotifiedEntity, the current notified entity for the endpoint.
* NotifiedEntity，端点的当前通知实体。
* ConnectionIdentifiers, the list of ConnectionIdentifiers for all connections that currently exist for the specified endpoint.
* ConnectionIdentifiers，指定端点当前存在的所有连接的ConnectionIdentifiers列表。
* ObservedEvents: the current list of observed events for the endpoint.
* ObservedEvents：端点的当前观察事件列表。
* EventStates: For events that have auditable states associated with them, the event corresponding to the state the endpoint is in, e.g., off-hook if the endpoint is off-hook. The definition of the individual events will state if the event in question has an auditable state associated with it.
* EventState：对于具有关联的可审核状态的事件，对应于端点所处状态的事件，例如，如果端点处于摘机状态，则为摘机状态。单个事件的定义将说明相关事件是否具有关联的可审核状态。
* BearerInformation: the value of the last received BearerInformation parameter for this endpoint.
* BealerInformation:此终结点上次接收的BealerInformation参数的值。
* RestartReason: the value of the restart reason parameter in the last RestartInProgress command issued by the endpoint, "restart" indicating a fully functional endpoint.
* RestartReason：端点发出的最后一个RestartInProgress命令中的restart reason参数的值，“restart”表示功能齐全的端点。
* RestartDelay: the value of the restart delay parameter if a RestartInProgress command was issued by the endpoint at the time of the response, or zero if the command would not include this parameter.
* RestartDelay：如果响应时端点发出RestartInProgress命令，则为restart delay参数的值；如果命令不包含此参数，则为零。
* ReasonCode:the value of the Reason-Code parameter in the last RestartInProgress or DeleteConnection command issued by the gateway for the endpoint, or the special value 000 if the endpoint's state is nominal.
* ReasonCode：网关为端点发出的上一次RestartInProgress或DeleteConnection命令中的ReasonCode参数值，或者如果端点的状态为标称，则为特殊值000。
* The capabilities for the endpoint similar to the LocalConnectionOptions parameter and including event packages and connection modes. If there is a need to specify that some parameters, such as e.g., silence suppression, are only compatible with some
* 端点的功能类似于LocalConnectionOptions参数，包括事件包和连接模式。如果需要指定某些参数，例如静音抑制，仅与某些参数兼容
* codecs, then the gateway will return several capability sets:
* 编解码器，然后网关将返回多个功能集：
Compression Algorithm: a list of supported codecs. The rest of the parameters will apply to all codecs specified in this list.
压缩算法：支持的编解码器列表。其余参数将应用于此列表中指定的所有编解码器。
Packetization Period: A single value or a range may be specified.
打包周期：可以指定单个值或范围。
Bandwidth: A single value or a range corresponding to the range for packetization periods may be specified (assuming no silence suppression).
带宽：可以指定单个值或与打包周期范围相对应的范围（假设没有静音抑制）。
Echo Cancellation: Whether echo cancellation is supported or not.
回音取消：是否支持回音取消。
Silence Suppression: Whether silence suppression is supported or not.
静音抑制：是否支持静音抑制。
Type of Service: Whether type of service is supported or not.
服务类型：是否支持服务类型。
Event Packages: A list of event packages supported. The first event package in the list will be the default package.
事件包：支持的事件包列表。列表中的第一个事件包将是默认包。
Modes: A list of supported connection modes.
模式：支持的连接模式列表。
The Call Agent may then decide to use the AuditConnection command to obtain further information about the connections.
然后，呼叫代理可以决定使用AuditConnection命令来获取有关连接的进一步信息。
If no info was requested and the EndpointId refers to a valid endpoint, the gateway simply returns a positive acknowledgement.
如果未请求任何信息，并且EndpointId引用了有效的端点，则网关只返回肯定的确认。
If no NotifiedEntity has been specified in the last NotificationRequest, the notified entity defaults to the source address of the last NotificationRequest command received for this connection.
如果上次NotificationRequest中未指定NotificationIdentity，则被通知实体默认为为此连接接收的上次NotificationRequest命令的源地址。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
The AuditConnection command can be used by the Call Agent to retrieve the parameters attached to a connection:
调用代理可以使用AuditConnection命令检索连接所附加的参数：
ReturnCode,
[CallId,]
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[LocalConnectionDescriptor,]
[ConnectionParameters]
<--- AuditConnection(EndpointId,
ConnectionId,
RequestedInfo)
ReturnCode,
[CallId,]
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[LocalConnectionDescriptor,]
[ConnectionParameters]
<--- AuditConnection(EndpointId,
ConnectionId,
RequestedInfo)
The EndpointId parameter specifies the endpoint that handles the connection. The wildcard conventions shall not be used.
EndpointId参数指定处理连接的端点。不得使用通配符约定。
The ConnectionId parameter is the identifier of the audited connection, within the context of the specified endpoint.
ConnectionId参数是指定端点上下文中已审核连接的标识符。
The (possibly empty) RequestedInfo describes the information that is requested for the ConnectionId within the EndpointId specified. The following connection info can be audited with this command:
RequestedInfo（可能为空）描述了为指定EndpointId内的ConnectionId请求的信息。使用此命令可以审核以下连接信息：
CallId, NotifiedEntity, LocalConnectionOptions, Mode, RemoteConnectionDescriptor, LocalConnectionDescriptor, ConnectionParameters
CallId、NotifiedEntity、LocalConnectionOptions、Mode、RemoteConnectionDescriptor、LocalConnectionDescriptor、ConnectionParameters
The AuditConnectionResponse will in turn include information about each of the items auditing info was requested for:
AuditConnectionResponse将依次包括有关以下各项的信息：请求的审核信息：
* CallId, the CallId for the call the connection belongs to.
* CallId，连接所属呼叫的CallId。
* NotifiedEntity, the current notified entity for the Connection.
* NotifiedEntity，连接的当前通知实体。
* LocalConnectionOptions, the LocalConnectionOptions that was supplied for the connection.
* LocalConnectionOptions，为连接提供的LocalConnectionOptions。
* Mode, the current mode of the connection.
* 模式，连接的当前模式。
* RemoteConnectionDescriptor, the RemoteConnectionDescriptor that was supplied to the gateway for the connection.
* RemoteConnectionDescriptor，为连接提供给网关的RemoteConnectionDescriptor。
* LocalConnectionDescriptor, the LocalConnectionDescriptor the gate-way supplied for the connection.
* LocalConnectionDescriptor，LocalConnectionDescriptor为连接提供的门路径。
* ConnectionParameters, the current value of the connection parameters for the connection.
* ConnectionParameters，连接的连接参数的当前值。
If no info was requested and the EndpointId is valid, the gateway simply checks that the connection exists, and if so returns a positive acknowledgement.
如果未请求任何信息且EndpointId有效，网关只需检查连接是否存在，如果存在，则返回肯定确认。
If no NotifiedEntity has been specified for the connection, the notified entity defaults to the source address of the last connection handling command received for this connection.
如果未为连接指定NotifiedEntity，则通知的实体默认为为此连接接收的最后一个连接处理命令的源地址。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
The RestartInProgress command is used by the gateway to signal that An endpoint, or a group of endpoint, is taken in or out of service.
网关使用RestartInProgress命令发出一个端点或一组端点进入或退出服务的信号。
ReturnCode,
[NotifiedEntity]
<------- RestartInProgress ( EndPointId,
RestartMethod,
[RestartDelay,]
[Reason-code])
ReturnCode,
[NotifiedEntity]
<------- RestartInProgress ( EndPointId,
RestartMethod,
[RestartDelay,]
[Reason-code])
The EndPointId identifies the endpoint that are taken in or out of service. The "all of" wildcard convention may be used to apply the command to a group of endpoint, such as for example all endpoints that are attached to a specified interface, or even all endpoints that are attached to a given gateway. The "any of" wildcard convention shall not be used.
EndPointId标识进入或退出服务的端点。“全部”通配符约定可用于将命令应用于一组端点，例如，连接到指定接口的所有端点，甚至连接到给定网关的所有端点。不得使用“任意”通配符约定。
The RestartMethod parameter specified the type of restart. Three values have been defined:
RestartMethod参数指定了重新启动的类型。定义了三个值：
* A "graceful" restart method indicates that the specified endpoints will Be taken out of service after the specified delay. The established connections are not yet affected, but the Call Agent should refrain to establish new connections, and should try to gracefully tear down the existing connections.
* “优雅”重新启动方法表示指定的端点将在指定的延迟后停止服务。已建立的连接尚未受到影响，但呼叫代理应避免建立新连接，并应尝试正常断开现有连接。
* A "forced" restart method indicates that the specified endpoints are taken abruptely out of service. The established connections, if any, are lost.
* “强制”重新启动方法表示指定的端点突然停止服务。已建立的连接（如果有）将丢失。
* A "restart" method indicates that service will be restored on the endpoints after the specified "restart delay." There are no connections that are currently established on the endpoints.
* “重新启动”方法表示在指定的“重新启动延迟”之后，将在终结点上恢复服务。终结点上当前没有建立连接。
* A "disconnected" method indicates that the endpoint has become disconnected and is now trying to establish connectivity. The "restart delay" specifies the number of seconds the endpoint has been disconnected. Established connections are not affected.
* “断开连接”方法表示端点已断开连接，并且正在尝试建立连接。“重启延迟”指定端点断开连接的秒数。已建立的连接不受影响。
* A "cancel-graceful" method indicates that a gateway is canceling a previously issued "graceful" restart command.
* “取消优雅”方法表示网关正在取消先前发出的“优雅”重启命令。
The optional "restart delay" parameter is expressed as a number of seconds. If the number is absent, the delay value should be considered null. In the case of the "graceful" method, a null delay indicates that the call agent should simply wait for the natural termination of the existing connections, without establishing new connections. The restart delay is always considered null in the case of the "forced" method.
可选的“重启延迟”参数表示为秒数。如果没有数字，则延迟值应视为空。在“优雅”方法的情况下，空延迟表示呼叫代理应该只等待现有连接的自然终止，而不建立新连接。在“强制”方法的情况下，重启延迟始终被视为空。
A restart delay of null for the "restart" method indicates that service has already been restored. This typically will occur after gateway startup/reboot.
“restart”方法的restart delay为null表示服务已经恢复。这通常会在网关启动/重新启动后发生。
The optional reason code parameter the cause of the restart.
可选的原因码参数表示重新启动的原因。
Gateways SHOULD send a "graceful" or "forced" RestartInProgress message as a courtesy to the Call Agent when they are taken out of service, e.g., by being shutdown, or taken out of service by a network management system, although the Call Agent cannot rely on always receiving such messages. Gateways MUST send a "restart" RestartInProgress message with a null delay to their Call Agent when they are back in service according to the restart procedure specified in Section 4.3.4 - Call Agents can rely on receiving this message. Also, gateways MUST send a "disconnected" RestartInProgress message to their current "notified entity" according to the "disconnected" procedure specified in Section 4.3.5. The "restart delay" parameter MUST NOT be used with the "forced" restart method.
当网关停止服务时（例如，由于网络管理系统关闭或停止服务），网关应向呼叫代理发送“优雅”或“强制”重新启动进度消息，作为对呼叫代理的礼貌，尽管呼叫代理不能依赖于始终接收此类消息。根据第4.3.4节“呼叫代理可以依赖于接收此消息”中规定的重新启动过程，网关在重新投入服务时，必须向呼叫代理发送一条带有空延迟的“重新启动”重新启动进程消息。此外，网关必须根据第4.3.5节中规定的“断开连接”程序，向其当前的“通知实体”发送“断开连接的”重启进程消息。“重启延迟”参数不得与“强制”重启方法一起使用。
The RestartInProgress message will be sent to the current notified entity for the EndpointId in question. It is expected that a default Call Agent, i.e., notified entity, has been provisioned for each endpoint so, after a reboot, the default Call Agent will be the notified entity for each endpoint. Gateways should take full advantage of wild- carding to minimize the number of RestartInProgress messages generated when multiple endpoints in a gateway restart and the endpoints are managed by the same Call Agent.
RestartInProgress消息将被发送到当前通知的端点ID实体。预计已为每个端点配置了默认呼叫代理（即通知实体），因此，在重新启动后，默认呼叫代理将成为每个端点的通知实体。网关应该充分利用通配符来最小化当网关中的多个端点重新启动并且端点由同一呼叫代理管理时生成的重新启动进程消息的数量。
ReturnCode is a parameter returned by the gateway. It indicates the outcome of the command and consists of an integer number optionally followed by commentary.
ReturnCode是网关返回的参数。它指示命令的结果，并由一个整数（可选后跟注释）组成。
A NotifiedEntity may additionally be returned with the response from the Call Agent:
此外，还可以通过呼叫代理的响应返回NotifiedEntity：
* If the response indicated success (return code 200 - transaction executed), the restart procedure has completed, and the NotifiedEntity returned is the new "notified entity" for the endpoint(s).
* 如果响应指示成功（返回代码200-已执行事务），则重启过程已完成，并且返回的NotifiedEntity是端点的新“通知实体”。
* If the response from the Call Agent indicated an error, the restart procedure is not yet complete, and must therefore be initiated again. If a NotifiedEntity parameter was returned, it then specifies the new "notified entity" for the endpoint(s), which must consequently be used when retrying the restart procedure.
* 如果来自呼叫代理的响应指示错误，则重新启动过程尚未完成，因此必须再次启动。如果返回NotifiedEntity参数，则它将为端点指定新的“通知实体”，因此在重试重新启动过程时必须使用该实体。
2.4. Return codes and error codes.
2.4. 返回代码和错误代码。
All MGCP commands are acknowledged. The acknowledgment carries a return code, which indicates the status of the command. The return code is an integer number, for which four ranges of values have been defined:
所有MGCP命令均已确认。确认带有一个返回码，指示命令的状态。返回码是一个整数，已为其定义了四个值范围：
* values between 100 and 199 indicate a provisional response,
* 介于100和199之间的值表示临时响应，
* values between 200 and 299 indicate a successful completion,
* 值介于200和299之间表示成功完成，
* values between 400 and 499 indicate a transient error,
* 400和499之间的值表示瞬时误差，
* values between 500 and 599 indicate a permanent error.
* 介于500和599之间的值表示永久性错误。
The values that have been already defined are listed in the following list:
已定义的值列在以下列表中：
100 The transaction is currently being executed. An actual completion message will follow on later.
100当前正在执行事务。稍后将出现实际的完成消息。
200 The requested transaction was executed normally.
200请求的事务正常执行。
250 The connection was deleted.
250该连接已被删除。
400 The transaction could not be executed, due to a transient error.
400由于暂时性错误，事务无法执行。
401 The phone is already off hook
401电话已经挂断了
402 The phone is already on hook
电话已经挂上了
403 The transaction could not be executed, because the endpoint does not have sufficient resources at this time
403无法执行事务，因为终结点此时没有足够的资源
404 Insufficient bandwidth at this time
404此时带宽不足
500 The transaction could not be executed, because the endpoint is unknown.
500由于端点未知，无法执行事务。
01 The transaction could not be executed, because the endpoint is not ready.
01无法执行事务，因为终结点未就绪。
502 The transaction could not be executed, because the endpoint does not have sufficient resources
502无法执行事务，因为终结点没有足够的资源
510 The transaction could not be executed, because a protocol error was detected.
510由于检测到协议错误，无法执行事务。
11 The transaction could not be executed, because the command contained an unrecognized extension.
11无法执行事务，因为该命令包含无法识别的扩展名。
512 The transaction could not be executed, because the gateway is not equipped to detect one of the requested events.
512无法执行事务，因为网关未配备检测请求事件之一的功能。
513 The transaction could not be executed, because the gateway is not equipped to generate one of the requested signals.
513无法执行事务，因为网关未配备生成请求的信号之一。
514 The transaction could not be executed, because the gateway cannot send the specified announcement.
514无法执行事务，因为网关无法发送指定的通知。
515 The transaction refers to an incorrect connection-id (may have been already deleted)
515事务引用了不正确的连接id（可能已被删除）
516 The transaction refers to an unknown call-id.
516事务引用一个未知的call-id。
517 Unsupported or invalid mode.
517不支持或无效的模式。
518 Unsupported or unknown package.
518不支持或未知的包。
519 Endpoint does not have a digit map.
519端点没有数字映射。
520 The transaction could not be executed, because the endpoint is "restarting".
520无法执行事务，因为终结点正在“重新启动”。
521 Endpoint redirected to another Call Agent.
521终结点已重定向到另一个呼叫代理。
522 No such event or signal.
522无此类事件或信号。
523 Unknown action or illegal combination of actions
523未知行动或行动的非法组合
524 Internal inconsistency in LocalConnectionOptions
524 LocalConnectionOptions中的内部不一致性
525 Unknown extension in LocalConnectionOptions
525 LocalConnectionOptions中的未知扩展
526 Insufficient bandwidth
526带宽不足
527 Missing RemoteConnectionDescriptor
527缺少RemoteConnectionDescriptor
528 Incompatible protocol version
528不兼容的协议版本
529 Internal hardware failure
529内部硬件故障
530 CAS signaling protocol error.
530 CAS信令协议错误。
531 failure of a grouping of trunks (e.g. facility failure).
531一组中继的故障（例如，设施故障）。
Reason-codes are used by the gateway when deleting a connection to inform the Call Agent about the reason for deleting the connection. They may also be used in a RestartInProgress command, to inform the gateway of the Restart's reason. The reason code is an integer number, and the following values have been defined:
网关在删除连接时使用原因码通知呼叫代理删除连接的原因。它们也可用于RestartInProgress命令中，以通知网关重新启动的原因。原因码是一个整数，定义了以下值：
000 Endpoint state is nominal. (This code is used only in response to audit requests.)
000端点状态为标称状态。（此代码仅用于响应审核请求。）
900 Endpoint malfunctioning
900端点故障
901 Endpoint taken out of service
901终结点停止服务
902 Loss of lower layer connectivity (e.g., downstream sync)
902下层连接丢失（例如，下游同步）
The MGCP implements the media gateway control interface as a set of transactions. The transactions are composed of a command and a mandatory response. There are eight types of command:
MGCP将媒体网关控制接口作为一组事务来实现。事务由命令和强制响应组成。有八种类型的命令：
* CreateConnection
* 创建连接
* ModifyConnection
* 修改连接
* DeleteConnection
* 删除连接
* NotificationRequest
* 通知请求
* Notify
* 通知
* AuditEndpoint
* 审核端点
* AuditConnection
* 审核连接
* RestartInProgress
* 重新启动进程
The first four commands are sent by the Call Agent to a gateway. The Notify command is sent by the gateway to the Call Agent. The gateway may also send a DeleteConnection as defined in 2.3.6. The Call Agent may send either of the Audit commands to the gateway. The Gateway may send a RestartInProgress command to the Call Agent.
前四个命令由呼叫代理发送到网关。Notify命令由网关发送给呼叫代理。网关还可以发送2.3.6中定义的DeleteConnection。呼叫代理可以向网关发送任一审核命令。网关可以向呼叫代理发送RestartInProgress命令。
All commands are composed of a Command header, optionally followed by a session description.
所有命令都由一个命令头组成，后面可选地跟一个会话描述。
All responses are composed of a Response header, optionally followed by a session description.
所有响应都由一个响应头组成，可选地后跟一个会话描述。
Headers and session descriptions are encoded as a set of text lines, separated by a carriage return and line feed character (or, optionnally, a single line-feed character). The headers are separated from the session description by an empty line.
标题和会话描述被编码为一组文本行，由回车符和换行符（或者，可选地，单个换行符）分隔。标题与会话描述之间用空行分隔。
MGCP uses a transaction identifier to correlate commands and responses. The transaction identifier is encoded as a component of the command header and repeated as a component of the response header (see section 3.2.1, 3.2.1.2 and 3.3).
MGCP使用事务标识符关联命令和响应。事务标识符编码为命令头的一个组件，并作为响应头的一个组件重复（见第3.2.1、3.2.1.2和3.3节）。
The command header is composed of:
命令头由以下部分组成：
* A command line, identifying the requested action or verb, the transaction identifier, the endpoint towards which the action is requested, and the MGCP protocol version,
* 命令行，标识请求的操作或动词、事务标识符、请求操作的端点以及MGCP协议版本，
* A set of parameter lines, composed of a parameter name followed by a parameter value.
* 一组参数行，由参数名和参数值组成。
Unless otherwise noted or dictated by other referenced standards, each component in the command header is case insensitive. This goes for verbs as well as parameters and values, and all comparisons MUST treat upper and lower case as well as combinations of these as being equal.
除非其他参考标准另有说明或规定，否则命令头中的每个组件都不区分大小写。这适用于动词以及参数和值，所有比较都必须将大小写以及它们的组合视为相等。
The command line is composed of:
命令行由以下部分组成：
* The name of the requested verb,
* 请求的动词的名称，
* The identification of the transaction,
* 交易的识别，
* The name of the endpoint that should execute the command (in notifications or restarts, the name of the endpoint that is issuing the command),
* 应执行命令的端点的名称（在通知或重新启动中，发出命令的端点的名称），
* The protocol version.
* 协议版本。
These four items are encoded as strings of printable ASCII characters, separated by white spaces, i.e. the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one ASCII space separator.
这四个项目被编码为可打印ASCII字符的字符串，由空格分隔，即ASCII空格（0x20）或表格（0x09）字符。建议只使用一个ASCII空格分隔符。
The verbs that can be requested are encoded as four letter upper or lower case ASCII codes (comparisons should be case insensitive) as defined in the following table:
可请求的动词编码为四个字母的大写或小写ASCII代码（比较应不区分大小写），如下表所示：
______________________________
| Verb | Code|
|______________________|______|
| EndpointConfiguration| EPCF|
| CreateConnection | CRCX|
| ModifyConnection | MDCX|
| DeleteConnection | DLCX|
| NotificationRequest | RQNT|
| Notify | NTFY|
| AuditEndpoint | AUEP|
| AuditConnection | AUCX|
| RestartInProgress | RSIP|
|______________________|______|
______________________________
| Verb | Code|
|______________________|______|
| EndpointConfiguration| EPCF|
| CreateConnection | CRCX|
| ModifyConnection | MDCX|
| DeleteConnection | DLCX|
| NotificationRequest | RQNT|
| Notify | NTFY|
| AuditEndpoint | AUEP|
| AuditConnection | AUCX|
| RestartInProgress | RSIP|
|______________________|______|
The transaction identifier is encoded as a string of up to 9 decimal digits. In the command lines, it immediately follows the coding of the verb.
事务标识符编码为最多9位十进制数字的字符串。在命令行中，它紧跟着动词的编码。
New verbs may be defined in further versions of the protocol. It may be necessary, for experimentation purposes, to use new verbs before they are sanctioned in a published version of this protocol. Experimental verbs should be identified by a four letter code starting with the letter X, such as for example XPER.
新的动词可在协议的进一步版本中定义。出于实验目的，可能有必要在本协议的发布版本中批准新动词之前使用新动词。实验动词应该用以字母X开头的四个字母的代码来识别，例如XPER。
MGCP uses a transaction identifier to correlate commands and responses. A gateway supports two separate transaction identifier name spaces:
MGCP使用事务标识符关联命令和响应。网关支持两个独立的事务标识符名称空间：
a transaction identifier name space for sending transactions, and
用于发送事务的事务标识符名称空间，以及
a transaction identifier name space for receiving transactions.
用于接收事务的事务标识符名称空间。
At a minimum, transaction identifiers for commands sent to a given gateway MUST be unique for the maximum lifetime of the transactions within the collection of Call Agents that control that gateway. Thus,
至少，发送到给定网关的命令的事务标识符在控制该网关的调用代理集合中的事务的最大生存期内必须是唯一的。因此
regardless of the sending Call Agent, gateways can always detect duplicate transactions by simply examining the transaction identifier. The coordination of these transaction identifiers between Call Agents is outside the scope of this specification though.
不管发送呼叫代理是什么，网关总是可以通过简单地检查事务标识符来检测重复的事务。不过，调用代理之间这些事务标识符的协调不在本规范的范围之内。
Transaction identifiers for all commands sent from a given gateway MUST be unique for the maximum lifetime of the transactions regardless of which Call Agent the command is sent to. Thus, a Call Agent can always detect a duplicate transaction from a gateway by the combination of the domain-name of the endpoint and the transaction identifier.
在事务的最长生存期内，从给定网关发送的所有命令的事务标识符必须是唯一的，无论命令发送到哪个调用代理。因此，呼叫代理始终可以通过端点的域名和事务标识符的组合来检测来自网关的重复事务。
The transaction identifier is encoded as a string of up to nine decimal digits. In the command lines, it immediately follows the coding of the verb.
事务标识符编码为最多九位十进制数字的字符串。在命令行中，它紧跟着动词的编码。
Transaction identifiers have values between 1 and 999999999. An MGCP entity MUST NOT reuse a transaction identifier more quickly than three minutes after completion of the previous command in which the identifier was used.
事务标识符的值介于1和99999999之间。MGCP实体重用事务标识符的速度不得超过使用该标识符的上一个命令完成后三分钟。
The endpoint identifiers and entity names are encoded as case insensitive e-mail addresses, as defined in RFC 821. In these addresses, the domain name identifies the system where the endpoint is attached, while the left side identifies a specific endpoint on that system.
端点标识符和实体名称编码为不区分大小写的电子邮件地址，如RFC 821中所定义。在这些地址中，域名标识端点所连接的系统，而左侧标识该系统上的特定端点。
Examples of such addresses can be:
此类地址的示例可以是：
______________________________________________________________________
| hrd4/56@gw23.example.net | Circuit number 56 in |
| | interface "hrd4" of the Gateway 23 |
| | of the "Example" network |
| Call-agent@ca.example.net | Call Agent for the |
| | "example" network |
| Busy-signal@ann12.example.net| The "busy signal" virtual |
| | endpoint in the announcement |
| | server number 12. |
|______________________________|______________________________________|
______________________________________________________________________
| hrd4/56@gw23.example.net | Circuit number 56 in |
| | interface "hrd4" of the Gateway 23 |
| | of the "Example" network |
| Call-agent@ca.example.net | Call Agent for the |
| | "example" network |
| Busy-signal@ann12.example.net| The "busy signal" virtual |
| | endpoint in the announcement |
| | server number 12. |
|______________________________|______________________________________|
The name of notified entities is expressed with the same syntax, with the possible addition of a port number as in:
通知实体的名称用相同的语法表示，并可能添加端口号，如所示：
Call-agent@ca.example.net:5234
召唤-agent@ca.example.net:5234
In case the port number is omitted, the default MGCP port (2427) will be used.
如果省略端口号，将使用默认的MGCP端口（2427）。
The protocol version is coded as the key word MGCP followed by a white space and the version number, and optionally followed by a profile name.. The version number is composed of a major version, coded by a decimal number, a dot, and a minor version number, coded as a decimal number. The version described in this document is version 1.0.
协议版本编码为关键字MGCP，后跟空格和版本号，还可以选择后跟配置文件名称。。版本号由一个主要版本（由十进制数字编码）、一个点和一个次要版本（由十进制数字编码）组成。本文档中描述的版本为1.0版。
The profile name, if present, is represented by a white-space separated strings of visible (printable) characters extending to the end of the line. Profile names may be defined for user communities who want to apply restrictions or other profiling to MGCP.
配置文件名称（如果存在）由延伸到行尾的可见（可打印）字符字符串（以空格分隔）表示。可以为想要对MGCP应用限制或其他配置文件的用户社区定义配置文件名称。
In the initial messages, the version will be coded as:
在初始消息中，版本将编码为：
MGCP 1.0
MGCP 1.0
Parameter lines are composed of a parameter name, which in most cases is composed of a single upper case character, followed by a colon, a white space and the parameter value. The parameter that can be present in commands are defined in the following table:
参数行由参数名称组成，在大多数情况下，参数名称由单个大写字符组成，后跟冒号、空格和参数值。下表定义了命令中可能存在的参数：
_______________________________________________________________________
|Parameter name | Code| Parameter value |
|______________________|______|_______________________________________|
|ResponseAck | K | see description |
|BearerInformation | B | see description |
|CallId | C | Hexadecimal string, at most 32 chars.|
|ConnectionId | I | Hexadecimal string, at most 32 chars.|
|NotifiedEntity | N | An identifier, in RFC 821 format, |
| | | composed of an arbitrary string and |
| | | of the domain name of the requesting |
| | | entity, possibly completed by a port |
| | | number, as in: |
| | | Call-agent@ca.example.net:5234 |
|RequestIdentifier | X | Hexadecimal string, at most 32 chars.|
|LocalConnectionOptions| L | See description |
|Connection Mode | M | See description |
|RequestedEvents | R | See description |
|SignalRequests | S | See description |
|DigitMap | D | A text encoding of a digit map |
|ObservedEvents | O | See description |
|ConnectionParameters | P | See description |
|ReasonCode | E | An arbitrary character string |
|SpecificEndpointID | Z | An identifier, in RFC 821 format, |
| | | composed of an arbitrary string, |
| | | followed by an "@" followed by the |
| | | domain name of the gateway to which |
| | | this endpoint is attached. |
|Second Endpoint ID | Z2 | Endpoint Id. |
|SecondConnectionId | I2 | Connection Id. |
|RequestedInfo | F | See description |
|QuarantineHandling | Q | See description |
|DetectEvents | T | See Description |
|RestartMethod | RM | See description |
|RestartDelay | RD | A number of seconds, encoded as |
| | | a decimal number |
|EventStates | ES | See description |
|Capabilities | A | See description |
|______________________|______|_______________________________________|
|RemoteConnection | RC | Session Description |
|Descriptor | | |
|LocalConnection | LC | Session Description |
|Descriptor | | |
|______________________|______|_______________________________________|
_______________________________________________________________________
|Parameter name | Code| Parameter value |
|______________________|______|_______________________________________|
|ResponseAck | K | see description |
|BearerInformation | B | see description |
|CallId | C | Hexadecimal string, at most 32 chars.|
|ConnectionId | I | Hexadecimal string, at most 32 chars.|
|NotifiedEntity | N | An identifier, in RFC 821 format, |
| | | composed of an arbitrary string and |
| | | of the domain name of the requesting |
| | | entity, possibly completed by a port |
| | | number, as in: |
| | | Call-agent@ca.example.net:5234 |
|RequestIdentifier | X | Hexadecimal string, at most 32 chars.|
|LocalConnectionOptions| L | See description |
|Connection Mode | M | See description |
|RequestedEvents | R | See description |
|SignalRequests | S | See description |
|DigitMap | D | A text encoding of a digit map |
|ObservedEvents | O | See description |
|ConnectionParameters | P | See description |
|ReasonCode | E | An arbitrary character string |
|SpecificEndpointID | Z | An identifier, in RFC 821 format, |
| | | composed of an arbitrary string, |
| | | followed by an "@" followed by the |
| | | domain name of the gateway to which |
| | | this endpoint is attached. |
|Second Endpoint ID | Z2 | Endpoint Id. |
|SecondConnectionId | I2 | Connection Id. |
|RequestedInfo | F | See description |
|QuarantineHandling | Q | See description |
|DetectEvents | T | See Description |
|RestartMethod | RM | See description |
|RestartDelay | RD | A number of seconds, encoded as |
| | | a decimal number |
|EventStates | ES | See description |
|Capabilities | A | See description |
|______________________|______|_______________________________________|
|RemoteConnection | RC | Session Description |
|Descriptor | | |
|LocalConnection | LC | Session Description |
|Descriptor | | |
|______________________|______|_______________________________________|
The parameters are not necessarily present in all commands. The following table provides the association between parameters and commands. The letter M stands for mandatory, O for optional and F for forbidden.
参数不一定存在于所有命令中。下表提供了参数和命令之间的关联。字母M代表强制，O代表可选，F代表禁止。
___________________________________________________________________
| Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS|
| | CF| CX| CX| CX| NT| FY| EP| CX| IP|
|_____________________|____|____|____|____|____|____|____|____|____|
| ResponseAck | O | O | O | O | O | O | O | O | O |
| BearerInformation | M | O | O | O | O | F | F | F | F |
| CallId | F | M | M | O | F | F | F | F | F |
| ConnectionId | F | F | M | O | F | F | F | M | F |
| RequestIdentifier | F | O+| O+| O+| M | M | F | F | F |
| LocalConnection | F | O | O | F | F | F | F | F | F |
| Options | | | | | | | | | |
| Connection Mode | F | M | M | F | F | F | F | F | F |
| RequestedEvents | F | O | O | O | O*| F | F | F | F |
| SignalRequests | F | O | O | O | O*| F | F | F | F |
| NotifiedEntity | F | O | O | O | O | O | F | F | F |
| ReasonCode | F | F | F | O | F | F | F | F | O |
| ObservedEvents | F | F | F | F | F | M | F | F | F |
| DigitMap | F | O | O | O | O | F | F | F | F |
| Connection | F | F | F | O | F | F | F | F | F |
| parameters | | | | | | | | | |
| Specific Endpoint ID| F | F | F | F | F | F | F | F | F |
| Second Endpoint ID | F | O | F | F | F | F | F | F | F |
| RequestedInfo | F | F | F | F | F | F | M | M | F |
| QuarantineHandling | F | O | O | O | O | F | F | F | F |
| DetectEvents | F | O | O | O | O | F | F | F | F |
| EventStates | F | F | F | F | F | F | F | F | F |
| RestartMethod | F | F | F | F | F | F | F | F | M |
| RestartDelay | F | F | F | F | F | F | F | F | O |
| SecondConnectionID | F | F | F | F | F | F | F | F | F |
| Capabilities | F | F | F | F | F | F | F | F | F |
|_____________________|____|____|____|____|____|____|____|____|____|
| RemoteConnection | F | O | O | F | F | F | F | F | F |
| Descriptor | | | | | | | | | |
| LocalConnection | F | F | F | F | F | F | F | F | F |
| Descriptor | | | | | | | | | |
|_____________________|____|____|____|____|____|____|____|____|____|
___________________________________________________________________
| Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS|
| | CF| CX| CX| CX| NT| FY| EP| CX| IP|
|_____________________|____|____|____|____|____|____|____|____|____|
| ResponseAck | O | O | O | O | O | O | O | O | O |
| BearerInformation | M | O | O | O | O | F | F | F | F |
| CallId | F | M | M | O | F | F | F | F | F |
| ConnectionId | F | F | M | O | F | F | F | M | F |
| RequestIdentifier | F | O+| O+| O+| M | M | F | F | F |
| LocalConnection | F | O | O | F | F | F | F | F | F |
| Options | | | | | | | | | |
| Connection Mode | F | M | M | F | F | F | F | F | F |
| RequestedEvents | F | O | O | O | O*| F | F | F | F |
| SignalRequests | F | O | O | O | O*| F | F | F | F |
| NotifiedEntity | F | O | O | O | O | O | F | F | F |
| ReasonCode | F | F | F | O | F | F | F | F | O |
| ObservedEvents | F | F | F | F | F | M | F | F | F |
| DigitMap | F | O | O | O | O | F | F | F | F |
| Connection | F | F | F | O | F | F | F | F | F |
| parameters | | | | | | | | | |
| Specific Endpoint ID| F | F | F | F | F | F | F | F | F |
| Second Endpoint ID | F | O | F | F | F | F | F | F | F |
| RequestedInfo | F | F | F | F | F | F | M | M | F |
| QuarantineHandling | F | O | O | O | O | F | F | F | F |
| DetectEvents | F | O | O | O | O | F | F | F | F |
| EventStates | F | F | F | F | F | F | F | F | F |
| RestartMethod | F | F | F | F | F | F | F | F | M |
| RestartDelay | F | F | F | F | F | F | F | F | O |
| SecondConnectionID | F | F | F | F | F | F | F | F | F |
| Capabilities | F | F | F | F | F | F | F | F | F |
|_____________________|____|____|____|____|____|____|____|____|____|
| RemoteConnection | F | O | O | F | F | F | F | F | F |
| Descriptor | | | | | | | | | |
| LocalConnection | F | F | F | F | F | F | F | F | F |
| Descriptor | | | | | | | | | |
|_____________________|____|____|____|____|____|____|____|____|____|
Note (+) that the RequestIdentifier parameter is optional in connection creation, modification and deletion commands, but that it becomes mandatory if the command contains an encapsulated notification request.
请注意（+）RequestIdentifier参数在连接创建、修改和删除命令中是可选的，但如果该命令包含封装的通知请求，则它将成为必需的。
Note (*) that the RequestedEvents and SignalRequests parameters are optional in the NotificationRequest. If these parameters are omitted, the corresponding lists will be considered empty.
注意（*）RequestedEvents和SignalRequests参数在NotificationRequest中是可选的。如果省略这些参数，则相应的列表将被视为空。
If implementers need to experiment with new parameters, for example when developing a new application of MGCP, they should identify these parameters by names that start with the string "X-" or "X+", such as for example:
如果实施者需要试验新参数，例如在开发MGCP的新应用程序时，他们应该通过以字符串“X-”或“X+”开头的名称来识别这些参数，例如：
X-FlowerOfTheDay: Daisy
今天的X-花：黛西
Parameter names that start with "X+" are critical parameter extensions. An MGCP entity that receives a critical parameter extension that it cannot understand should refuse to execute the command. It should respond with an error code 511 (Unrecognized extension).
以“X+”开头的参数名称是关键的参数扩展。接收到无法理解的关键参数扩展的MGCP实体应拒绝执行该命令。它应该以错误代码511（无法识别的扩展名）响应。
Parameter names that start with "X-" are non critical parameter extensions. An MGCP entity that receives a non critical parameter extension that it cannot understand can safely ignore that parameter.
以“X-”开头的参数名称是非关键参数扩展。接收到无法理解的非关键参数扩展的MGCP实体可以安全地忽略该参数。
The response acknowledgement attribute is used to managed the "at-most-once" facility described in the "transmission over UDP" section. It contains a comma separated list of "confirmed transaction-id ranges".
响应确认属性用于管理“通过UDP传输”部分中描述的“最多一次”设施。它包含一个逗号分隔的“已确认事务id范围”列表。
Each "confirmed transaction-id ranges" is composed of either one decimal number, when the range includes exactly one transaction, or two decimal numbers separated by a single hyphen, describing the lower and higher transaction identifiers included in the range.
每个“已确认的交易id范围”由一个十进制数（当范围仅包含一个交易时）或两个十进制数（由一个连字符分隔）组成，用于描述范围中包含的较低和较高的交易标识符。
An example of response acknowledgement is:
响应确认的一个示例是：
K: 6234-6255, 6257, 19030-19044
K:6234-6255625719030-19044
The local connection options describe the operational parameters that the Call Agent suggests to the gateway. These parameters are:
本地连接选项描述呼叫代理向网关建议的操作参数。这些参数是：
* The packetization period in milliseconds, encoded as the keyword "p", followed by a colon and a decimal number. If the Call Agent specifies a range of values, the range will be specified as two decimal numbers separated by an hyphen.
* 打包周期（以毫秒为单位），编码为关键字“p”，后跟冒号和十进制数。如果调用代理指定一个值范围，则该范围将指定为两个由连字符分隔的十进制数字。
* The preferred type of compression algorithm, encoded as the keyword "a", followed by a colon and a character string. If the Call Agent specifies a list of values, these values will be separated by a semicolon.
* 首选的压缩算法类型，编码为关键字“a”，后跟冒号和字符串。如果调用代理指定值列表，则这些值将用分号分隔。
* The bandwidth in kilobits per second (1000 bits per second), encoded as the keyword "b", followed by a colon and a decimal number. If the Call Agent specifies a range of values, the range will be specified as two decimal numbers separated by an hyphen.
* 以千比特每秒（1000比特每秒）为单位的带宽，编码为关键字“b”，后跟冒号和十进制数。如果调用代理指定一个值范围，则该范围将指定为两个由连字符分隔的十进制数字。
* The echo cancellation parameter, encoded as the keyword "e", followed by a colon and the value "on" or "off".
* 回声消除参数，编码为关键字“e”，后跟冒号和值“开”或“关”。
* The gain control parameter, encoded as the keyword "gc", followed by a colon a value which can be either the keyword "auto" or a decimal number (positive or negative) representing the number of decibels of gain.
* 增益控制参数，编码为关键字“gc”，后跟一个冒号，该冒号可以是关键字“auto”或表示增益分贝数的十进制数（正或负）。
* The silence suppression parameter, encoded as the keyword "s", followed by a colon and the value "on" or "off".
* 静音抑制参数，编码为关键字“s”，后跟冒号和值“开”或“关”。
* The type of service parameter, encoded as the keyword "t", followed by a colon and the value encoded as two hexadecimal digits.
* 服务参数的类型，编码为关键字“t”，后跟冒号，值编码为两个十六进制数字。
* The resource reservation parameter, encoded as the keyword "r", followed by a colon and the value "g" (guaranteed service), "cl" (controlled load) or "be" (best effort).
* 资源保留参数，编码为关键字“r”，后跟冒号和值“g”（保证服务）、“cl”（控制负载）或“be”（尽力）。
* The encryption key, encoded as the keyword "k" followed by a colon and a key specification, as defined for the parameter "K" of SDP (RFC 2327).
* 加密密钥，编码为关键字“k”，后跟冒号和密钥规范，如SDP（RFC 2327）的参数“k”所定义。
* The type of network, encoded as the keyword "nt" followed by a colon and the type of network encoded as the keyword "IN", "ATM" or "LOCAL".
* 网络类型，编码为关键字“nt”，后跟冒号，网络类型编码为关键字“IN”、“ATM”或“LOCAL”。
Each of the parameters is optional. When several parameters are present, the values are separated by a comma.
每个参数都是可选的。当存在多个参数时，这些值用逗号分隔。
Examples of connection descriptors are:
连接描述符的示例包括：
L: p:10, a:PCMU
L: p:10, a:G726-32
L: p:10-20, b:64
L: b:32-64, e:off
L: p:10, a:PCMU
L: p:10, a:G726-32
L: p:10-20, b:64
L: b:32-64, e:off
These set of attributes may be extended by extension attributes.
这些属性集可以通过扩展属性进行扩展。
Extension attributes are composed of an attribute name, followed by a semi-colon and by an attribute value. The attribute name should start by the two characters "x+", for a mandatory extensions, or "x-", for a non mandatory extension. If a gateway receives a mandatory extension attribute that it does not recognize, it should reject the command with an error code 525 (Unknown extension in LocalConnectionOptions).
扩展属性由属性名、分号和属性值组成。属性名称应以两个字符“x+”开头（对于强制扩展名），或以“x-”开头（对于非强制扩展名）。如果网关接收到它无法识别的强制扩展属性，则应拒绝该命令，并返回错误代码525（LocalConnectionOptions中的未知扩展名）。
Capabilities inform the Call Agent about endpoints' capabilities when audited. The encoding of capabilities is based on the Local Connection Options encoding for the parameters that are common to both. In addition, capabilities can also contain a list of supported packages, and a list of supported modes.
功能在审核时通知呼叫代理端点的功能。功能的编码基于本地连接选项编码，该选项用于对两者通用的参数进行编码。此外，功能还可以包含受支持包的列表和受支持模式的列表。
The parameters used are:
使用的参数包括：
* A list of supported codecs. The following parameters will apply to all codecs specified in this list. If there is a need to specify that some parameters, such as e.g. silence suppression, are only compatible with some codecs, then the gateway will return several LocalConnectionOptions parameters, one for each set of codecs.
* 支持的编解码器列表。以下参数将应用于此列表中指定的所有编解码器。如果需要指定某些参数（例如静音抑制）仅与某些编解码器兼容，则网关将返回多个LocalConnectionOptions参数，每组编解码器一个。
Packetization Period: A range may be specified.
打包周期：可以指定一个范围。
Bandwidth: A range corresponding to the range for packetization periods may be specified (assuming no silence suppression). If absent, the values will be deduced from the codec type.
带宽：可以指定与打包周期范围相对应的范围（假设没有静音抑制）。如果不存在，则将从编解码器类型推断值。
Echo Cancellation: "on" if echo cancellation is supported for this codec, "off" otherwise. The default is support.
回声消除：如果此编解码器支持回声消除，则为“开”，否则为“关”。默认值是支持。
Silence Suppression: "on" if silence suppression is supported for this codec, "off" otherwise. The default is support.
静音抑制：“开”如果此编解码器支持静音抑制，则“关”否则。默认值是支持。
Gain Control: "0" if gain control is not supported. The default is support.
增益控制：如果不支持增益控制，则为“0”。默认值是支持。
Type of Service: The value "0" indicates no support for type of service, all other values indicate support for type of service. The default is support.
服务类型：值“0”表示不支持服务类型，所有其他值表示支持服务类型。默认值是支持。
Resource Reservation: The parameter indicates the reservation services that are supported, in addition to best effort. The value "g" is encoded when the gateway supports both the guaranteed and the controlled load service, "cl" when only the controlled load service is supported. The default is "best effort."
资源预留：该参数表示除尽力而为外，还支持的预留服务。当网关同时支持保证负载服务和控制负载服务时，对值“g”进行编码；当仅支持控制负载服务时，对值“cl”进行编码。默认值为“尽力而为”
Encryption Key: Encoding any value indicates support for encryption. Default is no support.
加密密钥：对任何值进行编码表示支持加密。默认为不支持。
Type of network: The keyword "nt", followed by a colon and a semicolon separated list of supported network types. This parameter is optional.
网络类型：关键字“nt”，后跟以冒号和分号分隔的受支持网络类型列表。此参数是可选的。
Event Packages The event packages supported by this endpoint encoded as the keyword "v", followed by a colon and a character string. If a list of values is specified, these values will be separated by a semicolon. The first value specified will be the default package for that endpoint.
事件包此端点支持的事件包编码为关键字“v”，后跟冒号和字符串。如果指定了值列表，这些值将用分号分隔。指定的第一个值将是该端点的默认包。
Modes The modes supported by this endpoint encoded as the keyword "m", followed by a colon and a semicolon-separated list of supported connection modes for this endpoint.
模式此端点支持的模式编码为关键字“m”，后跟一个冒号和分号分隔的此端点支持的连接模式列表。
Connection parameters are encoded as a string of type and value pairs, where the type is a either letter identifier of the parameter or an extension type, and the value a decimal integer. Types are separated from value by an `=' sign. Parameters are encoded from each other by a comma.
连接参数编码为类型和值对的字符串，其中类型为参数的字母标识符或扩展类型，值为十进制整数。类型和值之间用“=”符号分隔。参数之间用逗号编码。
The connection parameter types are specified in the following table:
下表中指定了连接参数类型：
__________________________________________________________________
| Connection parameter| Code| Connection parameter |
| name | | value |
|_____________________|______|____________________________________|
| Packets sent | PS | The number of packets that |
| | | were sent on the connection. |
| Octets sent | OS | The number of octets that |
| | | were sent on the connection. |
| Packets received | PR | The number of packets that |
| | | were received on the connection. |
| Octets received | OR | The number of octets that |
| | | were received on the connection. |
| Packets lost | PL | The number of packets that |
| | | were not received on the |
| | | connection, as deduced from |
| | | gaps in the sequence number. |
| Jitter | JI | The average inter-packet arrival |
| | | jitter, in milliseconds, |
| | | expressed as an integer number. |
| Latency | LA | Average latency, in milliseconds, |
| | | expressed as an integer number. |
|_____________________|______|____________________________________|
__________________________________________________________________
| Connection parameter| Code| Connection parameter |
| name | | value |
|_____________________|______|____________________________________|
| Packets sent | PS | The number of packets that |
| | | were sent on the connection. |
| Octets sent | OS | The number of octets that |
| | | were sent on the connection. |
| Packets received | PR | The number of packets that |
| | | were received on the connection. |
| Octets received | OR | The number of octets that |
| | | were received on the connection. |
| Packets lost | PL | The number of packets that |
| | | were not received on the |
| | | connection, as deduced from |
| | | gaps in the sequence number. |
| Jitter | JI | The average inter-packet arrival |
| | | jitter, in milliseconds, |
| | | expressed as an integer number. |
| Latency | LA | Average latency, in milliseconds, |
| | | expressed as an integer number. |
|_____________________|______|____________________________________|
Extension parameters names are composed of the string "X-" followed by a two letters extension parameter name. Call agents that received unrecognized extensions shall silently ignore these extensions.
扩展参数名称由字符串“X-”和两个字母的扩展参数名称组成。接收到无法识别的分机的呼叫代理应自动忽略这些分机。
An example of connection parameter encoding is:
连接参数编码的一个示例是：
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
Reason codes are three-digit numeric values. The reason code is optionally followed by a white space and commentary, e.g.:
原因代码是三位数字值。原因码后面可以选择空白和注释，例如：
900 Endpoint malfunctioning
900端点故障
A list of reason-codes can be found in Section 2.5.
原因代码列表见第2.5节。
The connection mode describes the mode of operation of the connection. The possible values are:
连接模式描述连接的操作模式。可能的值为：
________________________________________________________
| Mode | Meaning |
|____________|__________________________________________|
| M: sendonly| The gateway should only send packets |
| M: recvonly| The gateway should only receive packets |
| M: sendrecv| The gateway should send |
| | and receive packets |
| M: confrnce| The gateway should place |
| | the connection in conference mode |
| M: inactive| The gateway should neither |
| | send nor receive packets |
| M: loopback| The gateway should place |
| | the circuit in loopback mode. |
| M: conttest| The gateway should place |
| | the circuit in test mode. |
| M: netwloop| The gateway should place |
| | the connection in network loopback mode.|
| M: netwtest| The gateway should place |
| | the connection in network |
| | continuity test mode. |
| M: data | The gateway should use the circuit |
| | for network access for data |
| | (e.g., PPP, SLIP, etc.). |
|____________|__________________________________________|
________________________________________________________
| Mode | Meaning |
|____________|__________________________________________|
| M: sendonly| The gateway should only send packets |
| M: recvonly| The gateway should only receive packets |
| M: sendrecv| The gateway should send |
| | and receive packets |
| M: confrnce| The gateway should place |
| | the connection in conference mode |
| M: inactive| The gateway should neither |
| | send nor receive packets |
| M: loopback| The gateway should place |
| | the circuit in loopback mode. |
| M: conttest| The gateway should place |
| | the circuit in test mode. |
| M: netwloop| The gateway should place |
| | the connection in network loopback mode.|
| M: netwtest| The gateway should place |
| | the connection in network |
| | continuity test mode. |
| M: data | The gateway should use the circuit |
| | for network access for data |
| | (e.g., PPP, SLIP, etc.). |
|____________|__________________________________________|
Event names are composed of an optional package name, separated by a slash (/) from the name of the actual event. The event name can optionally be followed by an at sign (@) and the identifier of a connection on which the event should be observed. Event names are used in the RequestedEvents, SignalRequests and ObservedEvents parameter.
事件名称由可选的包名称组成，由斜杠（/）与实际事件名称分隔。事件名称后面可以有at符号（@）和应该观察事件的连接的标识符。事件名称用于RequestedEvents、SignalRequests和ObservedEvents参数。
Each signal has one of the following signal-types associated with: On/Off (OO), Time-out (TO), Brief (BR). (These signal types are specified in the package definitions, and are not present in the messages.) On/Off signals can be parameterized with a "+" to turn the signal on, or a "-" to turn the signal off. If an on/off signal is not parameterized, the signal is turned on. Both of the following will turn the vmwi signal on:
每个信号都有以下与之相关的信号类型之一：开/关（OO）、超时（TO）、简短（BR）。（这些信号类型在包定义中指定，在消息中不存在。）可以用“+”参数化开/关信号，或用“-”参数化关信号。如果on/off信号未参数化，则该信号开启。以下两项都将打开vmwi信号：
vmwi(+), vmwi
vmwi（+），vmwi
The following are valid examples of event names:
以下是事件名称的有效示例：
____________________________________________________________
| L/hu | on-hook transition, in the line package |
| F/0 | digit 0 in the MF package |
| fh | Flash-hook, assuming that the line package|
| | is a default package for the end point. |
| G/rt@0A3F58 | Ring back signal on |
| | connection "0A3F58". |
|_____________|_____________________________________________|
____________________________________________________________
| L/hu | on-hook transition, in the line package |
| F/0 | digit 0 in the MF package |
| fh | Flash-hook, assuming that the line package|
| | is a default package for the end point. |
| G/rt@0A3F58 | Ring back signal on |
| | connection "0A3F58". |
|_____________|_____________________________________________|
In addition, the range and wildcard notation of events can be used, instead of individual names, in the RequestedEvents and DetectEvents parameters. The star sign can be used to denote "all connections", and the dollar sign can be used to denote the "current" connection. The following are valid examples of such notations:
此外，在RequestedEvents和DetectedEvents参数中，可以使用事件的范围和通配符符号，而不是单个名称。星号可用于表示“所有连接”，美元符号可用于表示“当前”连接。以下是此类标记的有效示例：
__________________________________________________________
| M/[0-9] | Digits 0 to 9 in the MF package |
| fh | Flash-hook, assuming that the line package|
| | is a default package for the end point. |
| [0-9*#A-D]| All digits and letters in the DTMF |
| | packages (default for endpoint). |
| T/$ | All events in the trunk packages. |
| R/qa@* | The quality alert event in all |
| | connections |
| R/rt@$ | Ringback on current connection |
|___________|_____________________________________________|
__________________________________________________________
| M/[0-9] | Digits 0 to 9 in the MF package |
| fh | Flash-hook, assuming that the line package|
| | is a default package for the end point. |
| [0-9*#A-D]| All digits and letters in the DTMF |
| | packages (default for endpoint). |
| T/$ | All events in the trunk packages. |
| R/qa@* | The quality alert event in all |
| | connections |
| R/rt@$ | Ringback on current connection |
|___________|_____________________________________________|
The RequestedEvent parameter provides the list of events that have been requested. The event codes are described in the previous section.
RequestedEvent参数提供已请求的事件列表。事件代码在上一节中介绍。
Each event can be qualified by a requested action, or by a list of actions. The actions, when specified, are encoded as a list of keywords, enclosed in parenthesis and separated by commas. The codes for the various actions are:
可以通过请求的操作或操作列表来限定每个事件。指定操作时，将其编码为关键字列表，用括号括起，并用逗号分隔。各种操作的代码为：
______________________________________
| Action | Code|
|______________________________|______|
| Notify immediately | N |
| Accumulate | A |
| Treat according to digit map | D |
| Swap | S |
| Ignore | I |
| Keep Signal(s) active | K |
| Embedded Notification Request| E |
|______________________________|______|
______________________________________
| Action | Code|
|______________________________|______|
| Notify immediately | N |
| Accumulate | A |
| Treat according to digit map | D |
| Swap | S |
| Ignore | I |
| Keep Signal(s) active | K |
| Embedded Notification Request| E |
|______________________________|______|
When no action is specified, the default action is to notify the event. This means that, for example, ft and ft(N) are equivalent. Events that are not listed are ignored.
未指定任何操作时，默认操作是通知事件。这意味着，例如，ft和ft（N）是等效的。未列出的事件将被忽略。
The digit-map action can only be specified for the digits, letters and interdigit timers in the MF and DTMF packages, or in other packages that would define the encoding of digits and timers.
只能为MF和DTMF包中的数字、字母和叉指计时器指定数字映射操作，或在定义数字和计时器编码的其他包中指定数字映射操作。
The requested list is encoded on a single line, with event/action groups separated by commas. Examples of RequestedEvents encoding are:
请求的列表编码在一行上，事件/操作组用逗号分隔。RequestedEvents编码的示例包括：
R: hu(N), hf(S,N)
R: hu(N), [0-9#T](D)
R: hu(N), hf(S,N)
R: hu(N), [0-9#T](D)
In the case of the "enable" action, the embedded notification request parameters are encoded as a list of up to three parameter groups, separated by commas. Each group start by a one letter identifier, followed by a list of parameters enclosed between parenthesis. The first optional parameter group, identified by the letter "R", is the enabled value of the RequestedEvents parameter. The second optional group, identified by the letter "S", is the enabled value of the SignalRequests parameter. The third optional group, identified by the letter "D", is the enabled value of the DigitMap. (Note that some existing implementation may encode these three components in a different order.)
在“启用”操作的情况下，嵌入式通知请求参数被编码为最多三个参数组的列表，由逗号分隔。每个组都以一个单字母标识符开头，后面是括号中包含的参数列表。由字母“R”标识的第一个可选参数组是RequestedEvents参数的启用值。第二个可选组由字母“S”标识，是SignalRequests参数的启用值。第三个可选组由字母“D”标识，是DigitMap的启用值。（请注意，某些现有实现可能会以不同的顺序对这三个组件进行编码。）
If the RequestedEvents is not present, the parameter will be set to a null value. If the SignalRequest is not present, the parameter will be set to a null value. If the DigitMap is absent, the current value should be used. The following are valid examples of embedded requests:
如果RequestedEvents不存在，则该参数将设置为空值。如果SignalRequest不存在，参数将设置为空值。如果缺少DigitMap，则应使用当前值。以下是嵌入式请求的有效示例：
R: hd(E(R([0-9#T](D),hu(N)),S(dl),D([0-9].[#T])))
R: hd(E(R([0-9#T](D),hu(N)),S(dl)))
R: hd(E(R([0-9#T](D),hu(N)),S(dl),D([0-9].[#T])))
R: hd(E(R([0-9#T](D),hu(N)),S(dl)))
The SignalRequests parameter provides the name of the signals that have been requested. Each signal is identified by a name, as indicated in the previous section.
SignalRequests参数提供已请求的信号的名称。每个信号由一个名称标识，如前一节所示。
Several signals, such as for example announcement or ADSI display, can be qualified by additional parameters:
多个信号，例如公告或ADSI显示，可通过附加参数进行鉴定：
* the name and parameters of the announcement,
* 公告的名称和参数，
* the string that should be displayed.
* 应显示的字符串。
These parameters will be encoded as a set of UTF8 character strings,
spearated by comams and enclosed within parenthesis, as in:
S: adsi("123456 Francois Gerard")
S: ann(no-such-number, 1234567)
These parameters will be encoded as a set of UTF8 character strings,
spearated by comams and enclosed within parenthesis, as in:
S: adsi("123456 Francois Gerard")
S: ann(no-such-number, 1234567)
When several signals are requested, their codes are separated by a comma, as in:
当请求多个信号时，它们的代码用逗号分隔，如：
S: asdi(123456 Your friend), rg
S:asdi（你的朋友123456），rg
The observed event parameters provides the list of events that have been observed. The event codes are the same as those used in the NotificationRequest. Events that have been accumulated according to the digit map may be grouped in a single string; they should be reported as lists of isolated events if other events where detected during the digit accumulation. Examples of observed actions are:
观察到的事件参数提供已观察到的事件列表。事件代码与NotificationRequest中使用的代码相同。根据数字映射累积的事件可以分组为单个字符串；如果在数字累加期间检测到其他事件，则应将其报告为孤立事件列表。观察到的行动示例如下：
O: L/hu
O: 8295555T
O: 8,2,9,5,5,L/hf,5,5,T
O: L/hf, L/hf, L/hu
O: L/hu
O: 8295555T
O: 8,2,9,5,5,L/hf,5,5,T
O: L/hf, L/hf, L/hu
The RequestedInfo parameter contains a comma separated list of parameter codes, as defined in the "Parameter lines" section. For example, if one wants to audit the value of the NotifiedEntity, RequestIdentifier, RequestedEvents, SignalRequests, DigitMap, QuarantineHandling and DetectEvents parameters, The value of the RequestedInfo parameter will be:
RequestedInfo参数包含以逗号分隔的参数代码列表，如“参数行”部分中所定义。例如，如果要审核NotifiedIdentity、RequestIdentifier、RequestedEvents、SignalRequests、DigitMap、QuarantineHandling和DetecteEvents参数的值，RequestedInfo参数的值将为：
F:N,X,R,S,D,Q,T
F:N，X，R，S，D，Q，T
The capabilities request, in the AuditEndPoint command, is encoded by the keyword "A", as in:
AuditEndPoint命令中的能力请求由关键字“A”编码，如中所示：
F:A
F:A
The quarantine handling parameter contains a list of comma separated keywords:
隔离处理参数包含逗号分隔的关键字列表：
* The keyword "process" or "discard" to indicate the treatment of quarantined events. If neither process or discard is present, process is assumed.
* 关键字“process”或“discard”表示隔离事件的处理。如果不存在过程或丢弃，则假定过程。
* The keyword "step" or "loop" to indicate whether exactly at most one notification is expected, or whether multiple notifications are allowed. If neither step or loop is present, step is assumed. The following values are valid examples:
* 关键字“step”或“loop”指示是否最多只需要一个通知，或者是否允许多个通知。如果步骤或循环都不存在，则假定步骤。以下值是有效的示例：
Q:loop Q:process Q:discard,loop
Q：循环Q：过程Q：丢弃，循环
The DetectEvent parameter is encoded as a comma separated list of events, such as for example:
DetecteEvent参数编码为逗号分隔的事件列表，例如：
T: hu,hd,hf,[0-9#*]
T: hu,hd,hf,[0-9#*]
It should be noted, that no actions can be associated with the events.
应该注意的是，任何操作都不能与事件关联。
The EventStates parameter is encoded as a comma separated list of events, such as for example:
EventState参数编码为逗号分隔的事件列表，例如：
ES: hu
ES:胡
It should be noted, that no actions can be associated with the events.
应该注意的是，任何操作都不能与事件关联。
The RestartMethod parameter is encoded as one of the keywords "graceful", "forced", "restart", "disconnected" or "cancel-graceful" as for example:
RestartMethod参数编码为关键字“优雅”、“强制”、“重新启动”、“断开连接”或“取消优雅”之一，例如：
RM:restart
RM：重新启动
The values of the bearer informations are encoded as a comma separated list of attributes, represented by an attribute name, separated by a colon from an attribute value.
承载信息的值编码为逗号分隔的属性列表，由属性名称表示，由冒号与属性值分隔。
The only attribute that is defined is the "encoding" (code "e"), whose defined values are "A" (A-law) and "mu" (mu-law).
唯一定义的属性是“编码”（代码“e”），其定义值为“A”（A-定律）和“mu”（mu-定律）。
An example of bearer information encoding is:
承载信息编码的一个示例是：
B: e:mu
B:e:mu
The response header is composed of a response line, optionally followed by headers that encode the response parameters.
响应头由响应行组成，可选地后跟对响应参数进行编码的头。
An example of response header could be:
响应头的一个示例可以是：
200 1203 OK
2001203好
The response line starts with the response code, which is a three digit numeric value. The code is followed by a white space, the transaction identifier, and an optional commentary preceded by a white space.
响应行以响应代码开头，它是一个三位数的数值。代码后面是一个空格、事务标识符和一个可选注释，前面是一个空格。
The following table describe the parameters whose presence is mandatory or optional in a response header, as a function of the command that triggered the response. The letter M stands for mandatory, O for optional and F for forbidden.
下表描述了在响应头中作为触发响应的命令的函数出现的强制或可选参数。字母M代表强制，O代表可选，F代表禁止。
___________________________________________________________________
| Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS|
| | CF| CX| CX| CX| NT| FY| EP| CX| IP|
|_____________________|____|____|____|____|____|____|____|____|____|
| ResponseAck | F | F | F | F | F | F | F | F | F |
| BearerInformation | F | F | F | F | F | F | O | F | F |
| CallId | F | F | F | F | F | F | F | O | F |
| ConnectionId | F | O*| F | F | F | F | F | F | F |
| RequestIdentifier | F | F | F | F | F | F | O | F | F |
| LocalConnection | F | F | F | F | F | F | O | O | F |
| Options | | | | | | | | | |
| Connection Mode | F | F | F | F | F | F | F | O | F |
| RequestedEvents | F | F | F | F | F | F | O | F | F |
| SignalRequests | F | F | F | F | F | F | O | F | F |
| NotifiedEntity | F | F | F | F | F | F | F | F | O |
| ReasonCode | F | F | F | F | F | F | O | F | F |
| ObservedEvents | F | F | F | F | F | F | O | F | F |
| DigitMap | F | F | F | F | F | F | O | F | F |
| Connection | F | F | F | O | F | F | F | O | F |
| Parameters | | | | | | | | | |
| Specific Endpoint ID| F | O | F | F | F | F | F | F | F |
| RequestedInfo | F | F | F | F | F | F | F | F | F |
| QuarantineHandling | F | F | F | F | F | F | O | F | F |
| DetectEvents | F | F | F | F | F | F | O | F | F |
| EventStates | F | F | F | F | F | F | O | F | F |
| RestartMethod | F | F | F | F | F | F | O | F | F |
| RestartDelay | F | F | F | F | F | F | O | F | F |
| Capabilities | F | F | F | F | F | F | O | F | F |
| SecondConnectionId | F | O | F | F | F | F | F | F | F |
| SecondEndpointID | F | O | F | F | F | F | F | F | F |
|_____________________|____|____|____|____|____|____|____|____|____|
| LocalConnection | F | M | O | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
| RemoteConnection | F | F | F | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
|_____________________|____|____|____|____|____|____|____|____|____|
___________________________________________________________________
| Parameter name | EP| CR| MD| DL| RQ| NT| AU| AU| RS|
| | CF| CX| CX| CX| NT| FY| EP| CX| IP|
|_____________________|____|____|____|____|____|____|____|____|____|
| ResponseAck | F | F | F | F | F | F | F | F | F |
| BearerInformation | F | F | F | F | F | F | O | F | F |
| CallId | F | F | F | F | F | F | F | O | F |
| ConnectionId | F | O*| F | F | F | F | F | F | F |
| RequestIdentifier | F | F | F | F | F | F | O | F | F |
| LocalConnection | F | F | F | F | F | F | O | O | F |
| Options | | | | | | | | | |
| Connection Mode | F | F | F | F | F | F | F | O | F |
| RequestedEvents | F | F | F | F | F | F | O | F | F |
| SignalRequests | F | F | F | F | F | F | O | F | F |
| NotifiedEntity | F | F | F | F | F | F | F | F | O |
| ReasonCode | F | F | F | F | F | F | O | F | F |
| ObservedEvents | F | F | F | F | F | F | O | F | F |
| DigitMap | F | F | F | F | F | F | O | F | F |
| Connection | F | F | F | O | F | F | F | O | F |
| Parameters | | | | | | | | | |
| Specific Endpoint ID| F | O | F | F | F | F | F | F | F |
| RequestedInfo | F | F | F | F | F | F | F | F | F |
| QuarantineHandling | F | F | F | F | F | F | O | F | F |
| DetectEvents | F | F | F | F | F | F | O | F | F |
| EventStates | F | F | F | F | F | F | O | F | F |
| RestartMethod | F | F | F | F | F | F | O | F | F |
| RestartDelay | F | F | F | F | F | F | O | F | F |
| Capabilities | F | F | F | F | F | F | O | F | F |
| SecondConnectionId | F | O | F | F | F | F | F | F | F |
| SecondEndpointID | F | O | F | F | F | F | F | F | F |
|_____________________|____|____|____|____|____|____|____|____|____|
| LocalConnection | F | M | O | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
| RemoteConnection | F | F | F | F | F | F | F | O*| F |
| Descriptor | | | | | | | | | |
|_____________________|____|____|____|____|____|____|____|____|____|
In the case of a CreateConnection message, the response line is followed by a Connection-Id parameter. It may also be followed a Specific-Endpoint-Id parameter, if the creation request was sent to a wildcarded Endpoint-Id. The connection-Id parameter is marked as optional in the Table. In fact, it is mandatory with all positive responses, when a connection was created, and forbidden when the response is negative, when no connection as created.
对于CreateConnection消息，响应行后面跟着连接Id参数。如果创建请求被发送到通配符为Endpoint-Id的端点，则还可以在特定的Endpoint-Id参数之后。连接Id参数在表中标记为可选。事实上，当创建了连接时，所有积极响应都必须使用该选项，当响应为消极响应时，如果没有创建连接，则禁止使用该选项。
In the case of a DeleteConnection message, the response line is followed by a Connection Parameters parameter, as defined in section 3.2.2.2.
如果是DeleteConnection消息，响应行后面跟着连接参数，如第3.2.2.2节所定义。
A LocalConnectionDescriptor should be transmitted with a positive response (code 200) to a CreateConnection. It may be transmitted in response to a ModifyConnection command, if the modification resulted in a modification of the session parameters. The LocalConnectionDescriptor is encoded as a "session description," as defined in section 3.4. It is separated from the response header by an empty line.
LocalConnectionDescriptor应与肯定响应（代码200）一起传输到CreateConnection。如果修改导致会话参数的修改，则可响应ModifyConnection命令发送该消息。LocalConnectionDescriptor编码为“会话描述”，如第3.4节所定义。它与响应头之间用空行分隔。
When several session descriptors are encoded in the same response, they are encoded one after each other, separated by an empty line. This is the case for example when the response to an audit connection request carries both a local session description and a remote session description, as in:
当在同一响应中对多个会话描述符进行编码时，它们将依次编码，并用空行分隔。例如，当对审核连接请求的响应同时包含本地会话描述和远程会话描述时，就是这种情况，如：
200 1203 OK
C: A3C47F21456789F0
N: [128.96.41.12]
L: p:10, a:PCMU;G726-32
M: sendrecv
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48
200 1203 OK
C: A3C47F21456789F0
N: [128.96.41.12]
L: p:10, a:PCMU;G726-32
M: sendrecv
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48
v=0 c=IN IP4 128.96.41.1 m=audio 1296 RTP/AVP 0
v=0 c=IN IP4 128.96.41.1 m=audio 1296 RTP/AVP 0
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
In this example, according to the SDP syntax, each description starts with a "version" line, (v=...). The local description is always transmitted before the remote description. If a connection descriptor is requested, but it does not exist for the connection audited, that connection descriptor will appear with the SDP protocol version field only.
在本例中，根据SDP语法，每个描述都以“version”行开始，（v=…）。本地描述总是在远程描述之前传输。如果请求了连接描述符，但该连接描述符对于已审核的连接不存在，则该连接描述符将仅与SDP协议版本字段一起显示。
In this section, we provided a formal description of the protocol syntax, following the "Augmented BNF for Syntax Specifications" defined in RFC 2234.
在本节中，我们提供了协议语法的正式描述，遵循RFC 2234中定义的“语法规范的扩充BNF”。
MGCPMessage = MGCPCommand / MGCPResponse
MGCPMessage = MGCPCommand / MGCPResponse
MGCPCommand = MGCPCommandLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPCommand = MGCPCommandLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPCommandLine = MGCPVerb 1*(WSP) <transaction-id> 1*(WSP)
<endpointName> 1*(WSP) MGCPversion EOL
MGCPCommandLine = MGCPVerb 1*(WSP) <transaction-id> 1*(WSP)
<endpointName> 1*(WSP) MGCPversion EOL
MGCPVerb = "EPCF" / "CRCX" / "MDCX" / "DLCX" / "RQNT"
/ "NTFY" / "AUEP" / "AUCX" / "RSIP" / extensionVerb
MGCPVerb = "EPCF" / "CRCX" / "MDCX" / "DLCX" / "RQNT"
/ "NTFY" / "AUEP" / "AUCX" / "RSIP" / extensionVerb
extensionVerb = "X" 3(ALPHA / DIGIT)
extensionVerb = "X" 3(ALPHA / DIGIT)
transaction-id = 1*9(DIGIT)
transaction-id = 1*9(DIGIT)
endpointName = localEndpointName "@" DomainName
LocalEndpointName = LocalNamePart 0*("/" LocalNamePart)
LocalNamePart = AnyName / AllName / NameString
AnyName = "$"
AllNames = "*"
NameString = 1*(range-of-allowed-characters)
DomainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821
endpointName = localEndpointName "@" DomainName
LocalEndpointName = LocalNamePart 0*("/" LocalNamePart)
LocalNamePart = AnyName / AllName / NameString
AnyName = "$"
AllNames = "*"
NameString = 1*(range-of-allowed-characters)
DomainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821
MGCPversion = "MGCP" 1*(WSP) 1*(DIGIT) "." 1*(DIGIT)
[1*(WSP) ProfileName]
ProfileName = 1*(range-of-allowed-characters)
MGCPversion = "MGCP" 1*(WSP) 1*(DIGIT) "." 1*(DIGIT)
[1*(WSP) ProfileName]
ProfileName = 1*(range-of-allowed-characters)
MGCPParameter = ParameterValue EOL
MGCPParameter = ParameterValue EOL
ParameterValue = ("K" ":" 0*WSP <ResponseAck>) /
("B" ":" 0*WSP <BearerInformation>) /
("C" ":" 0*WSP <CallId>) /
("I" ":" 0*WSP <ConnectionId>) /
("N" ":" 0*WSP <NotifiedEntity>) /
("X" ":" 0*WSP <RequestIdentifier>) /
("L" ":" 0*WSP <LocalConnectionOptions>) /
("M" ":" 0*WSP <ConnectionMode>) /
("R" ":" 0*WSP <RequestedEvents>) /
("S" ":" 0*WSP <SignalRequests>) /
("D" ":" 0*WSP <DigitMap>) /
("O" ":" 0*WSP <ObservedEvents>) /
("P" ":" 0*WSP <ConnectionParameters>) /
("E" ":" 0*WSP <ReasonCode>) /
ParameterValue = ("K" ":" 0*WSP <ResponseAck>) /
("B" ":" 0*WSP <BearerInformation>) /
("C" ":" 0*WSP <CallId>) /
("I" ":" 0*WSP <ConnectionId>) /
("N" ":" 0*WSP <NotifiedEntity>) /
("X" ":" 0*WSP <RequestIdentifier>) /
("L" ":" 0*WSP <LocalConnectionOptions>) /
("M" ":" 0*WSP <ConnectionMode>) /
("R" ":" 0*WSP <RequestedEvents>) /
("S" ":" 0*WSP <SignalRequests>) /
("D" ":" 0*WSP <DigitMap>) /
("O" ":" 0*WSP <ObservedEvents>) /
("P" ":" 0*WSP <ConnectionParameters>) /
("E" ":" 0*WSP <ReasonCode>) /
("Z" ":" 0*WSP <SpecificEndpointID>) /
("Z2" ":" 0*WSP <SecondEndpointID>) /
("I2" ":" 0*WSP <SecondConnectionID>) /
("F" ":" 0*WSP <RequestedInfo>) /
("Q" ":" 0*WSP <QuarantineHandling>) /
("T" ":" 0*WSP <DetectEvents>) /
("RM" ":" 0*WSP <RestartMethod>) /
("RD" ":" 0*WSP <RestartDelay>) /
("A" ":" 0*WSP <Capabilities>) /
("ES" ":" 0*WSP <EventStates>) /
(extensionParameter ":" 0*WSP <parameterString>)
("Z" ":" 0*WSP <SpecificEndpointID>) /
("Z2" ":" 0*WSP <SecondEndpointID>) /
("I2" ":" 0*WSP <SecondConnectionID>) /
("F" ":" 0*WSP <RequestedInfo>) /
("Q" ":" 0*WSP <QuarantineHandling>) /
("T" ":" 0*WSP <DetectEvents>) /
("RM" ":" 0*WSP <RestartMethod>) /
("RD" ":" 0*WSP <RestartDelay>) /
("A" ":" 0*WSP <Capabilities>) /
("ES" ":" 0*WSP <EventStates>) /
(extensionParameter ":" 0*WSP <parameterString>)
ResponseAck = confirmedTransactionIdRange *[ "," confirmedTransactionIdRange ]
responseAK=confirmedTransactionIdRange*[”，“confirmedTransactionIdRange]
confirmedTransactionIdRange = 1*9DIGIT [ "-" 1*9DIGIT ]
confirmedTransactionIdRange = 1*9DIGIT [ "-" 1*9DIGIT ]
BearerInformation = BearerAttribute 0*("," 0*WSP BearerAttribute)
BearerAttribute = ("e" ":" <BearerEncoding>)
BearerEncoding = "A" / "mu"
BearerInformation = BearerAttribute 0*("," 0*WSP BearerAttribute)
BearerAttribute = ("e" ":" <BearerEncoding>)
BearerEncoding = "A" / "mu"
CallId = 1*32(HEXDIG)
CallId = 1*32(HEXDIG)
// The audit request response may include a list of identifiers
ConnectionId = 1*32(HEXDIG) 0*("," 1*32(HEXDIG))
SecondConnectionID = ConnectionId
// The audit request response may include a list of identifiers
ConnectionId = 1*32(HEXDIG) 0*("," 1*32(HEXDIG))
SecondConnectionID = ConnectionId
NotifiedEntity = [LocalName "@"] DomainName [":" portNumber]
LocalName = 1*32(suitableCharacter)
portNumber = 1*5(DIGIT)
NotifiedEntity = [LocalName "@"] DomainName [":" portNumber]
LocalName = 1*32(suitableCharacter)
portNumber = 1*5(DIGIT)
RequestIdentifier = 1*32(HEXDIG)
RequestIdentifier = 1*32(HEXDIG)
LocalConnectionOptions = [ LocalOptionValue 0*(WSP)
0*("," 0*(WSP) LocalOptionValue 0*(WSP)) ]
LocalOptionValue = ("p" ":" <packetizationPeriod> )
/ ("a" ":" <compressionAlgorithm> )
/ ("b" ":" <bandwidth> )
/ ("e" ":" <echoCancellation> )
/ ("gc" ":" <gainControl> )
/ ("s" ":" <silenceSuppression> )
/ ("t" ":" <typeOfService> )
/ ("r" ":" <resourceReservation> )
/ ("k" ":" <encryptionmethod>[":"<encryptionKey>])
/ ("nt" ":" <typeOfNetwork> )
/ (localOptionExtensionName ":"
/ localOptionExtensionValue)
LocalConnectionOptions = [ LocalOptionValue 0*(WSP)
0*("," 0*(WSP) LocalOptionValue 0*(WSP)) ]
LocalOptionValue = ("p" ":" <packetizationPeriod> )
/ ("a" ":" <compressionAlgorithm> )
/ ("b" ":" <bandwidth> )
/ ("e" ":" <echoCancellation> )
/ ("gc" ":" <gainControl> )
/ ("s" ":" <silenceSuppression> )
/ ("t" ":" <typeOfService> )
/ ("r" ":" <resourceReservation> )
/ ("k" ":" <encryptionmethod>[":"<encryptionKey>])
/ ("nt" ":" <typeOfNetwork> )
/ (localOptionExtensionName ":"
/ localOptionExtensionValue)
Capabilities = [ CapabilityValue 0*(WSP)
0*("," 0*(WSP) CapabilityValue 0*(WSP)) ]
Capabilities = [ CapabilityValue 0*(WSP)
0*("," 0*(WSP) CapabilityValue 0*(WSP)) ]
CapabilityValue = LocalOptionValue
/ ("v" ":" <supportedPackages>)
/ ("m" ":" <supportedModes> )
CapabilityValue = LocalOptionValue
/ ("v" ":" <supportedPackages>)
/ ("m" ":" <supportedModes> )
packetizationPeriod = 1*4(DIGIT)["-" 1*4(DIGIT)]
compressionAlgorithm = algorithmName 0*(";" algorithmName)
algorithmName = 1*32(SuitableCharacter)
bandwidth = 1*4(DIGIT)["-" 1*4(DIGIT)]
echoCancellation = "on" / "off"
gainControl = "auto" / ["-"]1*4(DIGIT)
silenceSuppression = "on" / "off"
typeOfService = 2HEXDIG
resourceReservation = "g" / "cl" / "be"
packetizationPeriod = 1*4(DIGIT)["-" 1*4(DIGIT)]
compressionAlgorithm = algorithmName 0*(";" algorithmName)
algorithmName = 1*32(SuitableCharacter)
bandwidth = 1*4(DIGIT)["-" 1*4(DIGIT)]
echoCancellation = "on" / "off"
gainControl = "auto" / ["-"]1*4(DIGIT)
silenceSuppression = "on" / "off"
typeOfService = 2HEXDIG
resourceReservation = "g" / "cl" / "be"
;encryption parameters are coded as in SDP (RFC 2327)
encryptiondata = ( "clear" ":" <encryptionKey> )
/ ( "base64" ":" <encodedEncryptionKey> )
/ ( "uri" ":" <URItoObtainKey> )
/ ( "prompt" ) ; defined in SDP, not usable in MGCP!
encryptionKey = 1*(SuitableCharacter / SP)
encodedEncryptionKey = 1*(ALPHA / DIGIT / "+" / "/" / "=")
URItoObtainKey = 1*(SuitableCharacter) / quotedString
;encryption parameters are coded as in SDP (RFC 2327)
encryptiondata = ( "clear" ":" <encryptionKey> )
/ ( "base64" ":" <encodedEncryptionKey> )
/ ( "uri" ":" <URItoObtainKey> )
/ ( "prompt" ) ; defined in SDP, not usable in MGCP!
encryptionKey = 1*(SuitableCharacter / SP)
encodedEncryptionKey = 1*(ALPHA / DIGIT / "+" / "/" / "=")
URItoObtainKey = 1*(SuitableCharacter) / quotedString
typeOfNetwork = "IN" / "ATM" / "LOCAL"
supportedModes= ConnectionMode 0*(";" ConnectionMode)
supportedPackages = packageName 0*(";" packageName)
typeOfNetwork = "IN" / "ATM" / "LOCAL"
supportedModes= ConnectionMode 0*(";" ConnectionMode)
supportedPackages = packageName 0*(";" packageName)
localOptionExtensionName = "x" ("+"/"-") 1*32(SuitableCharacter)
localOptionExtensionValue = 1*32(SuitableCharacter) / quotedString
localOptionExtensionName = "x" ("+"/"-") 1*32(SuitableCharacter)
localOptionExtensionValue = 1*32(SuitableCharacter) / quotedString
ConnectionMode = "sendonly" / "recvonly" / "sendrecv" /
"confrnce" / "inactive" / "loopback" /
"conttest" / "netwloop" / "netwtest" / "data"
ConnectionMode = "sendonly" / "recvonly" / "sendrecv" /
"confrnce" / "inactive" / "loopback" /
"conttest" / "netwloop" / "netwtest" / "data"
RequestedEvents = [requestedEvent 0*("," 0*(WSP) requestedEvent)]
requestedEvent = eventName [ "(" requestedActions ")" ]
RequestedEvents = [requestedEvent 0*("," 0*(WSP) requestedEvent)]
requestedEvent = eventName [ "(" requestedActions ")" ]
eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange)
[ "@" (ConnectionId / "$" / "*") ]
packageName = 1*(ALPHA / DIGIT / HYPHEN)
eventId = 1*(SuitableCharacter)
eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" /
eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange)
[ "@" (ConnectionId / "$" / "*") ]
packageName = 1*(ALPHA / DIGIT / HYPHEN)
eventId = 1*(SuitableCharacter)
eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" /
(DIGIT "-" DIGIT)/(DTMFLetter "-" DTMFLetter)) "]"
（数字“-”数字）/（DTMFLetter“-”DTMFLetter））“]
requestedActions = requestedAction 0*("," 0*(WSP) requestedAction)
requestedAction = "N" / "A" / "D" / "S" / "I" / "K" /
"E" "(" EmbeddedRequest ")"
requestedActions = requestedAction 0*("," 0*(WSP) requestedAction)
requestedAction = "N" / "A" / "D" / "S" / "I" / "K" /
"E" "(" EmbeddedRequest ")"
EmbeddedRequest = ( "R" "(" EmbeddedRequestList ")"
["," "S" "(" EmbeddedSignalRequest ")" ]
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "S" "(" EmbeddedSignalRequest ")"
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "D" "(" EmbeddedDigitMap ")" )
EmbeddedRequest = ( "R" "(" EmbeddedRequestList ")"
["," "S" "(" EmbeddedSignalRequest ")" ]
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "S" "(" EmbeddedSignalRequest ")"
["," "D" "(" EmbeddedDigitMap ")" ] )
/ ( "D" "(" EmbeddedDigitMap ")" )
EmbeddedRequestList = RequestedEvents EmbeddedSignalRequest = SignalRequests EmbeddedDigitMap = DigitMap
EmbeddedRequestList=RequestedEvents EmbeddedSignalRequest=SignalRequests EmbeddedDigitMap=DigitMap
SignalRequests = [ SignalRequest 0*("," 0*(WSP) SignalRequest ) ]
SignalRequest = eventName [ "(" eventParameters ")" ]
eventParameters = eventParameter 0*("," 0*(WSP) eventParameter)
eventParameter = eventParameterString / quotedString
eventParameterString = 1*(SuitableCharacter)
SignalRequests = [ SignalRequest 0*("," 0*(WSP) SignalRequest ) ]
SignalRequest = eventName [ "(" eventParameters ")" ]
eventParameters = eventParameter 0*("," 0*(WSP) eventParameter)
eventParameter = eventParameterString / quotedString
eventParameterString = 1*(SuitableCharacter)
DigitMap = DigitString / "(" DigitStringList ")"
DigitStringList = DigitString 0*( "|" DigitString )
DigitString = 1*(DigitStringElement)
DigitStringElement = DigitPosition ["."]
DigitPosition = DigitMapLetter / DigitMapRange
DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / "T"
DigitMapRange = "x" / "[" 1*DigitLetter "]"
DigitLetter ::= *((DIGIT "-" DIGIT ) / DigitMapLetter)
DigitMap = DigitString / "(" DigitStringList ")"
DigitStringList = DigitString 0*( "|" DigitString )
DigitString = 1*(DigitStringElement)
DigitStringElement = DigitPosition ["."]
DigitPosition = DigitMapLetter / DigitMapRange
DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / "T"
DigitMapRange = "x" / "[" 1*DigitLetter "]"
DigitLetter ::= *((DIGIT "-" DIGIT ) / DigitMapLetter)
ObservedEvents = SignalRequests EventStates = SignalRequests
ObservedEvents=SignalRequests事件状态=SignalRequests
ConnectionParameters = [ConnectionParameter
0*( "," 0*(WSP) ConnectionParameter )
ConnectionParameter = ( "PS" "=" packetsSent )
/ ( "OS" "=" octetsSent )
/ ( "PR" "=" packetsReceived )
/ ( "OR" "=" octetsReceived )
/ ( "PL" "=" packetsLost )
/ ( "JI" "=" jitter )
/ ( "LA" "=" averageLatency )
/ ( ConnectionParameterExtensionName "="
ConnectionParameterExtensionValue )
packetsSent = 1*9(DIGIT)
ConnectionParameters = [ConnectionParameter
0*( "," 0*(WSP) ConnectionParameter )
ConnectionParameter = ( "PS" "=" packetsSent )
/ ( "OS" "=" octetsSent )
/ ( "PR" "=" packetsReceived )
/ ( "OR" "=" octetsReceived )
/ ( "PL" "=" packetsLost )
/ ( "JI" "=" jitter )
/ ( "LA" "=" averageLatency )
/ ( ConnectionParameterExtensionName "="
ConnectionParameterExtensionValue )
packetsSent = 1*9(DIGIT)
octetsSent = 1*9(DIGIT)
packetsReceived = 1*9(DIGIT)
octetsReceived = 1*9(DIGIT)
packetsLost = 1*9(DIGIT)
jitter = 1*9(DIGIT)
averageLatency = 1*9(DIGIT)
ConnectionParameterExtensionName = "X" "-" 2*ALPHA
ConnectionParameterExtensionValue = 1*9(DIGIT)
octetsSent = 1*9(DIGIT)
packetsReceived = 1*9(DIGIT)
octetsReceived = 1*9(DIGIT)
packetsLost = 1*9(DIGIT)
jitter = 1*9(DIGIT)
averageLatency = 1*9(DIGIT)
ConnectionParameterExtensionName = "X" "-" 2*ALPHA
ConnectionParameterExtensionValue = 1*9(DIGIT)
ReasonCode = 3DIGIT [SPACE 1*(%x20-7E)]
ReasonCode=3DIGIT[空格1*（%x20-7E）]
SpecificEndpointID = endpointName SecondEndpointID = endpointName
SpecificEndpointID=endpointName SecondEndpointID=endpointName
RequestedInfo = [infoCode 0*("," infoCode)]
RequestedInfo = [infoCode 0*("," infoCode)]
infoCode = "B" / "C" / "I" / "N" / "X" / "L" / "M" /
"R" / "S" / "D" / "O" / "P" / "E" / "Z" /
"Q" / "T" / "RC" / "LC" / "A" / "ES" / "RM" / "RD"
infoCode = "B" / "C" / "I" / "N" / "X" / "L" / "M" /
"R" / "S" / "D" / "O" / "P" / "E" / "Z" /
"Q" / "T" / "RC" / "LC" / "A" / "ES" / "RM" / "RD"
QuarantineHandling = loopControl / processControl /
(loopControl "," processControl )
loopControl = "step" / "loop"
processControl = "process" / "discard"
QuarantineHandling = loopControl / processControl /
(loopControl "," processControl )
loopControl = "step" / "loop"
processControl = "process" / "discard"
DetectEvents = [eventName 0*("," eventName)]
DetectEvents = [eventName 0*("," eventName)]
RestartMethod = "graceful" / "forced" / "restart" / "disconnected"
RestartMethod = "graceful" / "forced" / "restart" / "disconnected"
RestartDelay = 1*6(DIGIT)
RestartDelay = 1*6(DIGIT)
extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT)
parameterString = 1*(%x20-7F)
extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT)
parameterString = 1*(%x20-7F)
MGCPResponse = MGCPResponseLine 0*(MGCPParameter) [EOL *SDPinformation]
MGCPResponse=MGCPResponseLine 0*（MGCPParameter）[EOL*SDP信息]
MGCPResponseLine = (<responseCode> 1*(WSP) <transaction-id>
[1*(WSP) <responseString>] EOL)
responseCode = 3DIGIT
responseString = *(%x20-7E)
MGCPResponseLine = (<responseCode> 1*(WSP) <transaction-id>
[1*(WSP) <responseString>] EOL)
responseCode = 3DIGIT
responseString = *(%x20-7E)
SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" /
"!" / "'" / "|" / "=" / "#" / "?" / "/" /
"." / "$" / "*" / ";" / "@" / "[" / "]" /
"^" / "`" / "{" / "}" / "~"
SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" /
"!" / "'" / "|" / "=" / "#" / "?" / "/" /
"." / "$" / "*" / ";" / "@" / "[" / "]" /
"^" / "`" / "{" / "}" / "~"
quotedString = DQUOTE visibleString
quotedString = DQUOTE visibleString
0*(quoteEscape visibleString) DQUOTE
quoteEscape = DQUOTE DQUOTE
visibleString = (%x00-21 / %x23-FF)
EOL = CRLF / LF
0*(quoteEscape visibleString) DQUOTE
quoteEscape = DQUOTE DQUOTE
visibleString = (%x00-21 / %x23-FF)
EOL = CRLF / LF
SDPinformation = ;See RFC 2327
SDPinformation=；见RFC 2327
The session description is encoded in conformance with the session description protocol, SDP. MGCP implementations are expected to be fully capable of parsing any conformant SDP message, and should send session descriptions that strictly conform to the SDP standard. The usage of SDP actually depends on the type of session that is being, as specified in the "mode" parameter:
会话描述按照会话描述协议SDP进行编码。MGCP实现应该完全能够解析任何符合SDP标准的消息，并且应该发送严格符合SDP标准的会话描述。SDP的使用实际上取决于正在进行的会话类型，如“mode”参数中所指定：
* if the mode is set to "data", the session description describes the configuration of a data access service.
* 如果模式设置为“数据”，则会话描述描述数据访问服务的配置。
* if the mode is set to any other value, the session description is for an audio service.
* 如果模式设置为任何其他值，则会话描述针对音频服务。
For an audio service, the gateway will consider the information provided in SDP for the "audio" media. For a data service, the gateway will consider the information provided for the "network-access" media.
对于音频服务，网关将考虑SDP中为“音频”媒体提供的信息。对于数据服务，网关将考虑为“网络接入”媒体提供的信息。
In a telephony gateway, we only have to describe sessions that use exactly one media, audio. The parameters of SDP that are relevant for the telephony application are:
在电话网关中，我们只需描述只使用一种媒体（音频）的会话。与电话应用程序相关的SDP参数包括：
At the session description level:
在会话描述级别：
* The IP address of the remote gateway (in commands) or of the local gateway (in responses), or multicast address of the audio conference, encoded as an SDP "connection data" parameter. This parameter specifies the IP address that will be used to exchange RTP packets.
* 远程网关（在命令中）或本地网关（在响应中）的IP地址，或音频会议的多播地址，编码为SDP“连接数据”参数。此参数指定将用于交换RTP数据包的IP地址。
For the audio media:
对于音频媒体：
* Media description field (m) specifying the audio media, the transport port used for receiving RTP packets by the remote gateway (commands) or by the local gateway (responses), the
* 媒体描述字段（m），指定音频媒体、用于通过远程网关（命令）或本地网关（响应）接收RTP数据包的传输端口，以及
RTP/AVP transport, and the list of formats that the gateway will accept. This list should normally always include the code 0 (reserved for PCMU).
RTP/AVP传输，以及网关将接受的格式列表。此列表通常应始终包含代码0（为PCMU保留）。
* Optionally, RTPMAP attributes that define the encoding of dynamic audio formats,
* （可选）定义动态音频格式编码的RTPMAP属性，
* Optionally, a packetization period (packet time) attribute (Ptime) defining the duration of the packet,
* 可选地，定义数据包持续时间的数据包化周期（数据包时间）属性（Ptime），
* Optionally, an attribute defining the type of connection (sendonly, recvonly, sendrecv, inactive). Note that this attribute does not have a direct relation with the "Mode" parameter of MGCP. In fact, the SDP type of connection will most of the time be set to "sendrecv", regardless of the value used by MGCP. Other values will only be used rarely, for example in the case of information or announcement servers that need to establish one way connections.
* （可选）定义连接类型的属性（sendonly、RecVoOnly、sendrecv、inactive）。请注意，此属性与MGCP的“Mode”参数没有直接关系。事实上，无论MGCP使用的值是多少，SDP类型的连接在大多数情况下都会设置为“sendrecv”。其他值只会很少使用，例如在需要建立单向连接的信息或公告服务器的情况下。
* The IP address of the remote gateway (in commands) or of the local gateway (in responses), if it is not present at the session level.
* 远程网关（在命令中）或本地网关（在响应中）的IP地址（如果在会话级别不存在）。
An example of SDP specification for an audio connection could be:
音频连接的SDP规范示例如下：
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
There is a request, in some environments, to use the MGCP to negotiate connections that will use other transmission channels than RTP over UDP and IP. This will be detailed in an extension to this document.
在某些环境中，存在使用MGCP协商将使用UDP和IP上RTP以外的其他传输通道的连接的请求。这将在本文件的扩展部分中详细说明。
The parameters of SDP that are relevant for a data network access application are:
与数据网络访问应用程序相关的SDP参数包括：
For the data media:
对于数据媒体：
* Media description field (m) specifying the network access media, identified by the code "m=nas/xxxx", where "xxxx" describes the access control method that should be used for parametrizing the network access, as specified below. The field may also specify the port that should be used for contacting the server, as specified in the SDP syntax.
* 介质描述字段（m）指定网络访问介质，由代码“m=nas/xxxx”标识，其中“xxxx”描述了用于参数化网络访问的访问控制方法，如下所述。该字段还可以指定SDP语法中指定的用于联系服务器的端口。
* Connection address parameter (c=) specifying the address, or the domain name, of the server that implement the access control method. This parameter may also be specified at the session level.
* 连接地址参数（c=），指定实现访问控制方法的服务器的地址或域名。也可以在会话级别指定此参数。
* Optionally, a bearer type attribute (a=bearer:) describing the type of data connection to be used, including the modem type.
* 可选地，描述要使用的数据连接类型（包括调制解调器类型）的承载类型属性（a=承载：）。
* Optionally, a framing type attribue (a=framing:) describing the type of framing that will be used on the channel.
* （可选）帧类型属性（a=framing:）描述将在通道上使用的帧类型。
* Optionally, attributes describing the called number (a=dialed:), the number to which the call was delivered (a=called:) and the calling number (a=dialing:).
* （可选）描述被叫号码（a=已拨：）、呼叫转接号码（a=已拨：）和主叫号码（a=已拨：）的属性。
* Optionally, attributes describing the range of addresses that could be used by the dialup client on its LAN (a=subnet:).
* （可选）描述拨号客户端可在其LAN（a=子网：）上使用的地址范围的属性。
* Optionally, an encryption key, encoded as specified in the SDP protocol(k=).
* 可选地，加密密钥，按照SDP协议（k=）中的指定进行编码。
The connection address shall be encoded as specified in the SDP standard. It will be used in conjunction with the port specified in the media line to access a server, whose type will one of:
连接地址应按照SDP标准的规定进行编码。它将与媒体线路中指定的端口一起使用，以访问服务器，服务器类型为：
__________________________________________________________
| Method name| Method description |
|____________|____________________________________________|
| radius | Authentication according |
| | to the Radius protocol. |
| tacacs | Authentication according |
| | to the TACACS+ protocol. |
| diameter | Authentication according |
| | to the Diameter protocol. |
| l2tp | Level 2 tunneling protocol. |
| | The address and port are those of the LNS.|
| login | Local login. (There is normally |
| | no server for that method.) |
| none | No authentication required. |
| | (The call was probably vetted |
| | by the Call Agent.) |
|____________|____________________________________________|
__________________________________________________________
| Method name| Method description |
|____________|____________________________________________|
| radius | Authentication according |
| | to the Radius protocol. |
| tacacs | Authentication according |
| | to the TACACS+ protocol. |
| diameter | Authentication according |
| | to the Diameter protocol. |
| l2tp | Level 2 tunneling protocol. |
| | The address and port are those of the LNS.|
| login | Local login. (There is normally |
| | no server for that method.) |
| none | No authentication required. |
| | (The call was probably vetted |
| | by the Call Agent.) |
|____________|____________________________________________|
If needed, the gateway may use the key specified in the announcement to access the service. That key, in particular, may be used for the establishment of an L2TP tunnel.
如果需要，网关可以使用公告中指定的密钥访问服务。该密钥尤其可用于建立L2TP隧道。
The bearer attribute is composed of a bearer name and an optional extension. The bearer type specifies the type of modulation (modem name) or, in the case of digital connections, the type of ISDN service (8 bits, 7 bits). When an extension is present, it is separated from the bearer name by a single slash (/). The valid values of the bearer attribute are defined in the following table:
承载属性由承载名称和可选扩展名组成。承载类型指定调制类型（调制解调器名称），或者在数字连接的情况下，指定ISDN服务类型（8位、7位）。当存在扩展名时，它与承载名之间用一个斜杠（/）分隔。下表定义了承载属性的有效值：
____________________________________________________________________
| Type of bearer description | Example of values |
|_________________________________|_________________________________|
| ITU modem standard | V.32, V.34, V.90. |
| ITU modem standard qualified | v.90/3com, |
| by a manufacturer name | v.90/rockwell, |
| | v.90/xxx |
| Well known modem types | X2, K56flex |
| ISDN transparent access, 64 kbps| ISDN64 |
| ISDN64 + V.110 | ISDN64/V.110 |
| ISDN64 + V.120 | ISDN64/V.120 |
| ISDN transparent access, 56 kbps| ISDN56 |
| Informal identification | (Requires coordination between |
| | the Call Agent and the gateway)|
|_________________________________|_________________________________|
____________________________________________________________________
| Type of bearer description | Example of values |
|_________________________________|_________________________________|
| ITU modem standard | V.32, V.34, V.90. |
| ITU modem standard qualified | v.90/3com, |
| by a manufacturer name | v.90/rockwell, |
| | v.90/xxx |
| Well known modem types | X2, K56flex |
| ISDN transparent access, 64 kbps| ISDN64 |
| ISDN64 + V.110 | ISDN64/V.110 |
| ISDN64 + V.120 | ISDN64/V.120 |
| ISDN transparent access, 56 kbps| ISDN56 |
| Informal identification | (Requires coordination between |
| | the Call Agent and the gateway)|
|_________________________________|_________________________________|
The valid values of the framing attribute are defined in the following table:
框架属性的有效值在下表中定义：
_________________________________________________
| Type of framing description| Example of values|
|____________________________|___________________|
| PPP, asynchronous framing | ppp-asynch |
| PPP, HDLC framing | ppp-hdlc |
| SLIP, asynchronous | slip |
| Asynchronous, no framing | asynch |
|____________________________|___________________|
_________________________________________________
| Type of framing description| Example of values|
|____________________________|___________________|
| PPP, asynchronous framing | ppp-asynch |
| PPP, HDLC framing | ppp-hdlc |
| SLIP, asynchronous | slip |
| Asynchronous, no framing | asynch |
|____________________________|___________________|
The network access authentication parameter provides instructions on the access control that should be exercized for the data call. This optional attribute is encoded as:
network access authentication（网络访问身份验证）参数提供有关数据调用应执行的访问控制的说明。此可选属性编码为：
"a=subnet:" <network type> <address type>
<connection address> "/" <prefix length>
"a=subnet:" <network type> <address type>
<connection address> "/" <prefix length>
Where the parameters "network type", "address type", and "connection address" are formatted as defined for the connection address parameter (c=) in SDP, and where the "prefix length" is a decimal representation of the number of bits in the prefix.
其中，参数“网络类型”、“地址类型”和“连接地址”的格式与SDP中连接地址参数（c=）的定义相同，“前缀长度”是前缀中位数的十进制表示。
Examples of SDP announcement for the network access service could be:
网络接入服务的SDP公告示例如下：
v=0
m=nas/radius
c=IN IP4 radius.example.net
a=bearer:v.34
a=framing:ppp-asynch
a=dialed:18001234567
a=called:12345678901
a=dialing:12340567890
v=0
m=nas/radius
c=IN IP4 radius.example.net
a=bearer:v.34
a=framing:ppp-asynch
a=dialed:18001234567
a=called:12345678901
a=dialing:12340567890
v=0
m=nas/none
c=IN IP4 128.96.41.1
a=subnet:IN IP4 123.45.67.64/26
a=bearer:isdn64
a=framing:ppp-sync
a=dialed:18001234567
a=dialing:2345678901
v=0
m=nas/none
c=IN IP4 128.96.41.1
a=subnet:IN IP4 123.45.67.64/26
a=bearer:isdn64
a=framing:ppp-sync
a=dialed:18001234567
a=dialing:2345678901
v=0
c=IN IP4 access.example.net
m=nas/l2tp
k=clear:some-shared-secret
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
v=0
c=IN IP4 access.example.net
m=nas/l2tp
k=clear:some-shared-secret
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
The specification of the SDP payload for ATM connections will be described in a companion document, "Usage of MGCP to control Voice over ATM gateways." The following text is indicative.
ATM连接的SDP有效载荷规范将在配套文件“使用MGCP控制ATM网关上的语音”中描述。以下文本仅供参考。
The SDP payload will specify:
SDP有效载荷将指定：
* That the connection is to be established over an ATM interface, using the "c=" parameter of SDP to specify an address in the ATM family, the ATM addressing variant (NSAP, UNI, E.164) and the ATM address.
* 通过ATM接口建立连接，使用SDP的“c=”参数指定ATM系列中的地址、ATM寻址变量（NSAP、UNI、E.164）和ATM地址。
* The "m=audio" parameter will specify the audio encoding and, if needed, the VPI and VCI.
* “m=audio”参数将指定音频编码，如果需要，还将指定VPI和VCI。
* Additional attributes parameters (a=) will be used to specify the ATM coding variants, such as the type of adaptation layer and the error correction or loss compenmsation algorithms.
* 附加属性参数（a=）将用于指定ATM编码变体，例如适配层的类型和纠错或丢失补偿算法。
An example of SDP payload for an ATM connection could be:
ATM连接的SDP有效负载示例如下：
v=0 c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe m=audio
5/1002 ATM/AVP PCMU a=connection_type:AAL2
v=0 c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe m=audio
5/1002 ATM/AVP PCMU a=connection_type:AAL2
When MGCP is used to set up internal connections within a single gateway, the SDP format is used to encode the parameters of that connection. The following parameters will be used:
当MGCP用于在单个网关内建立内部连接时，SDP格式用于对该连接的参数进行编码。将使用以下参数：
* The connection parameter (C=) will specify that the connection is local, using the keyword "LOCAL" as network type space, the keyword "EPN" (endpoint name) as address type, and the name of the endpoint as the connection-address.
* 连接参数（C=）将指定连接是本地的，使用关键字“local”作为网络类型空间，关键字“EPN”（端点名称）作为地址类型，端点的名称作为连接地址。
* The "m=audio" parameter will specify a port number, which will always be set to 0, the type of protocol, always set to the keyword LOCAL, and the type of encoding, using the same conventions used for RTP (RTP payload numbers.) The type of encoding should normally be set to 0 (PCMU).
* “m=audio”参数将使用用于RTP（RTP有效负载编号）的相同约定，指定端口号（始终设置为0）、协议类型（始终设置为关键字LOCAL）和编码类型。编码类型通常应设置为0（PCMU）。
An example of local SDP payload could be:
本地SDP有效负载的一个示例可以是：
v=0
c=LOCAL EPN X35V3+A4/13
m=audio 0 LOCAL 0
v=0
c=LOCAL EPN X35V3+A4/13
m=audio 0 LOCAL 0
MGCP messages are transmitted over UDP. Commands are sent to one of the IP addresses defined in the DNS for the specified endpoint . The responses are sent back to the source address of the commands.
MGCP消息通过UDP传输。命令被发送到指定端点的DNS中定义的其中一个IP地址。响应被发送回命令的源地址。
When no port is specified for the endpoint, the commands should be sent:
如果未为端点指定端口，则应发送以下命令：
* by the Call Agents, to the default MGCP port for gateways, 2427.
* 由呼叫代理发送到网关的默认MGCP端口2427。
* by the Gateways, to the default MGCP port for Call Agents, 2727.
* 通过网关连接到呼叫代理的默认MGCP端口2727。
MGCP messages, being carried over UDP, may be subject to losses. In the absence of a timely response, commands are repeated. Most MGCP commands are not idempotent. The state of the gateway would become
通过UDP传输的MGCP消息可能会丢失。在没有及时响应的情况下，命令会重复执行。大多数MGCP命令不是幂等的。网关的状态将变为
unpredictable if, for example, CreateConnection commands were executed several times. The transmission procedures must thus provide an "At-Most-Once" functionality.
例如，如果多次执行CreateConnection命令，则不可预测。因此，传输程序必须提供“最多一次”功能。
MGCP entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently being executed. The transaction identifiers of incoming commands are compared to the transaction identifiers of the recent responses. If a match is found, the MGCP entity does not execute the transaction, but simply repeats the response. The remaining commands will be compared to the list of current transaction. If a match is found, the MGCP entity does not execute the transaction, which is simply ignored.
MGCP实体需要在内存中保存它们发送给最近事务的响应列表和当前正在执行的事务列表。将传入命令的事务标识符与最近响应的事务标识符进行比较。如果找到匹配项，则MGCP实体不执行事务，而只是重复响应。其余命令将与当前事务列表进行比较。如果找到匹配项，则MGCP实体不执行事务，这将被忽略。
The procedure use a long timer value, noted LONG-TIMER in the following. The timer should be set larger than the maximum duration of a transaction, which should take into account the maximum number of repetitions, the maximum value of the repetition timer and the maximum propagation delay of a packet in the network. A suggested value is 30 seconds.
该程序使用一个长定时器值，如下所示为长定时器。计时器的设置应大于事务的最大持续时间，这应考虑最大重复次数、重复计时器的最大值以及网络中数据包的最大传播延迟。建议值为30秒。
The copy of the responses can be destroyed either LONG-TIMER seconds after the response is issued, or when the gateway (or the call agent) receives a confirmation that the response has been received, through the "Response Acknowledgement attribute". For transactions that are acknowledged through this attribute, the gateway shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, in order to detect and ignore duplicate copies of the transaction request that could be produced by the network.
响应的副本可以在响应发出后长时间内销毁，也可以在网关（或呼叫代理）通过“响应确认属性”接收到已接收到响应的确认时销毁。对于通过此属性确认的交易，网关应在响应发出后长时间保留交易id的副本，以便检测和忽略网络可能产生的交易请求的副本。
Transaction identifiers are integer numbers in the range from 0 to 999,999,999. Call-agents may decide to use a specific number space for each of the gateways that they manage, or to use the same number space for all gateways that belong to some arbitrary group. Call agents may decide to share the load of managing a large gateway between several independent processes. These processes will share the same transaction number space. There are multiple possible implementations of this sharing, such as having a centralized allocation of transaction identifiers, or pre-allocating non-overlapping ranges of identifiers to different processes. The implementations must guarantee that unique transaction identifiers are allocated to all transactions that originate from a logical call agent, as defined in the "states, failover and race conditions" section. Gateways can simply detect duplicate transactions by looking at the transaction identifier only.
事务标识符是介于0到99999999之间的整数。呼叫代理可能决定为其管理的每个网关使用特定的号码空间，或为属于某个任意组的所有网关使用相同的号码空间。呼叫代理可能决定在多个独立进程之间分担管理大型网关的负载。这些进程将共享相同的事务编号空间。这种共享有多种可能的实现，例如事务标识符的集中分配，或者将不重叠的标识符范围预分配给不同的进程。这些实现必须保证为源自逻辑调用代理的所有事务分配唯一的事务标识符，如“状态、故障切换和竞争条件”部分中所定义。网关只需查看事务标识符即可检测重复事务。
The Response Acknowledgement Attribute can be found in any command. It carries a set of "confirmed transaction-id ranges."
响应确认属性可以在任何命令中找到。它携带一组“已确认的交易id范围”
MGCP gateways may choose to delete the copies of the responses to transactions whose id is included in "confirmed transaction-id ranges" received in the Response Confirmation messages. They should silently discard further commands from that Call Agent when the transaction-id falls within these ranges.
MGCP网关可以选择删除响应确认消息中接收到的id包含在“已确认的事务id范围”中的事务的响应副本。当事务id在这些范围内时，它们应该悄悄地放弃来自调用代理的进一步命令。
The "confirmed transaction-id ranges" values shall not be used if more than LONG-TIMER seconds have elapsed since the gateway issued its last response to that call agent, or when a gateway resumes operation. In this situation, commands should be accepted and processed, without any test on the transaction-id.
如果自网关向该呼叫代理发出最后一次响应后已超过长定时器秒，或者当网关恢复运行时，不得使用“确认的事务id范围”值。在这种情况下，应该接受和处理命令，而不需要对transaction-id进行任何测试。
Commands that carry the "Response Acknowledgement attribute" may be transmitted in disorder. The gateway shall retain the union of the "confirmed transaction-id ranges" received in recent commands.
携带“响应确认属性”的命令可能会无序传输。网关应保留最近命令中收到的“已确认交易id范围”的并集。
It is the responsibility of the requesting entity to provide suitable time outs for all outstanding commands, and to retry commands when time outs have been exceeded. Furthermore, when repeated commands fail to be acknowledged, it is the responsibility of the requesting entity to seek redundant services and/or clear existing or pending connections.
请求实体负责为所有未完成的命令提供适当的超时，并在超过超时时重试命令。此外，当重复命令未被确认时，请求实体有责任寻求冗余服务和/或清除现有或挂起的连接。
The specification purposely avoids specifying any value for the retransmission timers. These values are typically network dependent. The retransmission timers should normally estimate the timer by measuring the time spent between the sending of a command and the return of a response. One possibility is to use the algorithm implemented in TCP-IP, which uses two variables:
该规范有意避免为重传定时器指定任何值。这些值通常依赖于网络。重传计时器通常应通过测量发送命令和返回响应之间的时间来估计计时器。一种可能性是使用TCP-IP中实现的算法，该算法使用两个变量：
* the average acknowledgement delay, AAD, estimated through an exponentially smoothed average of the observed delays,
* 通过观察到的延迟的指数平滑平均值估计的平均确认延迟AAD，
* the average deviation, ADEV, estimated through an exponentially smoothed average of the absolute value of the difference between the observed delay and the current average
* 平均偏差ADEV，通过观察到的延迟与当前平均值之差的绝对值的指数平滑平均值进行估计
The retransmission timer, in TCP, is set to the sum of the average delay plus N times the average deviation. In MGCP, the maximum value of the timer should however be bounded, in order to guarantee that no repeated packet will be received by the gateways after LONG-TIMER seconds. A suggested maximum value is 4 seconds.
TCP中的重传计时器设置为平均延迟加上N倍平均偏差之和。然而，在MGCP中，定时器的最大值应该是有界的，以保证在长时间定时器秒后网关不会接收到重复的数据包。建议的最大值为4秒。
After any retransmission, the MGCP entity should do the following:
在任何重传之后，MGCP实体应执行以下操作：
* It should double the estimated value of the average delay, AAD
* 它应该是平均延迟AAD估计值的两倍
* It should compute a random value, uniformly distributed between 0.5 AAD and AAD
* 它应该计算一个随机值，均匀分布在0.5 AAD和AAD之间
* It should set the retransmission timer to the sum of that random value and N times the average deviation.
* 它应该将重传计时器设置为该随机值和N倍平均偏差之和。
This procedure has two effects. Because it includes an exponentially increasing component, it will automatically slow down the stream of messages in case of congestion. Because it includes a random component, it will break the potential synchronization between notifications triggered by the same external event.
这个过程有两个效果。因为它包含了一个指数级增长的组件，它会在拥塞情况下自动降低消息流的速度。因为它包含一个随机组件，它将破坏由同一外部事件触发的通知之间的潜在同步。
There are cases when a Call Agent will want to send several messages at the same time to the same gateways. When several MGCP messages have to be sent in the same UDP packets, they should be separated by a line of text that contain a single dot, as in for example:
在某些情况下，呼叫代理希望同时向同一网关发送多条消息。当必须在同一UDP数据包中发送多个MGCP消息时，应使用一行包含单个点的文本分隔这些消息，例如：
200 2005 OK DLCX 1244 card23/21@trgw-7.example.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8
200 2005正常DLCX 1244卡23/21@trgw-7.example.net MGCP 1.0 C:A3C47F21456789F0 I:FDE234C8
The piggy-backed messages should be processed exactly has if they had been received in several simultaneous messages.
如果在多条同步消息中接收到了这些消息，则应该准确地处理这些消息。
Executing some transactions may require a long time. Long execution times may interact with the timer based retransmission procedure. This may result either in an inordinate number of retransmissions, or in timer values that become too long to be efficient.
执行某些事务可能需要很长时间。长执行时间可能与基于计时器的重传过程相互作用。这可能导致重新传输的次数过多，或者导致计时器值变得太长而无法发挥效率。
Gateways that can predict that a transaction will require a long execution time may send a provisional response, with response code 100. They should send this response if they receive a repetition of a transaction that is still being executed.
可以预测事务将需要较长执行时间的网关可以发送临时响应，响应代码为100。如果接收到仍在执行的事务的重复，则应发送此响应。
MGCP entities that receive a provisional response shall switch to a longer repetition timer for that transaction.
收到临时响应的MGCP实体应为该事务切换到更长的重复计时器。
4. States, failover and race conditions.
4. 状态、故障转移和竞争条件。
In order to implement proper call signalling, the Call Agent must keep track of the state of the endpoint, and the gateway must make sure that events are properly notified to the call agent. Special conditions exist when the gateway or the call agent are restarted: the gateway must be redirected to a new call agent during "failover" procedures, the call agent must take special action when the gateway is taken offline, or restarted.
为了实现正确的呼叫信令，呼叫代理必须跟踪端点的状态，网关必须确保事件正确通知呼叫代理。重新启动网关或呼叫代理时存在特殊情况：在“故障切换”过程中，网关必须重定向到新的呼叫代理，当网关脱机或重新启动时，呼叫代理必须采取特殊操作。
The support of "failover" is based on the following assumptions:
“故障切换”的支持基于以下假设：
* Call Agents are identified by their domain name, not their network addresses, and several addresses can be associated with a domain name.
* 呼叫代理通过其域名而不是网络地址进行标识，并且多个地址可以与一个域名关联。
* An endpoint has one NotifiedEntity associated with it any given point in time.
* 端点在任何给定的时间点都有一个与之关联的通知身份。
* The NotifiedEntity is the last value of the "NotifiedEntity" parameter received for this endpoint (including wild-carded end-point-names). If no explicit "NotifiedEntity" parameter has been received, the "NotifiedEntity" defaults to the provisioned NotifiedEntity value, or if no value was provisioned to the source address of the last command received for the endpoint,
* NotifiedEntity是为此端点接收的“NotifiedEntity”参数的最后一个值（包括通配符端点名称）。如果未收到明确的“NotifiedEntity”参数，“NotifiedEntity”默认为已设置的NotifiedEntity值，或者如果未为端点接收的最后一个命令的源地址设置值，
* Responses to commands are always sent to the source address of the command, regardless of the NotifiedEntity.
* 对命令的响应始终发送到命令的源地址，而不考虑通知的身份。
* When the "notified entity" refers to a domain name that resolves to multiple IP- address, endpoints are capable of switching between different interfaces on the same logical call agent, however they cannot switch to other (backup) call agent(s) on their own. A backup call agent can however instruct them to switch, either directly or indirectly.
* 当“通知实体”指解析为多个IP地址的域名时，端点能够在同一逻辑呼叫代理上的不同接口之间切换，但是它们不能自己切换到其他（备份）呼叫代理。但是，备用呼叫代理可以直接或间接指示他们切换。
* If an entire call agent becomes unavailable, the endpoints managed by that call agent will eventually become "disconnected". The only way for these endpoints to become connected again is either for the failed call agent to become available, or for a backup call agent to contact the affected endpoints.
* 如果整个呼叫代理变得不可用，则由该呼叫代理管理的端点最终将变得“断开”。这些端点重新连接的唯一方法是让失败的呼叫代理变得可用，或者让备份呼叫代理联系受影响的端点。
* When a backup call agent has taken over control of a group of endpoints, it is assumed that the failed call agent will communicate and synchronize with the backup call agent in order to
* 当备份呼叫代理已接管一组端点的控制时，假定失败的呼叫代理将与备份呼叫代理通信并同步，以便
transfer control of the affected endpoints back to the original call agent (if that's even desired - maybe the failed call agent should simply become the backup call agent now).
将受影响端点的控制权转移回原始调用代理（如果需要的话，可能失败的调用代理现在应该成为备份调用代理）。
We should note that handover conflict resolution between separate CA's is not in place - we are relying strictly on the CA's knowing what they are doing and communicating with each other (although AuditEndpoint can be used to learn about the current NotifiedEntity).
我们应该注意到，独立CA之间的切换冲突解决方案并不到位——我们严格依赖于CA了解他们在做什么并相互通信（尽管AuditEndpoint可用于了解当前的身份）。
4.2. Security, Retransmission, and Detection of Lost Associations:
4.2. 安全、重传和检测丢失的关联：
The media gateway control protocol is organized as a set of transactions, each of which is composed of a command and a response, commonly referred to as an acknowledgement. The MGCP messages, being carried over UDP, may be subject to losses. In the absence of a timely response, commands are repeated. MGCP entities are expected to keep in memory a list of the responses that they sent to recent transactions, i.e. a list of all the responses they sent over the last LONG-TIMER seconds, and a list of the transactions that are currently being executed.
媒体网关控制协议被组织为一组事务，每个事务由命令和响应（通常称为确认）组成。通过UDP传输的MGCP消息可能会丢失。在没有及时响应的情况下，命令会重复执行。MGCP实体应在内存中保留其发送给最近事务的响应列表，即，在过去长时间内发送的所有响应的列表，以及当前正在执行的事务的列表。
The transaction identifiers of incoming commands are compared to the transaction identifiers of the recent responses. If a match is found, the MGCP entity does not execute the transaction, but simply repeats the response. The remaining commands will be compared to the list of current transaction. If a match is found, the MGCP entity does not execute the transaction, which is simply ignored - a response will be provided when the execution of the command is complete.
将传入命令的事务标识符与最近响应的事务标识符进行比较。如果找到匹配项，则MGCP实体不执行事务，而只是重复响应。其余命令将与当前事务列表进行比较。如果找到匹配项，则MGCP实体不执行事务，这将被忽略-当命令执行完成时将提供响应。
The repetition mechanism is used to guard against four types of possible errors:
重复机制用于防止四种可能的错误：
* transmission errors, when for example a packet is lost due to noise on a line or congestion in a queue,
* 传输错误，例如，由于线路上的噪音或队列中的拥塞导致数据包丢失时，
* component failure, when for example an interface to a call agent becomes unavailable,
* 组件故障，例如呼叫代理接口不可用时，
* call agent failure, when for example an entire call agent becomes unavailable,
* 呼叫代理失败，例如，当整个呼叫代理变得不可用时，
* failover, when a new call agent is "taking over" transparently.
* 故障转移，当新呼叫代理以透明方式“接管”时。
The elements should be able to derive from the past history an estimate of the packet loss rate due to transmission errors. In a properly configured system, this loss rate should be kept very low, typically less than 1%. If a call agent or a gateway has to repeat a message more than a few times, it is very legitimate to assume that
这些元件应当能够从过去的历史中得出由于传输错误而导致的分组丢失率的估计值。在正确配置的系统中，此丢失率应保持非常低，通常小于1%。如果呼叫代理或网关必须重复一条消息多次，那么假设这样做是非常合理的
something else than a transmission error is occurring. For example, given a loss rate of 1%, the probability that 5 consecutive transmission attempts fail is 1 in 100 billion, an event that should occur less than once every 10 days for a call agent that processes 1,000 transactions per second. (Indeed, the number of repetition that is considered excessive should be a function of the prevailing packet loss rate.) We should note that the "suspicion threshold", which we will call "Max1", is normally lower than the "disconnection threshold", which should be set to a larger value.
正在发生传输错误以外的其他错误。例如，如果丢失率为1%，则5次连续传输尝试失败的概率为1000亿分之一，对于每秒处理1000个事务的呼叫代理，该事件应不到每10天发生一次。（事实上，被认为过多的重复次数应该是当前数据包丢失率的函数。）我们应该注意到，我们称之为“Max1”的“怀疑阈值”通常低于“断开阈值”，而“断开阈值”应该设置为更大的值。
Command issued: N=0
|
transmission: N++
| +------------ retransmission: N++ -----------+
| | |
| | transmission |
| | +---to new address -+<--------------------|--+
| | | N=0 | | |
V V V | | |
+-----------+ | | |
| awaiting |- new call agent ->+ +------------+ | |
| response |--- timer elapsed --->| N > Max1 ? |-(no)+ |
+-----------+ <----------+ +------------+ ^ |
| | | | | |
| +- wrong key? -+ (yes) | |
| | | |
response received (if N=Max1, | |
| or N=Max2 | |
| check DNS) | |
v | | |
(end) +---------------+ | |
|more addresses?|(yes)|--+
+---------------+ |
| |
(no) |
| |
+------------+ |
| N > Max2 ? |(no)-+
+------------+
|
(yes)
|
v
(disconnected)
Command issued: N=0
|
transmission: N++
| +------------ retransmission: N++ -----------+
| | |
| | transmission |
| | +---to new address -+<--------------------|--+
| | | N=0 | | |
V V V | | |
+-----------+ | | |
| awaiting |- new call agent ->+ +------------+ | |
| response |--- timer elapsed --->| N > Max1 ? |-(no)+ |
+-----------+ <----------+ +------------+ ^ |
| | | | | |
| +- wrong key? -+ (yes) | |
| | | |
response received (if N=Max1, | |
| or N=Max2 | |
| check DNS) | |
v | | |
(end) +---------------+ | |
|more addresses?|(yes)|--+
+---------------+ |
| |
(no) |
| |
+------------+ |
| N > Max2 ? |(no)-+
+------------+
|
(yes)
|
v
(disconnected)
A classic retransmission algorithm would simply count the number of successive repetitions, and conclude that the association is broken after re-transmitting the packet an excessive number of times
经典的重传算法只需计算连续重复的次数，并得出结论，在多次重新传输数据包后，关联被破坏
(typically between 7 and 11 times.) In order to account for the possibility of an undetected or in-progress "failover", we modify the classic algorithm as follows:
（通常在7到11次之间）为了考虑未检测到或正在进行的“故障切换”的可能性，我们对经典算法进行了如下修改：
* We request that the gateway always checks for the presence of a new call agent. It can be noticed either by
* 我们要求网关始终检查是否存在新的呼叫代理。它可以通过以下两种方式被注意到：
- receiving a valid multicast message announcing a failover, or
- 接收到宣布故障转移的有效多播消息，或
- receiving a command where the NotifiedEntity points to the new call agent, or
- 接收通知身份指向新呼叫代理的命令，或
- receiving a redirection response pointing to a new Call Agent.
- 接收指向新呼叫代理的重定向响应。
If a new call agent is detected, the gateway starts transmitting outstanding commands to that new agent. Responses to commands are still transmitted to the source address of the command.
如果检测到新的呼叫代理，网关将开始向该新代理发送未完成的命令。对命令的响应仍然传输到命令的源地址。
* we request that if the number of repetitions for this Call Agent is larger than "Max1", that the gateway actively queries the name server in order to detect the possible change of the call agent interfaces.
* 我们请求，如果此呼叫代理的重复次数大于“Max1”，则网关主动查询名称服务器，以便检测呼叫代理接口的可能更改。
* The gateway may have learned several IP addresses for the call agent. If the number of repetitions is larger than "Max1" and lower than "Max2", and there are more interfaces that have not been tried, then the gateway should direct the retransmissions to alternate addresses.
* 网关可能已读入呼叫代理的多个IP地址。如果重复次数大于“Max1”且小于“Max2”，且有更多接口尚未尝试，则网关应将重传定向到备用地址。
* If there are no more interfaces to try, and the number of repetitions is Max2, then the gateway contacts the DNS one more time to see if any other interface should have become available. If not, the gateway is now disconnected.
* 如果没有更多的接口可供尝试，且重复次数为Max2，则网关将再次联系DNS，以查看是否有任何其他接口可用。如果没有，网关现在已断开连接。
The procedure will maximize the chances of detecting an ongoing failover. It poses indeed two very specific problems, the potentially long delays of a timer based procedure and the risk of confusion caused by the use of cryptographic protections.
该过程将最大限度地提高检测正在进行的故障切换的机会。它确实带来了两个非常具体的问题，一个是基于计时器的过程可能会有很长的延迟，另一个是由于使用密码保护而造成混乱的风险。
In order to automatically adapt to network load, MGCP specifies exponentially increasing timers. If the initial timer is set to 200 milliseconds, the loss of a fifth retransmission will be detected after about 6 seconds. This is probably an acceptable waiting delay to detect a failover. The repetitions should continue after that delay not only in order to perhaps overcome a transient connectivity problem, but also in order to allow some more time for the execution of a failover - waiting a total delay of 30 seconds is probably acceptable.
为了自动适应网络负载，MGCP指定了指数增长的计时器。如果初始计时器设置为200毫秒，则在大约6秒后将检测到第五次重新传输的丢失。这可能是检测故障转移的可接受等待延迟。在该延迟之后，重复应该继续进行，这不仅是为了克服暂时的连接问题，也是为了允许更多的时间执行故障切换-等待30秒的总延迟可能是可以接受的。
It is however important that the maximum delay of retransmissions be bounded. Prior to any retransmission, it is checked that the time elapsed since the sending of the initial datagram is no greater than T- MAX. If more than T-MAX time has elapsed, the endpoint becomes disconnected. The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is obtained by adding to T-MAX the maximum propagation delay in the network.
然而，重要的是，重传的最大延迟是有界的。在任何重传之前，检查初始数据报发送后经过的时间是否不大于T-MAX。如果经过的时间超过T-MAX，则端点断开连接。值T-MAX与长定时器值相关：长定时器值是通过将网络中的最大传播延迟添加到T-MAX中获得的。
Another potential cause of connection failure would be the reception of a "wrong key" message, sent by a call agent that could not authenticate the command, presumably because it had lost the security parameters of the association. Such messages are actually not authorized in IPSEC, and they should in fact not be taken at face value: an attacker could easily forge "wrong key" messages in order to precipitate the loss of a control connection. The current algorithm ignores these messages, which translates into a strict reliance on timers. The algorithm could in fact be improved, maybe by executing a check with the key server of the call agent after "Max1" repetitions.
连接失败的另一个潜在原因是接收到呼叫代理发送的“错误密钥”消息，该消息无法对命令进行身份验证，可能是因为它丢失了关联的安全参数。这类消息实际上在IPSEC中未经授权，事实上不应将其视为表面价值：攻击者很容易伪造“错误的密钥”消息，从而导致控制连接的丢失。当前的算法忽略了这些消息，这转化为对计时器的严格依赖。该算法实际上可以得到改进，可能是在“Max1”重复之后，通过调用代理的密钥服务器执行检查。
MGCP deals with race conditions through the notion of a "quarantine list" and through explicit detection of desynchronization.
MGCP通过“隔离列表”的概念和显式检测去同步来处理竞争条件。
MGCP does not assume that the transport mechanism will maintain the order of command and responses. This may cause race conditions, that may be obviated through a proper behavior of the call agent. (Note that some race conditions are inherent to distributed systems; they would still occur, even if the commands were transmitted in strict order.)
MGCP不认为传输机制将维持命令和响应的顺序。这可能会导致竞争条件，这可以通过调用代理的正确行为来避免。（请注意，某些竞争条件是分布式系统固有的；即使命令以严格的顺序传输，它们仍然会发生。）
In some cases, many gateways may decide to restart operation at the same time. This may occur, for example, if an area loses power or transmission capability during an earthquake or an ice storm. When power and transmission are reestablished, many gateways may decide to send "RestartInProgress" commands simultaneously, leading to very unstable operation.
在某些情况下，许多网关可能决定同时重新启动操作。例如，如果一个地区在地震或冰暴期间失去电力或传输能力，则可能发生这种情况。当重新建立电源和传输时，许多网关可能决定同时发送“重新启动进程”命令，从而导致非常不稳定的操作。
MGCP controlled gateways will receive "notification requests" that ask them to watch for a list of "events." The protocol elements that determine the handling of these events are the "Requested Events" list, the "Digit Map" and the "Detect Events" list.
MGCP控制的网关将接收“通知请求”，要求它们监视“事件”列表。确定这些事件处理的协议元素是“请求的事件”列表、“数字映射”和“检测事件”列表。
When the endpoint is initialized, the requested events list and the digit map are empty. After reception of a command, the gateway starts observing the endpoint for occurrences of the events mentioned in the list.
初始化端点时，请求的事件列表和数字映射为空。接收到命令后，网关开始观察端点是否出现列表中提到的事件。
The events are examined as they occur. The action that follows is determined by the "action" parameter associated to the event in the list of requested events, and also by the digit map. The events that are defined as "accumulate" or "treat according to digit map" are accumulated in a list of events, the events that are marked as "treated according to the digit map" will additionally be accumulated in the dialed string. This will go on until one event is encountered that triggers a Notification to the "notified entity."
在事件发生时对其进行检查。接下来的操作由请求事件列表中与事件关联的“action”参数以及数字映射确定。定义为“累积”或“根据数字映射处理”的事件累积在事件列表中，标记为“根据数字映射处理”的事件将额外累积在拨号字符串中。这将一直持续到遇到一个事件触发对“已通知实体”的通知为止
The gateway, at this point, will transmit the notification command and will place the endpoint in a "notification" state. As long as the endpoint is in this notification state, the events that are to be detected on the endpoint are stored in a "quarantine" buffer for later processing. The events are, in a sense, "quarantined." All events that are specified by the union of the RequestedEvents parameter and the most recently received DetectEvent parameter or, in the absence of the latter, all events that are referred to in the RequestedEvents, should be detected and quarantined, regardless of the action associated to the event.
此时，网关将发送通知命令，并将端点置于“通知”状态。只要端点处于此通知状态，将在端点上检测到的事件存储在“隔离”缓冲区中，以供以后处理。从某种意义上说，这些事件是“隔离的”。应该检测并隔离由RequestedEvents参数和最近接收的detectedEvent参数联合指定的所有事件，或者，如果没有后者，则应检测并隔离RequestedEvents中引用的所有事件，而不考虑与事件相关的操作。
The endpoint exits the "notification state" when the acknowledgement of the Notify command is received. The Notify command may be retransmitted in the "notification state", as specified in section 3.5. When the endpoint exits the "notification state" it resets the list of observed events and the "current dial string" of the endpoint to a null value.
当接收到Notify命令的确认时，端点退出“通知状态”。Notify命令可在第3.5节规定的“通知状态”下重新传输。当端点退出“通知状态”时，它会将观察到的事件列表和端点的“当前拨号字符串”重置为空值。
Following that point, the behavior of the gateway depends on the value of The QuarantineHandling parameter in the notification request. If the Call Agent specified that it expected at most one notification in response to the notification request command, then the gateway should simply keep on accumulating events in the quarantine list until it receives the next notification request command.
在此之后，网关的行为取决于通知请求中QuarantineHandling参数的值。如果呼叫代理指定它最多需要一个通知来响应通知请求命令，那么网关应该继续在隔离列表中累积事件，直到它收到下一个通知请求命令。
If the gateway is authorized to send multiple successive Notify commands, it will proceed as follows. When the gateway exits the "notification state", it resets the list of observed events and the "current dial string" of the endpoint to a null value and starts processing the list of quarantined events, using the already received list of requested events and digit map. When processing these events,
如果网关被授权发送多个连续的Notify命令，它将按以下步骤进行。当网关退出“通知状态”时，它会将观察到的事件列表和端点的“当前拨号字符串”重置为空值，并使用已收到的请求事件列表和数字映射开始处理隔离事件列表。在处理这些事件时，
the gateway may encounter an event which requires a Notify command to be sent. If that is the case, the gateway can adopt one of the two following behaviors:
网关可能遇到需要发送Notify命令的事件。如果是这种情况，网关可以采用以下两种行为之一：
* it can immediately transmit a Notify command that will report all events that were accumulated in the list of observed events until the triggering event, included, leaving the unprocessed events in the quarantine list,
* 它可以立即发送Notify命令，该命令将报告观察到的事件列表中累积的所有事件，直到触发事件（包括在内），将未处理的事件保留在隔离列表中，
* or it can attempt to empty the quarantined list and transmit a single Notify command reporting several sets of events and possibly several dial strings. The dial string is reset to a null value after each triggering event. The events that follow the last triggering event are left in the quarantine list.
* 或者，它可以尝试清空隔离列表，并发送一个Notify命令，报告多组事件，可能还有多个拨号字符串。每次触发事件后，拨号字符串重置为空值。上次触发事件之后的事件保留在隔离列表中。
If the gateway transmits a Notify command, the end point will remain in the "notification state" until the acknowledgement is received. If the gateway does not find a quarantined event that requests a Notify command, it places the end point in a normal state. Events are then processed as they come, in exactly the same way as if a Notification Request command had just been received.
如果网关发送Notify命令，端点将保持“通知状态”，直到收到确认。如果网关未找到请求Notify命令的隔离事件，则会将端点置于正常状态。然后，事件在发生时进行处理，处理方式与刚刚收到通知请求命令完全相同。
A gateway may receive at any time a new Notification Request command for the end point. When a new notification request is received in the notification state, the gateway shall ensure that the pending notification is received by the Call Agent prior to a successful response to the new NotificationRequest. It does so by using the "piggy-backing" functionality of the protocol. The messages will then be sent in a single packetto the source of the new NotificationRequest, regardless of respectively the source and "notified entity" for the old and new command. The steps involved are the following:
网关可在任何时候接收针对端点的新通知请求命令。当在通知状态下收到新通知请求时，网关应确保呼叫代理在成功响应新通知请求之前收到待决通知。它通过使用协议的“背驮”功能来实现这一点。然后，消息将以单个包的形式发送到新NotificationRequest的源，而不考虑新旧命令的源和“通知实体”。涉及的步骤如下：
a) the gateway builds a message that carries in a single packet a repetition of the old pending Notify command and the acknowledgement of the new notification request.
a) 网关构建一条消息，该消息在单个数据包中携带旧的挂起通知命令的重复和新通知请求的确认。
b) the endpoint is then taken out of the "notification state" without waiting for the acknowledgement of the notification command.
b) 然后将端点从“通知状态”中取出，而无需等待通知命令的确认。
c) a copy of the unacknowledged Notify command command is kept until an acknowledgement is received. If a timer elapses, the notification will be repeated, in a packet that will also carry a repetition of the acknowledgement of the notification request.
c) 将保留未确认的Notify命令的副本，直到收到确认。如果计时器过期，通知将在一个包中重复，该包还将重复发送通知请求的确认。
d) if the acknowledgement is lost, the Call Agent will retransmit the Notification Request. The gateway will reply to this repetition by retransmitting in a single packet the unacknowledged Notify and the acknowledgement of the notification request.
d) 如果确认丢失，呼叫代理将重新传输通知请求。网关将通过在单个数据包中重新传输未确认的通知和通知请求的确认来回复此重复。
e) if the gateway has to transmit a Notify before the previous Notify is acknowledged, it should construct a packet that piggybacks a repetition of the old Notify, a repetition of the acknowledgement of the last notification request and the new Notify.
e) 如果网关必须在确认前一个通知之前发送通知，那么它应该构造一个数据包，该数据包承载旧通知的重复、上一个通知请求的重复确认和新通知。
f) Gateways that cannot piggyback several packets in the same message should elect to leave the endpoint in the "notification" state as long as the last notification is not acknowledged.
f) 不能在同一消息中搭载多个数据包的网关应选择在最后一个通知未确认的情况下将端点保持在“通知”状态。
After receiving the Notification Request command, the requested events list and digit map (if a new one was provided) are replaced by the newly received parameters, and the list of observed events and accumulated dial string are reset to a null value. The behavior is conditioned by the value of the QuarantineHandling parameter. The parameter may specify that quarantined events, or previously observed events, should be discarded, in which case they will be. If the parameter specifies that the quarantined events should be processed, the gateway will start processing the list of quarantined events or previously observed events, using the newly received list of requested events and digit map. When processing these events, the gateway may encounter an event which requires a Notify command to be sent. If that is the case, the gateway will immediately transmit a Notify command that will report all events that were accumulated in the list of observed events until the triggering event, included, leaving the unprocessed events in the quarantine buffer, and will enter the "notification state".
接收到通知请求命令后，请求的事件列表和数字映射（如果提供了新的）将替换为新接收的参数，观察到的事件列表和累积拨号字符串将重置为空值。该行为由QuarantineHandling参数的值决定。该参数可以指定应丢弃隔离的事件或以前观察到的事件，在这种情况下，它们将被丢弃。如果该参数指定应处理隔离事件，网关将使用新收到的请求事件列表和数字映射，开始处理隔离事件列表或以前观察到的事件。在处理这些事件时，网关可能会遇到需要发送Notify命令的事件。如果是这种情况，网关将立即发送Notify命令，该命令将报告在所观察事件列表中累积的所有事件，直到触发事件（包括）将未处理的事件留在隔离缓冲区中，并将进入“通知状态”。
A new notification request may be received while the gateway has accumulated events according to the previous notification requests, but has not yet detected a notification-triggering events. The handling of not-yet-notified events is determined, as with the quarantined events, by the quarantine handling parameters:
当网关已根据先前的通知请求累积事件，但尚未检测到通知触发事件时，可接收新的通知请求。与隔离事件一样，未通知事件的处理由隔离处理参数决定：
* If the quarantine-handling parameter specifies that quarantined events shall be ignored, the observed event list is simply reset.
* 如果隔离处理参数指定应忽略隔离事件，则只需重置观察到的事件列表。
* If the quarantine-handling parameter specifies that quarantined events shall be processed, the observed event list is transferred to the quarantined event list. The observed event list is then reset, and the quarantined event list is processed.
* 如果隔离处理参数指定应处理隔离事件，则观察到的事件列表将传输到隔离事件列表。然后重置观察到的事件列表，并处理隔离的事件列表。
Call Agents SHOULD provide the response to a successful Notify message and the new NotificationRequest in the same datagram using the piggy-backing mechanism.
呼叫代理应使用piggy backing机制在同一数据报中提供对成功通知消息和新NotificationRequest的响应。
A key element of the state of several endpoints is the position of the hook. A race condition may occur when the user decides to go off-hook before the Call Agent has the time to ask the gateway to notify an off hook event (the "glare" condition well known in telephony), or if the user goes on-hook before the Call Agent has the time to request the event's notification.
多个端点状态的一个关键元素是挂钩的位置。当用户决定在呼叫代理有时间要求网关通知脱钩事件之前脱钩（电话中众所周知的“眩光”情况），或者如果用户在呼叫代理有时间请求事件通知之前脱钩，则可能发生竞态情况。
To avoid this race condition, the gateway should check the condition of the endpoint before acknowledging a NotificationRequest. It should return an error:
为了避免这种竞争状况，网关应该在确认NotificationRequest之前检查端点的状况。它应该返回一个错误：
1- If the gateway is requested to notify an "off hook" transition while the phone is already off hook,
1-如果请求网关在手机已脱离连接时通知“脱离连接”转换，
2- If the gateway is requested to notify an "on hook" or "flash hook" condition while the phone is already on hook.
2-如果请求网关在手机已挂机时通知“挂机”或“闪存挂机”情况。
It should be noted, that the condition check is performed at the time the notification request is received, where as the actual event that caused the current condition may have either been reported, or ignored earlier, or it may currently be quarantined.
应注意的是，在收到通知请求时执行条件检查，其中，导致当前条件的实际事件可能已经报告，或在之前被忽略，或者当前可能被隔离。
The other state variables of the gateway, such as the list of RequestedEvent or list of requested signals, are entirely replaced after each successful NotificationRequest, which prevents any long term discrepancy between the Call Agent and the gateway.
网关的其他状态变量，如RequestedEvent列表或requested signals列表，在每次成功的NotificationRequest之后都会被完全替换，这防止了呼叫代理和网关之间的任何长期差异。
When a NotificationRequest is unsuccessful, whether it is included in a connection-handling command or not, the gateway will simply continue as if the command had never been received. As all other transactions, the NotificationRequest should operate as an atomic transaction, thus any changes initiated as a result of the command should be reverted.
当NotificationRequest不成功时，无论它是否包含在连接处理命令中，网关都将继续，就像从未收到该命令一样。与所有其他事务一样，NotificationRequest应作为一个原子事务运行，因此，应恢复由于该命令而启动的任何更改。
Another race condition may occur when a Notify is issued shortly before the reception by the gateway of a NotificationRequest. The RequestIdentifier is used to correlate Notify commands with NotificationRequest commands.
当网关在接收NotificationRequest之前不久发出通知时，可能会发生另一种竞争情况。RequestIdentifier用于将Notify命令与NotificationRequest命令关联起来。
MGCP does not mandate that the underlying transport protocol guarantees the sequencing of commands sent to a gateway or an endpoint. This property tends to maximize the timeliness of actions, but it has a few draw backs. For example:
MGCP并不要求底层传输协议保证发送到网关或端点的命令的顺序。此属性倾向于最大化操作的及时性，但它有一些缺点。例如：
* Notify commands may be delayed and arrive to the call agent after the transmission of a new Notification Request command,
* 通知命令可能会延迟，并在传输新的通知请求命令后到达呼叫代理，
* If a new NotificationRequest is transmitted before a previous one is acknowledged, there is no guarantee that the previous one will not be received in second position.
* 如果在确认前一个通知请求之前发送了新的通知请求，则不能保证前一个通知请求不会在第二个位置收到。
Call Agents that want to guarantee consistent operation of the end points can use the following rules:
想要保证端点一致运行的呼叫代理可以使用以下规则：
1) When a gateway handles several endpoints, commands pertaining to the different endpoints can be sent in parallel, for example following a model where each endpoint is controlled by its own process or its own thread.
1) 当网关处理多个端点时，可以并行发送与不同端点相关的命令，例如，遵循一个模型，其中每个端点由其自己的进程或线程控制。
2) When several connections are created on the same endpoint, commands pertaining to different connections can be sent in parallel.
2) 在同一端点上创建多个连接时，可以并行发送与不同连接相关的命令。
3) On a given connection, there should normally be only one outstanding command (create or modify). However, a DeleteConnection command can be issued at any time. In consequence, a gateway may sometimes receive a ModifyConnection command that applies to a previously deleted connection. Such commands should be ignored, and an error code should be returned.
3) 在给定的连接上，通常只有一个未完成的命令（创建或修改）。但是，可以随时发出DeleteConnection命令。因此，网关有时可能会收到适用于先前删除的连接的ModifyConnection命令。应忽略此类命令，并返回错误代码。
4) On a given endpoint, there should normally be only one outstanding NotificationRequest command at any time. The RequestId parameter should be used to correlate Notify commands with the triggering notification request.
4) 在给定的端点上，任何时候通常只有一个未完成的NotificationRequest命令。RequestId参数应用于将Notify命令与触发通知请求相关联。
5) In some cases, an implicitly or explicitly wildcarded DeleteConnection command that applies to a group of endpoints can step in front of a pending CreateConnection command. The Call Agent should individually delete all connections whose completion was pending at the time of the global DeleteConnection command. Also, new CreateConnection commands for endpoints named by the wild-carding cannot be sent until the wild-carded DeleteConnection command is acknowledged.
5) 在某些情况下，应用于一组端点的隐式或显式通配符DeleteConnection命令可以在挂起的CreateConnection命令之前执行。调用代理应单独删除在执行全局DeleteConnection命令时等待完成的所有连接。此外，在确认通配符的DeleteConnection命令之前，无法发送由通配符命名的端点的新CreateConnection命令。
6) When commands are embedded within each other, sequencing requirements for all commands must be adhered to. For example a Create Connection command with a Notification Request in it must adhere to the sequencing for CreateConnection and NotificationRequest at the same time.
6) 当命令相互嵌入时，必须遵守所有命令的顺序要求。例如，包含通知请求的CreateConnection命令必须同时遵循CreateConnection和NotificationRequest的顺序。
7) AuditEndpoint and AuditConnection is not subject to any sequencing.
7) AuditEndpoint和AuditConnection不受任何排序的约束。
8) RestartInProgress must always be the first command sent by an endpoint as defined by the restart procedure. Any other command or response must be delivered after this RestartInProgress command (piggy-backing allowed).
8) RestartInProgress必须始终是由重新启动过程定义的端点发送的第一个命令。任何其他命令或响应必须在此RestartInProgress命令之后发送（允许使用piggy backing）。
9) When multiple messages are piggy-backed in a single packet, the messages are always processed in order.
9) 当多条消息在一个数据包中进行备份时，消息总是按顺序处理。
These rules do not affect the gateway, which should always respond to commands.
这些规则不影响网关，网关应始终响应命令。
Let's suppose that a large number of gateways are powered on simultaneously. If they were to all initiate a RestartInProgress transaction, the call agent would very likely be swamped, leading to message losses and network congestion during the critical period of service restoration. In order to prevent such avalanches, the following behavior is suggested:
让我们假设大量网关同时通电。如果他们都要启动RestartInProgress事务，则呼叫代理很可能会被淹没，从而在服务恢复的关键时期导致消息丢失和网络拥塞。为了防止此类雪崩，建议采取以下措施：
1) When a gateway is powered on, it should initiate a restart timer to a random value, uniformly distributed between 0 and a maximum waiting delay (MWD). Care should be taken to avoid synchronicity of the random number generation between multiple gateways that would use the same algorithm.
1) 当网关通电时，它应启动一个随机值的重启计时器，该值均匀分布在0和最大等待延迟（MWD）之间。应注意避免使用相同算法的多个网关之间随机数生成的同步性。
2) The gateway should then wait for either the end of this timer, the reception of a command from the call agent, or the detection of a local user activity, such as for example an off-hook transition on a residential gateway.
2) 然后，网关应等待该计时器结束、从呼叫代理接收命令或检测本地用户活动，例如住宅网关上的脱钩转换。
3) When the timer elapses, when a command is received, or when an activity is detected, the gateway should initiate the restart procedure.
3) 当计时器过期、收到命令或检测到活动时，网关应启动重启过程。
The restart procedure simply requires the endpoint to guarantee that the first message (command or response) that the Call Agent sees from this endpoint is a RestartInProgress message informing the Call Agent about the restart. The endpoint is free to take full advantage of piggy-backing to achieve this.
重启过程只需要端点保证调用代理从该端点看到的第一条消息（命令或响应）是一条RestartInProgress消息，通知调用代理重启。端点可以自由地充分利用piggy backing来实现这一点。
It is expected that each endpoint in a gateway will have a provisionable Call Agent, i.e., "notified entity", to direct the initial restart message towards. When the collection of endpoints in a gateway is managed by more than one Call Agent, the above procedure must be performed for each collection of endpoints managed by a given Call Agent. The gateway MUST take full advantage of wild-carding to minimize the number of RestartInProgress messages generated when multiple endpoints in a gateway restart and the endpoints are managed by the same Call Agent.
预计网关中的每个端点都将有一个可配置的呼叫代理，即“通知实体”，用于将初始重启消息指向。当网关中的端点集合由多个调用代理管理时，必须对给定调用代理管理的每个端点集合执行上述过程。当网关中的多个端点重新启动且端点由同一呼叫代理管理时，网关必须充分利用通配符来最小化重新启动进程消息的数量。
The value of MWD is a configuration parameter that depends on the type of the gateway. The following ]reasoning can be used to determine the value of this delay on residential gateways.
MWD的值是一个配置参数，取决于网关的类型。以下推理可用于确定住宅网关上该延迟的值。
Call agents are typically dimensioned to handle the peak hour traffic load, during which, in average, 10% of the lines will be busy, placing calls whose average duration is typically 3 minutes. The processing of a call typically involves 5 to 6 MGCP transactions between each end point and the call agent. This simple calculation shows that the call agent is expected to handle 5 to 6 transactions for each end point, every 30 minutes on average, or, to put it otherwise, about one transaction per end point every 5 to 6 minutes on average. This suggest that a reasonable value of MWD for a residential gateway would be 10 to 12 minutes. In the absence of explicit configuration, residential gateways should adopt a value of 600 seconds for MWD.
呼叫代理通常用于处理高峰时段的流量负载，在此期间，平均有10%的线路处于繁忙状态，呼叫的平均持续时间通常为3分钟。呼叫处理通常涉及每个端点和呼叫代理之间的5到6个MGCP事务。这个简单的计算表明，呼叫代理平均每30分钟为每个端点处理5到6个事务，或者，换句话说，平均每5到6分钟为每个端点处理一个事务。这表明住宅网关的MWD合理值为10至12分钟。在没有明确配置的情况下，住宅网关的MWD值应为600秒。
The same reasoning suggests that the value of MWD should be much shorter for trunking gateways or for business gateways, because they handle a large number of endpoints, and also because the usage rate of these endpoints is much higher than 10% during the peak busy hour, a typical value being 60%. These endpoints, during the peak hour, are this expected to contribute about one transaction per minute to the call agent load. A reasonable algorithm is to make the value of MWD per "trunk" endpoint six times shorter than the MWD per residential gateway, and also inversely proportional to the number of endpoints that are being restarted. for example MWD should be set to 2.5 seconds for a gateway that handles a T1 line, or to 60 milliseconds for a gateway that handles a T3 line.
同样的推理表明，对于中继网关或业务网关，MWD的值应该短得多，因为它们处理大量端点，而且这些端点的使用率在高峰繁忙时间远高于10%，典型值为60%。在高峰时段，这些端点预计每分钟为呼叫代理负载贡献一个事务。一个合理的算法是使每个“中继”端点的MWD值比每个住宅网关的MWD值短六倍，并且与正在重新启动的端点数量成反比。例如，对于处理T1线路的网关，MWD应设置为2.5秒；对于处理T3线路的网关，MWD应设置为60毫秒。
In addition to the restart procedure, gateways also have a "disconnected" procedure, which is initiated when an endpoint becomes "disconnected" as described in Section 3.4.2. It should here be noted, that endpoints can only become disconnected when they attempt to communicate with the Call Agent. The following steps are followed by an endpoint that becomes "disconnected":
除重启程序外，网关还具有“断开”程序，如第3.4.2节所述，当端点变为“断开”时启动该程序。这里应该注意的是，端点只有在尝试与呼叫代理通信时才能断开连接。以下步骤之后是一个变为“断开连接”的端点：
1. A "disconnected" timer is initialized to a random value, uniformly distributed between 0 and a provisionable "disconnected" initial waiting delay (Tdinit), e.g., 15 seconds. Care MUST be taken to avoid synchronicity of the random number generation between multiple gateways and endpoints that would use the same algorithm.
1. “断开”计时器初始化为随机值，均匀分布在0和可提供的“断开”初始等待延迟（Tdinit）之间，例如15秒。必须注意避免使用相同算法的多个网关和端点之间随机数生成的同步性。
2. The gateway then waits for either the end of this timer, the reception of a command from the call agent, or the detection of a local user activity for the endpoint, such as for example an off-hook transition.
2. 然后，网关等待该计时器结束、从呼叫代理接收命令或检测端点的本地用户活动，例如脱钩转换。
3. When the "disconnected" timer elapses, when a command is received, or when a local user activity is detected, the gateway initiates the "disconnected" procedure for the endpoint. In the case of local user activity, a provisionable "disconnected" minimum waiting delay (Tdmin) must furthermore have elapsed since the gateway became disconnected or the last time it initiated the "disconnected" procedure in order to limit the rate at which the procedure is performed.
3. 当“断开连接”计时器过期、收到命令或检测到本地用户活动时，网关将启动端点的“断开连接”过程。在本地用户活动的情况下，自网关断开连接或上次启动“断开连接”过程以来，还必须经过可设置的“断开连接”最小等待延迟（Tdmin），以限制过程的执行速率。
4. If the "disconnected" procedure still left the endpoint disconnected, the "disconnected" timer is then doubled, subject to a provisionable "disconnected" maximum waiting delay (Tdmax), e.g., 600 seconds, and the gateway proceeds with step 2 again.
4. 如果“断开连接”过程仍然使端点保持断开连接状态，则“断开连接”计时器将加倍，受到可提供的“断开连接”最大等待延迟（Tdmax）的影响，例如600秒，并且网关再次继续执行步骤2。
The "disconnected" procedure is similar to the restart procedure in that it now simply states that the endpoint MUST send a RestartInProgress command to the Call Agent informing it that the endpoint was disconnected and furthermore guarantee that the first message (command or response) that the Call Agent now sees from this endpoint MUST be this RestartInProgress command. The endpoint MUST take full advantage of piggy-backing in achieving this. The Call Agent may then for instance decide to audit the endpoint, or simply clear all connections for the endpoint.
“断开连接”过程类似于重新启动过程，因为它现在只是声明端点必须向呼叫代理发送RestartInProgress命令，通知其端点已断开连接，并进一步保证第一条消息（命令或响应）已发送调用代理现在从此端点看到的必须是此RestartInProgress命令。端点必须充分利用piggy backing来实现这一点。然后，调用代理可能决定审计端点，或者干脆清除端点的所有连接。
This specification purposely does not specify any additional behavior for a disconnected endpoint. Vendors MAY for instance choose to provide silence, play reorder tone, or even enable a downloaded wav file to be played.
本规范有意不为断开连接的端点指定任何其他行为。例如，供应商可以选择提供静音、播放重新订购音，甚至可以播放下载的wav文件。
The default value for Tdinit is 15 seconds, the default value for Tdmin, is 15 seconds, and the default value for Tdmax is 600 seconds.
Tdinit的默认值为15秒，Tdmin的默认值为15秒，Tdmax的默认值为600秒。
If unauthorized entities could use the MGCP, they would be able to set-up unauthorized calls, or to interfere with authorized calls. We expect that MGCP messages will always be carried over secure Internet connections, as defined in the IP security architecture as defined in RFC 2401, using either the IP Authentication Header, defined in RFC 2402, or the IP Encapsulating Security Payload, defined in RFC 2406. The complete MGCP protocol stack would thus include the following layers:
如果未经授权的实体可以使用MGCP，他们将能够建立未经授权的呼叫，或干扰授权呼叫。我们期望MGCP消息将始终通过安全的Internet连接进行传输，如RFC 2401中定义的IP安全体系结构所定义，使用RFC 2402中定义的IP身份验证报头或RFC 2406中定义的IP封装安全负载。因此，完整的MGCP协议栈将包括以下层：
________________________________
| MGCP |
|_______________________________|
| UDP |
|_______________________________|
| IP security |
| (authentication or encryption)|
|_______________________________|
| IP |
|_______________________________|
| transmission media |
|_______________________________|
________________________________
| MGCP |
|_______________________________|
| UDP |
|_______________________________|
| IP security |
| (authentication or encryption)|
|_______________________________|
| IP |
|_______________________________|
| transmission media |
|_______________________________|
Adequate protection of the connections will be achieved if the gateways and the Call Agents only accept messages for which IP security provided an authentication service. An encryption service will provide additional protection against eavesdropping, thus forbidding third parties from monitoring the connections set up by a given endpoint
如果网关和呼叫代理只接受IP安全为其提供身份验证服务的消息，则可以实现对连接的充分保护。加密服务将提供额外的防窃听保护，从而禁止第三方监视给定端点建立的连接
The encryption service will also be requested if the session descriptions are used to carry session keys, as defined in SDP.
如果会话描述用于携带SDP中定义的会话密钥，则还将请求加密服务。
These procedures do not necessarily protect against denial of service attacks by misbehaving gateways or misbehaving call agents. However, they will provide an identification of these misbehaving entities, which should then be deprived of their authorization through maintenance procedures.
这些过程不一定能够防止行为不当的网关或呼叫代理的拒绝服务攻击。但是，他们将提供这些行为不端实体的身份证明，然后通过维护程序剥夺这些实体的授权。
MGCP allows call agent to provide gateways with "session keys" that can be used to encrypt the audio messages, protecting against eavesdropping.
MGCP允许呼叫代理为网关提供“会话密钥”，用于加密音频消息，防止窃听。
A specific problem of packet networks is "uncontrolled barge-in." This attack can be performed by directing media packets to the IP address and UDP port used by a connection. If no protection is implemented, the packets will be decompressed and the signals will be played on the "line side".
数据包网络的一个特殊问题是“不受控制的闯入”。这种攻击可以通过将媒体数据包定向到连接使用的IP地址和UDP端口来执行。如果未实施保护，则数据包将被解压缩，信号将在“线路侧”播放。
A basic protection against this attack is to only accept packets from known sources, checking for example that the IP source address and UDP source port match the values announced in the "remote session description." But this has two inconveniences: it slows down connection establishment and it can be fooled by source spoofing:
针对此攻击的基本防护措施是仅接受来自已知来源的数据包，例如检查IP源地址和UDP源端口是否与“远程会话描述”中宣布的值匹配。但这有两个不便之处：它会减慢连接的建立速度，并且可能被源欺骗所愚弄：
* To enable the address-based protection, the call agent must obtain the remote session description of the e-gress gateway and pass it to the in-gress gateway. This requires at least one network round trip, and leaves us with a dilemma: either allow the call to proceed without waiting for the round trip to complete, and risk for example "clipping" a remote announcement, or wait for the full round trip and settle for slower call-set-up procedures.
* 要启用基于地址的保护，呼叫代理必须获取e-gress网关的远程会话描述，并将其传递给in-gress网关。这至少需要一次网络往返，让我们陷入两难境地：要么允许呼叫继续进行而不等待往返完成，并冒着“剪辑”远程公告等风险，要么等待完整的往返并满足于较慢的呼叫设置过程。
* Source spoofing is only effective if the attacker can obtain valid pairs of source destination addresses and ports, for example by listening to a fraction of the traffic. To fight source spoofing, one could try to control all access points to the network. But this is in practice very hard to achieve.
* 源欺骗只有在攻击者能够获得有效的源-目标地址和端口对时才有效，例如，通过监听一小部分流量。为了打击源欺骗，可以尝试控制网络的所有接入点。但这在实践中很难实现。
An alternative to checking the source address is to encrypt and authenticate the packets, using a secret key that is conveyed during the call set-up procedure. This will no slow down the call set-up, and provides strong protection against address spoofing.
检查源地址的另一种方法是使用在呼叫建立过程中传递的密钥对数据包进行加密和身份验证。这不会减慢呼叫设置速度，并提供强大的地址欺骗保护。
This section provides an initial definition of packages and event names. More packages can be defined in additional documents.
本节提供包和事件名称的初始定义。可以在其他文档中定义更多包。
The list of basic packages includes the following:
基本包列表包括以下内容：
_________________________________________
| Package | name |
|______________________________|_________|
| Generic Media Package | G |
| DTMF package | D |
| MF Package | M |
| Trunk Package | T |
| Line Package | L |
| Handset Package | H |
| RTP Package | R |
| Network Access Server Package| N |
| Announcement Server Package | A |
| Script Package | Script|
|______________________________|_________|
_________________________________________
| Package | name |
|______________________________|_________|
| Generic Media Package | G |
| DTMF package | D |
| MF Package | M |
| Trunk Package | T |
| Line Package | L |
| Handset Package | H |
| RTP Package | R |
| Network Access Server Package| N |
| Announcement Server Package | A |
| Script Package | Script|
|______________________________|_________|
In the tables of events for each package, there are five columns:
在每个包的事件表中，有五列：
Symbol: the unique symbol used for the event Definition: a short description of the event
符号：用于事件定义的唯一符号：事件的简短描述
R: an x appears in this column is the event can be Requested by the call agent.
R：此列中出现的x表示呼叫代理可以请求事件。
S: if nothing appears in this column for an event, then the event cannot be signaled on command by the call agent. Otherwise, the following symbols identify the type of event:
S：如果此列中未显示任何事件，则调用代理无法通过命令通知该事件。否则，以下符号表示事件类型：
OO On/Off signal. The signal is turned on until commanded by the call agent to turn it off, and vice versa.
OO开/关信号。信号会一直打开，直到呼叫代理命令将其关闭，反之亦然。
TO Timeout signal. The signal lasts for a given duration unless it is superseded by a new signal.
发送超时信号。除非被新信号取代，否则信号将持续给定的时间。
BR Brief signal. The event has a short, known duration.
BR短信号。该事件的持续时间很短。
Duration: specifies the duration of TO signals.
持续时间：指定到信号的持续时间。
Package Name: G
包装名称：G
The generic media package group the events and signals that can be observed on several types of endpoints, such as trunking gateways, access gateways or residential gateways.
通用媒体包将可在若干类型的端点（如中继网关、访问网关或住宅网关）上观察到的事件和信号分组。
_____________________________________________________________________
| Symbol | Definition | R | S Duration |
|__________|____________________________|_____|______________________|
| mt | Modem detected | x | |
| ft | Fax tone detected | x | |
| ld | Long duration connection | x | |
| pat(###) | Pattern ### detected | x | OO |
| rt | Ringback tone | | TO |
| rbk(###) | ring back on connection | | TO 180 seconds |
| cf | Confirm tone | | BR |
| cg | Network Congestion tone | | TO |
| it | Intercept tone | | OO |
| pt | Preemption tone | | OO |
| of | report failure | x | |
|__________|____________________________|_____|______________________|
_____________________________________________________________________
| Symbol | Definition | R | S Duration |
|__________|____________________________|_____|______________________|
| mt | Modem detected | x | |
| ft | Fax tone detected | x | |
| ld | Long duration connection | x | |
| pat(###) | Pattern ### detected | x | OO |
| rt | Ringback tone | | TO |
| rbk(###) | ring back on connection | | TO 180 seconds |
| cf | Confirm tone | | BR |
| cg | Network Congestion tone | | TO |
| it | Intercept tone | | OO |
| pt | Preemption tone | | OO |
| of | report failure | x | |
|__________|____________________________|_____|______________________|
The signals are defined as follows:
信号定义如下：
The pattern definition can be used for specific algorithms such as answering machine detection, tone detection, and the like.
模式定义可用于特定算法，例如应答机检测、音调检测等。
Ring back tone (rt) an Audible Ring Tone, 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. The cadence for Audible Ring Tone is 2 seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR: SIGNALING, Section 17.2.5.
回铃音（rt）一种可听见的铃声，由两个交流音组成，频率分别为440和480赫兹，电平分别为-19 dBm，组合电平为-16 dBm。可听铃声的节拍为接通2秒，然后断开4秒。参见GR-506-CORE-LSSGR：信号，第17.2.5节。
Ring back on connection A ring back tone, applied to the connection whose identifier is passed as a parameter.
连接时回铃一种回铃音，应用于标识符作为参数传递的连接。
The "long duration connection" is detected when a connection has been established for more than 1 hour.
当建立连接超过1小时时，会检测到“长时间连接”。
Package name: D
包裹名称：D
_______________________________________________________________
| Symbol | Definition | R | S Duration |
|________|___________________________|_____|___________________|
| 0 | DTMF 0 | x | BR |
| 1 | DTMF 1 | x | BR |
| 2 | DTMF 2 | x | BR |
| 3 | DTMF 3 | x | BR |
| 4 | DTMF 4 | x | BR |
| 5 | DTMF 5 | x | BR |
| 6 | DTMF 6 | x | BR |
| 7 | DTMF 7 | x | BR |
| 8 | DTMF 8 | x | BR |
| 9 | DTMF 9 | x | BR |
| # | DTMF # | x | BR |
| * | DTMF * | x | BR |
| A | DTMF A | x | BR |
| B | DTMF B | x | BR |
| C | DTMF C | x | BR |
| D | DTMF D | x | BR |
| L | long duration indicator | x | 2 seconds|
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| of | report failure | x | |
|________|___________________________|_____|___________________|
_______________________________________________________________
| Symbol | Definition | R | S Duration |
|________|___________________________|_____|___________________|
| 0 | DTMF 0 | x | BR |
| 1 | DTMF 1 | x | BR |
| 2 | DTMF 2 | x | BR |
| 3 | DTMF 3 | x | BR |
| 4 | DTMF 4 | x | BR |
| 5 | DTMF 5 | x | BR |
| 6 | DTMF 6 | x | BR |
| 7 | DTMF 7 | x | BR |
| 8 | DTMF 8 | x | BR |
| 9 | DTMF 9 | x | BR |
| # | DTMF # | x | BR |
| * | DTMF * | x | BR |
| A | DTMF A | x | BR |
| B | DTMF B | x | BR |
| C | DTMF C | x | BR |
| D | DTMF D | x | BR |
| L | long duration indicator | x | 2 seconds|
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| of | report failure | x | |
|________|___________________________|_____|___________________|
The "interdigit timer" T is a digit input timer that can be used in two ways:
“交指定时器”T是一种数字输入定时器，可通过两种方式使用：
* When timer T is used with a digit map, the timer is not started until the first digit is entered, and the timer is restarted after each new digit is entered until either a digit map match or mismatch occurs. In this case, timer T functions as an inter-digit timer.
* 当定时器T与数字映射一起使用时，在输入第一个数字之前，定时器不会启动，并且在输入每个新数字之后，定时器会重新启动，直到出现数字映射匹配或不匹配。在这种情况下，定时器T起到数字间定时器的作用。
* When timer T is used without a digit map, the timer is started immediately and simply cancelled (but not restarted) as soon as a digit is entered. In this case, timer T can be used as an interdigit timer when overlap sending is used.
* 当在没有数字映射的情况下使用定时器T时，定时器立即启动，并在输入数字后立即取消（但不重新启动）。在这种情况下，当使用重叠发送时，定时器T可用作叉指定时器。
When used with a digit map, timer T takes on one of two values, T(partial) or T(critical). When at least one more digit is required for the digit string to match any of the patterns in the digit map, timer T takes on the value T(partial), corresponding to
当与数字映射一起使用时，计时器T采用两个值之一，T（部分）或T（临界）。当数字字符串需要至少一个以上的数字来匹配数字映射中的任何模式时，计时器T采用值T（部分），对应于
partial dial timing. If a timer is all that is required to produce a match, timer T takes on the value T(critical) corresponding to critical timing. When timer T is used without a digit map, timer T takes on the value T(critical). The default value for T(partial) is 16 seconds and the default value for T(critical) is 4 seconds. The provisioning process may alter both of these.
部分拨号定时。如果定时器是产生匹配所需的全部，则定时器T取对应于临界定时的值T（临界）。当在没有数字映射的情况下使用计时器T时，计时器T的值为T（临界值）。T（部分）的默认值为16秒，T（临界）的默认值为4秒。供应过程可能会改变这两个方面。
The "long duration indicator" is observed when a DTMF signal is produced for a duration larger than two seconds. In this case, the gateway will detect two successive events: first, when the signal has been recognized, the DTMF signal, and then, 2 seconds later, the long duration signal.
当DTMF信号持续时间大于两秒时，会观察到“长持续时间指示器”。在这种情况下，网关将检测两个连续事件：首先，当信号被识别时，DTMF信号，然后，2秒后，长持续时间信号。
Package Name: M
包裹名称：M
________________________________________________________
| Symbol | Definition | R | S Duration |
|________|____________________|_____|___________________|
| 0 | MF 0 | x | BR |
| 1 | MF 1 | x | BR |
| 2 | MF 2 | x | BR |
| 3 | MF 3 | x | BR |
| 4 | MF 4 | x | BR |
| 5 | MF 5 | x | BR |
| 6 | MF 6 | x | BR |
| 7 | MF 7 | x | BR |
| 8 | MF 8 | x | BR |
| 9 | MF 9 | x | BR |
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| K0 | MF K0 or KP | x | BR |
| K1 | MF K1 | x | BR |
| K2 | MF K2 | x | BR |
| S0 | MF S0 or ST | x | BR |
| S1 | MF S1 | x | BR |
| S2 | MF S2 | x | BR |
| S3 | MF S3 | x | BR |
| wk | Wink | x | BR |
| wko | Wink off | x | BR |
| is | Incoming seizure | x | OO |
| rs | Return seizure | x | OO |
| us | Unseize circuit | x | OO |
| of | report failure | x | |
|________|____________________|_____|___________________|
________________________________________________________
| Symbol | Definition | R | S Duration |
|________|____________________|_____|___________________|
| 0 | MF 0 | x | BR |
| 1 | MF 1 | x | BR |
| 2 | MF 2 | x | BR |
| 3 | MF 3 | x | BR |
| 4 | MF 4 | x | BR |
| 5 | MF 5 | x | BR |
| 6 | MF 6 | x | BR |
| 7 | MF 7 | x | BR |
| 8 | MF 8 | x | BR |
| 9 | MF 9 | x | BR |
| X | Wildcard, match | x | |
| | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds|
| K0 | MF K0 or KP | x | BR |
| K1 | MF K1 | x | BR |
| K2 | MF K2 | x | BR |
| S0 | MF S0 or ST | x | BR |
| S1 | MF S1 | x | BR |
| S2 | MF S2 | x | BR |
| S3 | MF S3 | x | BR |
| wk | Wink | x | BR |
| wko | Wink off | x | BR |
| is | Incoming seizure | x | OO |
| rs | Return seizure | x | OO |
| us | Unseize circuit | x | OO |
| of | report failure | x | |
|________|____________________|_____|___________________|
The definition of the MF package events is as follows:
MF包事件的定义如下：
Wink A transition from unseized to seized to unseized trunk states within a specified period. Typical seizure period is 100-350 msec.)
在指定的时间段内，使未指定的中继状态转换为未指定的中继状态。典型的发作期为100-350毫秒。）
Incoming seizure Incoming indication of call attempt.
传入占用呼叫尝试的传入指示。
Return seizure: Seizure in response to outgoing seizure.
退货扣押：针对即将离境的扣押而扣押。
Unseize circuit: Unseizure of a circuit at the end of a call.
取消电路大小：在呼叫结束时取消电路大小。
Wink off: A signal used in operator services trunks. A transition from seized to unseized to seized trunk states within a specified period of 100-350 ms. (To be checked)
闪烁关闭：在操作员服务中继中使用的信号。在100-350毫秒的规定时间内，从被占用到未被占用到被占用的中继状态的转换。（待检查）
Package Name: T
包装名称：T
_____________________________________________________________________
| Symbol | Definition | R | S Duration |
|________|________________________________|_____|____________________|
| co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| lb | Loopback | | OO |
| om | Old Milliwatt Tone (1000 Hz) | x | OO |
| nm | New Milliwatt Tone (1004 Hz) | x | OO |
| tl | Test Line | x | OO |
| zz | No circuit | x | OO |
| as | Answer Supervision | x | OO |
| ro | Reorder Tone | x | TO 30 seconds|
| of | report failure | x | |
| bl | Blocking | | OO |
|________|________________________________|_____|____________________|
_____________________________________________________________________
| Symbol | Definition | R | S Duration |
|________|________________________________|_____|____________________|
| co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| lb | Loopback | | OO |
| om | Old Milliwatt Tone (1000 Hz) | x | OO |
| nm | New Milliwatt Tone (1004 Hz) | x | OO |
| tl | Test Line | x | OO |
| zz | No circuit | x | OO |
| as | Answer Supervision | x | OO |
| ro | Reorder Tone | x | TO 30 seconds|
| of | report failure | x | |
| bl | Blocking | | OO |
|________|________________________________|_____|____________________|
The definition of the trunk package signal events is as follows:
中继包信号事件的定义如下：
Continuity Tone (co1): A tone at 2010 + or - 30 Hz.
连续性音调（co1）：2010+或-30 Hz时的音调。
Continuity Test (co2): A tone at the 1780 + or - 30 Hz.
连续性测试（co2）：1780+或-30 Hz的音调。
Milliwatt Tones: Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz)
毫瓦音调：旧毫瓦音调（1000 Hz），新毫瓦音调（1004 Hz）
Line Test: 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 + or -- 0.5dB).
线路测试：105测试线路测试进度音（2225Hz+或-25Hz，在-10dBm0+或-0.5dB时）。
No circuit: (that annoying tri-tone, low to high)
无电路：（讨厌的三音，从低到高）
Answer Supervision:
答复:
Reorder Tone: 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 Station Busy Tone is 0.25 seconds on followed by 0.25 seconds off, repeating continuously. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.
重排序音调：重排序音调是两个交流音调的组合，频率分别为480和620赫兹，电平分别为-24 dBm，组合电平为-21 dBm。电台忙音的节拍为0.25秒打开，然后是0.25秒关闭，持续重复。参见GR-506-CORE-LSSGR：信号，第17.2.7节。
Blocking: The call agent can place the circuit in a blocked state by applying the "bl(+)" signal to the endpoint. It can unblock it by applying the "bl(-)" signal.
阻塞：呼叫代理可以通过向端点应用“bl（+）”信号将电路置于阻塞状态。它可以通过应用“bl（-）”信号来解除阻塞。
The continuity tones are used when the call agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone. The Call agent is expected to know, through provisioning information, which test should be applied to a given endpoint. For example, the call agent that wants to initiate a single frequency test will send to the gateway a command of the form:
当呼叫代理想要启动连续性测试时，将使用连续性提示音。有两种类型的测试，单音和双音。通过设置信息，呼叫代理应该知道应该对给定端点应用哪个测试。例如，想要启动单频测试的呼叫代理将向网关发送以下形式的命令：
RQNT 1234 epx-t1/17@tgw2.example.net X: AB123FE0 S: co1 R: co1
RQNT 1234 epx-t1/17@tgw2.example.netX:AB123FE0 S:co1 R:co1
If it wanted instead to initiate a dual-tone test, it would send the command:
如果它想启动双音测试，它将发送以下命令：
RQNT 1234 epx-t1/17@tgw2.example.net X: AB123FE0 S: co2 R: co1
RQNT 1234 epx-t1/17@tgw2.example.netX:AB123FE0 S:co2 R:co1
The gateway would send the requested signal, and in both cases would look for the return of the 2010 Hz tone (co1). When it detects that tone, it will send the corresponding notification.
网关将发送请求的信号，并且在这两种情况下都将寻找2010 Hz音调（co1）的返回。当它检测到该音调时，它将发送相应的通知。
The tones are of type OO: the gateway will keep sending them until it receives a new notification request.
这些音调属于OO类型：网关将一直发送它们，直到收到新的通知请求。
Package Name: L
包装名称：L
________________________________________________________________________
|Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|___________________|
|adsi(string) | adsi display | | BR |
|vmwi | visual message | | OO |
| | waiting indicator | | |
|hd | Off hook transition | x | |
|hu | On hook transition | x | |
|hf | Flash hook | x | |
|aw | Answer tone | x | OO |
|bz | Busy tone | | TO 30 seconds |
|ci(ti,nu,na) | Caller-id | | BR |
|wt | Call Waiting tone | | TO 30 seconds |
|wt1, wt2, | Alternative call | | |
|wt3, wt4 | waiting tones | | |
|dl | Dial tone | | TO 16 seconds |
|mwi | Message waiting ind. | | TO 16 seconds |
|nbz | Network busy | x | OO |
| | (fast cycle busy) | | |
|ro | Reorder tone | | TO 30 seconds |
|rg | Ringing | | TO 180 seconds|
|r0, r1, r2, | Distinctive ringing | | TO 180 seconds|
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|rs | Ringsplash | | BR |
|p | Prompt tone | x | BR |
|e | Error tone | x | BR |
|sl | Stutter dialtone | | TO 16 seconds |
|v | Alerting Tone | | OO |
|y | Recorder Warning Tone | | OO |
|sit | SIT tone | | |
|z | Calling Card Service Tone | | OO |
|oc | Report on completion | x | |
|ot | Off hook warning tone | | TO indefinite |
|s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | |
|_____________|______________________________|_____|___________________|
________________________________________________________________________
|Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|___________________|
|adsi(string) | adsi display | | BR |
|vmwi | visual message | | OO |
| | waiting indicator | | |
|hd | Off hook transition | x | |
|hu | On hook transition | x | |
|hf | Flash hook | x | |
|aw | Answer tone | x | OO |
|bz | Busy tone | | TO 30 seconds |
|ci(ti,nu,na) | Caller-id | | BR |
|wt | Call Waiting tone | | TO 30 seconds |
|wt1, wt2, | Alternative call | | |
|wt3, wt4 | waiting tones | | |
|dl | Dial tone | | TO 16 seconds |
|mwi | Message waiting ind. | | TO 16 seconds |
|nbz | Network busy | x | OO |
| | (fast cycle busy) | | |
|ro | Reorder tone | | TO 30 seconds |
|rg | Ringing | | TO 180 seconds|
|r0, r1, r2, | Distinctive ringing | | TO 180 seconds|
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|rs | Ringsplash | | BR |
|p | Prompt tone | x | BR |
|e | Error tone | x | BR |
|sl | Stutter dialtone | | TO 16 seconds |
|v | Alerting Tone | | OO |
|y | Recorder Warning Tone | | OO |
|sit | SIT tone | | |
|z | Calling Card Service Tone | | OO |
|oc | Report on completion | x | |
|ot | Off hook warning tone | | TO indefinite |
|s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | |
|_____________|______________________________|_____|___________________|
The definition of the tones is as follows:
音调的定义如下：
Dial tone: A combined 350 + 440 Hz tone.
拨号音：350+440 Hz的组合音。
Visual Message Waiting Indicator The transmission of the VMWI messages will conform to the requirements in Section 2.3.2, "On-hook Data Transmission Not Associated with Ringing" in TR-H-000030 and the CPE guidelines in SR-TSV-002476. VMWI messages will only be sent from the SPCS when the line is idle. If new messages arrive while the line is busy, the VMWI indicator message will be delayed until the line goes back to the idle state. The CA should periodically refresh the CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission Interface.
可视消息等待指示器VMWI消息的传输应符合TR-H-000030第2.3.2节“与振铃无关的挂机数据传输”和SR-TSV-002476中CPE指南的要求。VMWI消息仅在线路空闲时从SPC发送。如果新消息在线路繁忙时到达，VMWI指示灯消息将延迟，直到线路返回空闲状态。CA应定期刷新CPE的视觉指示器。见TR-NWT-001401-可视信息等待指示器一般要求；以及GR-30-CORE语音带数据传输接口。
Message waiting Indicator See GR-506-CORE, 17.2.3.
消息等待指示器见GR-506-CORE，17.2.3。
Alerting Tone: a 440 Hz Tone of 2 second duration followed by 1/2 second of tone every 10 seconds.
警报音：持续时间为2秒的440 Hz音，然后每10秒发出1/2秒的音。
Ring splash Ringsplash, also known as "Reminder ring" is a burst of ringing that may be applied to the physical forwarding line (when idle) to indicate that a call has been forwarded and to remind the user that a CF subfeature is active. In the US, it is defined to be a 0.5(-0,+0.1) second burst of power ringing. See TR-TSY-000586 - Call Forwarding Subfeatures.
Ring splash Ring splash，也称为“提醒铃声”，是一种突发铃声，可应用于物理转发线路（空闲时），以指示呼叫已转发，并提醒用户CF子功能处于活动状态。在美国，它被定义为0.5（-0，+0.1）秒的电源铃声突发。请参阅TR-TSY-000586-呼叫转接子功能。
Call waiting tone Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting feature is defined in TR-TSY-000571. By defining "wt" as a TO signal you are really defining the feature which seems wrong to me (given the spirit of MGCP), hence the definition of "wt" as a BR signal in ECS, per GR-506-CORE. Also, it turns out that there is actually four different call waiting tone patterns (see GR-506- CORE, 14.2) so we have wt1, wt2, wt3, wt4.
呼叫等待音呼叫等待音在GR-506-CORE 14.2中定义。TR-TSY-000571中定义了呼叫等待功能。通过将“wt”定义为TO信号，您实际上是在定义我认为错误的功能（鉴于MGCP的精神），因此根据GR-506-CORE，将“wt”定义为ECS中的BR信号。此外，事实证明，实际上有四种不同的呼叫等待音调模式（参见GR-506-CORE，14.2），因此我们有wt1、wt2、wt3、wt4。
Caller Id (ci(time, number, name)): The caller-id event carries three parameters, the time of the call, the calling number and the calling name. Each of the three fields are optional, however each of the commas will always be included. See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031.
呼叫者Id（ci（时间、号码、名称））：呼叫者Id事件包含三个参数，即呼叫时间、呼叫号码和呼叫名称。这三个字段中的每一个都是可选的，但始终会包含每个逗号。见TR-NWT-001188、GR-30-CORE和TR-NWT-000031。
Recorder Warning Tone: 1400 Hz of Tone of 0.5 second duration every 15 seconds.
记录器警告音：每15秒持续时间为0.5秒的1400 Hz音调。
SIT tone: used for indicating a line is out of service.
SIT音调：用于指示线路停止运行。
Calling Card Service Tone: 60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone), decaying exponentially with a time constant of 200 ms.
电话卡服务音：941+1477赫兹的60毫秒和350+440赫兹的940毫秒（拨号音），以指数衰减，时间常数为200毫秒。
Distinctive tone pattern: where ### is any number between 000 and 999, inclusive. Can be used for distinctive ringing, customized dial tone, etc.
独特的音调模式：其中####是介于000和999之间的任意数字。可用于独特的铃声、定制拨号音等。
Report on completion The report on completion event is detected when the gateway was asked to perform one or several signals of type TO on the endpoint, and when these signals were completed without being stopped by the detection of a requested event such as off-hook transition or dialed digit. The completion report may carry as parameter the name of the signal that came to the end of its live time, as in:
完成报告当要求网关在端点上执行一个或多个to类型的信号时，以及当这些信号在未被请求的事件（如脱钩转换或拨号数字）检测到的情况下完成时，检测到完成报告事件。完工报告可将到达现场时间结束的信号名称作为参数，如：
O: L/oc(L/dl)
O: L/oc(L/dl)
Ring back on connection A ring back tone, applied to the connection wghose identifier is passed as a parameter.
在连接时回铃应用于连接的回铃音，该标识符作为参数传递。
We should note that many of these definitions vary from country to country. The frequencies listed above are the one in use in North America. There is a need to accommodate different tone sets in different countries, and there is still an ongoing debate on the best way to meet that requirement:
我们应该注意到，其中许多定义因国家而异。上面列出的频率是在北美使用的频率。需要适应不同国家的不同语调，目前仍在就满足这一要求的最佳方式进行辩论：
* One solution is to define different event packages specifying for example the German dialtone as "L-DE/DL".
* 一种解决方案是定义不同的事件包，例如将德语拨号音指定为“L-DE/DL”。
* Another solution is to use a management interface to specify on an endpoint basis which frequency shall be associated to what tone.
* 另一种解决方案是使用管理接口在端点基础上指定哪个频率应与什么音调相关联。
Package Name: H
包装名称：H
________________________________________________________________________
|Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|___________________|
|adsi(string) | adsi display | x | BR |
|tdd | | | |
|vmwi | | | |
|hd | Off hook transition | x | OO |
|hu | On hook transition | x | OO |
|hf | Flash hook | x | BR |
|aw | Answer tone | x | OO |
|bz | Busy tone | x | OO |
|wt | Call Waiting tone | x | TO 30 seconds |
|dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds|
|nbz | Network busy | x | OO |
| | (fast cycle busy) | | |
|rg | Ringing | x | TO 30 seconds |
|r0, r1, r2, | Distinctive ringing | x | TO 30 seconds |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|p | Prompt tone | x | BR |
|e | Error tone | x | BR |
|sdl | Stutter dialtone | x | TO 16 seconds |
|v | Alerting Tone | x | OO |
|y | Recorder Warning Tone | x | OO |
|t | SIT tone | x | |
|z | Calling Card Service Tone | x | OO |
|oc | Report on completion | x | |
|ot | Off hook warning tone | x | OO |
|s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | |
|_____________|______________________________|_____|___________________|
________________________________________________________________________
|Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|___________________|
|adsi(string) | adsi display | x | BR |
|tdd | | | |
|vmwi | | | |
|hd | Off hook transition | x | OO |
|hu | On hook transition | x | OO |
|hf | Flash hook | x | BR |
|aw | Answer tone | x | OO |
|bz | Busy tone | x | OO |
|wt | Call Waiting tone | x | TO 30 seconds |
|dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds|
|nbz | Network busy | x | OO |
| | (fast cycle busy) | | |
|rg | Ringing | x | TO 30 seconds |
|r0, r1, r2, | Distinctive ringing | x | TO 30 seconds |
|r3, r4, r5, | | | |
|r6 or r7 | | | |
|p | Prompt tone | x | BR |
|e | Error tone | x | BR |
|sdl | Stutter dialtone | x | TO 16 seconds |
|v | Alerting Tone | x | OO |
|y | Recorder Warning Tone | x | OO |
|t | SIT tone | x | |
|z | Calling Card Service Tone | x | OO |
|oc | Report on completion | x | |
|ot | Off hook warning tone | x | OO |
|s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | |
|_____________|______________________________|_____|___________________|
The handset emulation package is an extension of the line package, to be used when the gateway is capable of emulating a handset. The difference with the line package is that events such as "off hook" can be signalled as well as detected.
手持设备仿真软件包是line软件包的扩展，在网关能够仿真手持设备时使用。与line包的不同之处在于，诸如“脱钩”之类的事件既可以用信号发送，也可以检测。
Package Name: R
软件包名称：R
____________________________________________________________________
| Symbol | Definition | R | S Duration|
|_________|________________________________|_____|__________________|
| UC | Used codec changed | x | |
| SR(###) | Sampling rate changed | x | |
| JI(###) | Jitter buffer size changed | x | |
| PL(###) | Packet loss exceeded | x | |
| qa | Quality alert | x | |
| co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| of | report failure | x | |
|_________|________________________________|_____|__________________|
____________________________________________________________________
| Symbol | Definition | R | S Duration|
|_________|________________________________|_____|__________________|
| UC | Used codec changed | x | |
| SR(###) | Sampling rate changed | x | |
| JI(###) | Jitter buffer size changed | x | |
| PL(###) | Packet loss exceeded | x | |
| qa | Quality alert | x | |
| co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | |
| of | report failure | x | |
|_________|________________________________|_____|__________________|
Codec Changed: Codec changed to hexadecimal codec number enclosed in parenthesis, as in UC(15), to indicate the codec was changed to PCM mu-law. Codec Numbers are specified in RFC 1890, or in a new definition of the audio profiles for RTP that replaces this RFC. Some implementations of media gateways may not allow the codec to be changed upon command from the call agent. codec changed to codec hexadecimal ##.
编解码器更改：编解码器更改为括号内的十六进制编解码器编号，如UC（15）中所示，以表明编解码器已更改为PCM mu法则。编解码器编号在RFC1890中指定，或在替代此RFC的RTP音频配置文件的新定义中指定。媒体网关的某些实现可能不允许根据呼叫代理的命令更改编解码器。编解码器更改为编解码器十六进制。
Sampling Rate Changed: Sampling rate changed to decimal number in milliseconds enclosed in parenthesis, as in SR(20), to indicate the sampling rate was changed to 20 milliseconds. Some implementations of media gateways may not allow the sampling rate to be changed upon command from a call agent.
采样率更改：采样率更改为括号中以毫秒为单位的十进制数，如SR（20）中所示，以指示采样率更改为20毫秒。媒体网关的某些实现可能不允许根据呼叫代理的命令更改采样率。
Jitter Buffer Size Changed: When the media gateway has the ability to automatically adjust the depth of the jitter buffer for received RTP streams, it is useful for the media gateway controller to receive notification that the media gateway has automatically increased its jitter buffer size to accomodate increased or decreased variability in network latency. The syntax for requesting notification is "JI", which tells the media gateway that the controller wants notification of any jitter buffer size changes. The syntax for notification from the media gateway to the controller is "JI(####)", where the #### is the new size of the jitter buffer, in milliseconds.
抖动缓冲区大小已更改：当媒体网关能够自动调整接收RTP流的抖动缓冲区深度时，媒体网关控制器接收媒体网关已自动增加其抖动缓冲区大小以适应网络延迟的增加或减少的变化的通知是有用的。请求通知的语法是“JI”，它告诉媒体网关控制器需要任何抖动缓冲区大小更改的通知。从媒体网关向控制器发送通知的语法为“JI（#######）”，其中####是抖动缓冲区的新大小，以毫秒为单位。
Packet Loss Exceeded: Packet loss rate exceed the threshold of the specified decimal number of packets per 100,000 packets, where the packet loss number is contained in parenthesis. For example, PL(10) indicates packets are being dropped at a rate of 1 in 10,000 packets.
超过数据包丢失：数据包丢失率超过每100000个数据包的指定十进制数据包数的阈值，其中数据包丢失数包含在括号中。例如，PL（10）指示正在以1/10000数据包的速率丢弃数据包。
Quality alert The packet loss rate or the combination of delay and jitter exceed a specified quality threshold.
质量警报数据包丢失率或延迟和抖动组合超过指定的质量阈值。
The continuity tones are the same as those defined in the Trunk package. They can be use in conjunction with the Network LoopBack or Network Continuity Test modes to test the continuity of an RTP circuit.
连续性音调与中继包中定义的音调相同。它们可与网络环回或网络连续性测试模式结合使用，以测试RTP电路的连续性。
The "operation failure" code can be used to report problems such as the loss of underlying connectivity. The observed event can include as parameter the reason code of the failure.
“操作失败”代码可用于报告基础连接丢失等问题。观察到的事件可以包括故障原因代码作为参数。
Package Name: N
软件包名称：N
____________________________________________________________
| Symbol | Definition | R | S Duration|
|________|__________________________|_____|_________________|
| pa | Packet arrival | x | |
| cbk | Call back request | x | |
| cl | Carrier lost | x | |
| au | Authorization succeeded| x | |
| ax | Authorization denied | x | |
| of | Report failure | x | |
|________|__________________________|_____|_________________|
____________________________________________________________
| Symbol | Definition | R | S Duration|
|________|__________________________|_____|_________________|
| pa | Packet arrival | x | |
| cbk | Call back request | x | |
| cl | Carrier lost | x | |
| au | Authorization succeeded| x | |
| ax | Authorization denied | x | |
| of | Report failure | x | |
|________|__________________________|_____|_________________|
The packet arrival event is used to notify that at least one packet was recently sent to an Internet address that is observed by an endpoint. The event report includes the Internet address, in standard ASCII encoding, between parenthesis:
数据包到达事件用于通知至少一个数据包最近被发送到端点观察到的互联网地址。事件报告在括号之间包含标准ASCII编码的Internet地址：
O: pa(192.96.41.1)
O:pa（192.96.41.1）
The call back event is used to notify that a call back has been requested during the initial phase of a data connection. The event report includes the identification of the user that should be called back, between parenthesis:
回调事件用于通知在数据连接的初始阶段已请求回调。事件报告在括号之间包括应回调的用户标识：
O: cbk(user25)
O:cbk（用户25）
Package Name: A
包裹名称：A
___________________________________________________________________
| Symbol | Definition | R | S Duration|
|________________|________________________|_____|__________________|
| ann(url,parms) | Play an announcement | | TO variable|
| oc | Report on completion | x | |
| of | Report failure | x | |
|________________|________________________|_____|__________________|
___________________________________________________________________
| Symbol | Definition | R | S Duration|
|________________|________________________|_____|__________________|
| ann(url,parms) | Play an announcement | | TO variable|
| oc | Report on completion | x | |
| of | Report failure | x | |
|________________|________________________|_____|__________________|
The announcement action is qualified by an URL name and by a set of initial parameters as in for example:
公告操作由URL名称和一组初始参数限定，例如：
S: ann(http://scripts.example.net/all-lines-busy.au)
S: ann(http://scripts.example.net/all-lines-busy.au)
The "operation complete" event will be detected when the announcement is played out. If the announcement cannot be played out, an operation failure event can be returned. The failure may be explained by a commentary, as in:
播放公告时将检测到“操作完成”事件。如果无法播放公告，则可以返回操作失败事件。该故障可通过评注进行解释，如：
O: A/of(file not found)
O: A/of(file not found)
Package Name: Script
包名称：Script
______________________________________________________________
| Symbol | Definition | R | S | Duration|
|___________|________________________|_____|______|___________|
| java(url) | Load a java script | | TO | variable|
| perl(url) | Load a perl script | | TO | variable|
| tcl(url) | Load a TCL script | | TO | variable|
| xml(url) | Load an XML script | | TO | variable|
| oc | Report on completion | x | | |
| of | Report failure | x | | |
|___________|________________________|_____|______|___________|
______________________________________________________________
| Symbol | Definition | R | S | Duration|
|___________|________________________|_____|______|___________|
| java(url) | Load a java script | | TO | variable|
| perl(url) | Load a perl script | | TO | variable|
| tcl(url) | Load a TCL script | | TO | variable|
| xml(url) | Load an XML script | | TO | variable|
| oc | Report on completion | x | | |
| of | Report failure | x | | |
|___________|________________________|_____|______|___________|
The "language" action define is qualified by an URL name and by a set of initial parameters as in for example:
“语言”操作定义由URL名称和一组初始参数限定，例如：
S: script/java(http://scripts.example.net/credit-
card.java,long,1234)
S: script/java(http://scripts.example.net/credit-
card.java,long,1234)
The current definition defines keywords for the most common languages. More languages may be defined in further version of this documents. For each language, an API specification will describe how the scripts can issue local "notificationRequest" commands, and receive the corresponding notifications.
当前定义定义了最常用语言的关键字。更多语言可在本文件的进一步版本中定义。对于每种语言，API规范将描述脚本如何发出本地“notificationRequest”命令，并接收相应的通知。
The script produces an output which consists of one or several text string, separated by commas. The text string are reported as a commentary in the report on completion, as in for example:
该脚本生成由一个或多个文本字符串组成的输出，用逗号分隔。文本字符串在完成报告中作为注释报告，例如：
O: script/oc(21223456794567,9738234567)
O: script/oc(21223456794567,9738234567)
The failure report may also return a string, as in:
故障报告还可能返回字符串，如中所示：
O: script/oc(21223456794567,9738234567)
O: script/oc(21223456794567,9738234567)
The definition of the script environment and the specific actions in that environment are for further study.
脚本环境的定义以及该环境中的具体操作有待进一步研究。
We define the following basic endpoint types and profiles:
我们定义了以下基本端点类型和配置文件：
* Trunk gateway (ISUP)
* 中继网关（ISUP）
* Trunk gateway (MF)
* 中继网关（MF）
* Network Access Server (NAS)
* 网络访问服务器（NAS）
* Combined NAS/VOIP gateway
* NAS/VOIP组合网关
* Access Gateway
* 接入网关
* Residential Gateway
* 住宅网关
* Announcement servers
* 公告服务器
These gateways are supposed to implement the following packages
这些网关应该实现以下包
___________________________________________________________
| Gateway | Supported packages |
|____________________________|_____________________________|
| Trunk gateway (ISUP) | GM, DTMF, TK, RTP |
| Trunk gateway (MF) | GM, MF, DTMF, TK, RTP |
| Network Access Server (NAS)| GM, MF, TK, NAS |
| Combined NAS/VOIP gateway | GM, MF, DTMF, TK, NAS, RTP|
| Access Gateway (VOIP) | GM, DTMF, MF, RTP |
| Access Gateway (VOIP+NAS) | GM, DTMF, MF, NAS, RTP |
| Residential Gateway | GM, DTMF, Line, RTP |
| Announcement Server | ANN, RTP |
|____________________________|_____________________________|
___________________________________________________________
| Gateway | Supported packages |
|____________________________|_____________________________|
| Trunk gateway (ISUP) | GM, DTMF, TK, RTP |
| Trunk gateway (MF) | GM, MF, DTMF, TK, RTP |
| Network Access Server (NAS)| GM, MF, TK, NAS |
| Combined NAS/VOIP gateway | GM, MF, DTMF, TK, NAS, RTP|
| Access Gateway (VOIP) | GM, DTMF, MF, RTP |
| Access Gateway (VOIP+NAS) | GM, DTMF, MF, NAS, RTP |
| Residential Gateway | GM, DTMF, Line, RTP |
| Announcement Server | ANN, RTP |
|____________________________|_____________________________|
Advanced announcement servers may also support the Script package.
高级公告服务器也可能支持脚本包。
Advanced trunking servers may support the ANN package, the Script package, and in some cases the Line and Handset package as well.
高级中继服务器可能支持ANN包、脚本包，在某些情况下还支持Line和Handset包。
Draft 0-5 was issued in February 1999, as the last update of draft version 0.1. Version 1.0 benefits from implementation experience, and also aligns as much as possible with the CableLabs' NCS project. The main differences between the February draft and version 1.0 are:
草案0-5于1999年2月发布，作为草案版本0.1的最后更新。版本1.0得益于实施经验，并尽可能与CableLabs的NCS项目保持一致。2月份的草案与1.0版之间的主要区别是：
* Specified more clearly that the encoding of three LocalConnectionOptions parameters, Encoding Method, Packetization Period and Bandwidth, shall follow the conventions laid out in SDP.
* 更明确地规定，三个LocalConnectionOptions参数、编码方法、打包周期和带宽的编码应遵循SDP中规定的约定。
* Specified how the quarantine handling parameter governs the handling of detected but not yet specified events.
* 指定隔离处理参数如何控制已检测但尚未指定事件的处理。
* Specified that unexpected timers or digits should trigger transmission of the dialed string.
* 指定意外计时器或数字应触发拨号字符串的传输。
* Removed the digit map syntax description from section 2.1.5 (it was redundant with section 3.4.)
* 从第2.1.5节中删除了数字映射语法描述（与第3.4节重复）
* Corrected miscellaneous bugs in the formal syntax description.
* 修正了形式语法描述中的各种错误。
* Aligned specification of commands with the CableLabs NCS specification. This mostly affects the AuditEndpoint and
* 命令规范与CableLabs NCS规范保持一致。这主要影响AuditEndpoint和
RestartInProgress commands.
重新启动进程命令。
* Aligned the handling of retransmission with the CableLabs NCS specification.
* 使重传处理与CableLabs NCS规范保持一致。
* Added the provisional response return code and corresponding behavior description.
* 添加了临时响应返回代码和相应的行为描述。
* Added an optional reason code parameter to restart in progress.
* 添加了一个可选的原因码参数以重新启动。
* Added the possibility to audit the restart method, restart delay and reason code.
* 增加了审核重启方法、重启延迟和原因代码的可能性。
Differences are minor: corrected the copyright statement, and corrected a bug in the formal description.
差异很小：更正了版权声明，并更正了正式描述中的错误。
Draft 04 corrects a number of minor editing mistakes that were pointed out during the review of draft 03, issued on February 1.
草案04纠正了2月1日发布的草案03审查期间指出的一些小编辑错误。
The main differences between draft-02, issued in January 22 1998, and draft 03 are:
1998年1月22日发布的第02号草案与第03号草案的主要区别在于：
* Introduced a discussion on endpoint types,
* 介绍了关于端点类型的讨论，
* Introduced a discussion of the connection set-up procedure, and of the role of connection parameters,
* 介绍了连接设置程序和连接参数作用的讨论，
* Introduced a notation of the connection identifier within event names,
* 在事件名称中引入了连接标识符的符号，
* Documented the extension procedure for the LocalConnectionOptions parameter and for the ConnectionParameters parameter,
* 记录了LocalConnectionOptions参数和ConnectionParameters参数的扩展过程，
* Introduced a three-way handshake procedure, using a ResponseAck parameter, in order to allow gateways to delete copies of old responses without waiting for a 30 seconds timer,
* 引入了一个三向握手过程，使用responseak参数，以便允许网关在不等待30秒计时器的情况下删除旧响应的副本，
* Expanded the security section to include a discussion of "uncontrolled barge-in."
* 扩展了安全部分，包括对“不受控制的驳船进入”的讨论
* Propsed a "create two connections" command, as an appendix.
* 提出了一个“创建两个连接”命令，作为附录。
The main differences between draft-01, issued in November 1998, and draft 02 are:
1998年11月发布的第01号草案与第02号草案的主要区别在于：
* Added an ABNF description of the protocol.
* 添加了协议的ABNF说明。
* Specification of an EndpointConfiguration command,
* 指定EndpointConfiguration命令，
* Addition of a "two endpoints" mode in the create connection command,
* 在创建连接命令中添加“两个端点”模式，
* Modification of the package wildcards from "$/$" to "*/all" at the Request of early implementors,
* 应早期实施者的请求，将包通配符从“$/$”修改为“*/all”，
* Revision of some package definitions to better align with external specifications.
* 修订一些包装定义，以更好地与外部规范保持一致。
* Addition of a specification for the handling of "failover."
* 添加了处理“故障转移”的规范
* Revision of the section on race conditions.
* 对比赛条件一节的修订。
MGCP version 0.1 results from the fusion of the SGCP and IPDC proposals.
MGCP版本0.1是SGCP和IPDC提案融合的结果。
MGCP version 0.1 (which subsumes SGCP version 1.2) introduces the following changes from SGCP version 1.1:
MGCP版本0.1（包含SGCP版本1.2）对SGCP版本1.1进行了以下更改：
* Protocol name changed to MGCP.
* 协议名称已更改为MGCP。
* Introduce a formal wildcarding structure in the name of endpoints, inspired from IPDC, and detailed the usage of wildcard names in each operation.
* 以端点的名称引入一种形式化的通配符结构，其灵感来源于IPDC，并详细说明了通配符名称在每个操作中的用法。
* Naming scheme for events, introducing a package structure inspired from IPDC.
* 事件的命名方案，引入了受IPDC启发的包结构。
* New operations for audit endpoint, audit connection (requested by the Cablelabs) and restart (inspired from IPDC).
* 审核端点、审核连接（Cablelabs请求）和重启（受IPDC启发）的新操作。
* New parameter to control the behavior of the notification request.
* 用于控制通知请求行为的新参数。
* Improved text on the detection and handling of race conditions.
* 改进了检测和处理竞争条件的文本。
* Syntax modification for event reporting, to incorporate package names.
* 事件报告的语法修改，以合并包名称。
* Definition of basic event packages (inspired from IPDC).
* 基本事件包的定义（受IPDC启发）。
* Incorporation of mandatory and optional extension parameters, inspired by IPDC.
* 受IPDC启发，纳入强制性和可选扩展参数。
SGCP version 1.1 introduces the following changes from version SGCP 1.0:
SGCP 1.1版引入了SGCP 1.0版的以下更改：
* Extension parameters (X-??:)
* 扩展参数（X-？：）
* Error Code 511 (Unrecognized extension).
* 错误代码511（无法识别的扩展名）。
* All event codes can be used in RequestEvent, SignalRequest and ObservedEvent parameters.
* 所有事件代码均可用于RequestEvent、SignalRequest和ObservedEvent参数。
* Error Code 512 (Not equipped to detect requested event).
* 错误代码512（未配备以检测请求的事件）。
* Error Code 513 (Not equipped to generate requested signal).
* 错误代码513（未配备以生成请求的信号）。
* Error Code 514 (Unrecognized announcement).
* 错误代码514（无法识别的公告）。
* Specific Endpoint-ID can be returned in creation commands.
* 可以在创建命令中返回特定的端点ID。
* Changed the code for the ASDI display from "ad" to "asdi" to avoid conflict with the digits A and D.
* 将ASDI显示的代码从“ad”更改为“ASDI”，以避免与数字A和D冲突。
* Changed the code for the answer tone from "at" to "aw" to avoid conflict with the digit A and the timer mark T
* 将应答音的代码从“at”更改为“aw”，以避免与数字A和计时器标记T冲突
* Changed the code for the busy tone from "bt" to "bz" to avoid conflict with the digit B and the timer mark T
* 将忙音代码从“bt”更改为“bz”，以避免与数字B和定时器标记T冲突
* Specified that the continuity tone value is "co" (CT was incorrectly used in several instances; CT conflicts with .)
* 指定连续性音调值为“co”（CT在多个实例中使用不正确；CT与冲突。）
* Changed the code for the dial tone from "dt" to "dl" to avoid conflict with the digit D and the timer mark T
* 将拨号音的代码从“dt”更改为“dl”，以避免与数字D和计时器标记T冲突
* Added a code point for announcement requests.
* 添加了公告请求的代码点。
* Added a code point for the "wink" event.
* 为“wink”事件添加了代码点。
* Set the "octet received" code in the "Connection Parameters" to "OR" (was set to RO, but then "OR" was used throughout all examples.)
* 将“连接参数”中的“接收到的八位字节”代码设置为“或”（设置为RO，但在所有示例中都使用了“或”）
* Added a "data" mode.
* 添加了“数据”模式。
* Added a description of SDP parameters for the network access mode (NAS).
* 添加了网络访问模式（NAS）的SDP参数说明。
* Added four flow diagrams for the network access mode.
* 为网络访问模式添加了四个流程图。
* Incorporated numerous editing suggestions to make the description easier to understand. In particular, cleared the confusion between requests, queries, functions and commands.
* 合并了许多编辑建议，使描述更易于理解。特别是，清除了请求、查询、函数和命令之间的混淆。
* Defined the continuity test mode as specifying a dual-tone transponder, while the loopback mode can be used for a single tone test.
* 将连续性测试模式定义为指定双音收发器，而环回模式可用于单音测试。
* Added event code "OC", operation completed.
* 添加事件代码“OC”，操作已完成。
* Added the specification of the "quarantine list", which clarifies the expected handling of events and notifications.
* 增加了“隔离列表”的规范，该规范澄清了事件和通知的预期处理。
* Added the specification of a "wildcard delete" operation.
* 添加了“通配符删除”操作的规范。
Security issues are discussed in section 5.
第5节讨论了安全问题。
We want to thank here the many reviewers who provided us with advice on the design of SGCP and then MGCP, notably Flemming Andreasen, Sankar Ardhanari, Francois Berard, David Auerbach, Bob Biskner, David Bukovinsky, Jerry Kamitses, Oren Kudevitzki, Barry Hoffner, Troy Morley, Dave Oran, Jeff Orwick, John Pickens, Lou Rubin, Chip Sharp, Paul Sijben, Kurt Steinbrenner, Joe Stone and Stuart Wray.
在此，我们要感谢为我们提供SGCP和MGCP设计建议的众多评论家，特别是弗莱明·安德烈森、桑卡·阿尔达纳里、弗朗索瓦·贝拉德、大卫·奥尔巴赫、鲍勃·比斯克纳、大卫·布科文斯基、杰瑞·卡米塞斯、奥伦·库德维茨基、巴里·霍夫纳、特洛伊·莫利、戴夫·奥兰、杰夫·奥维克、约翰·皮肯斯、卢·鲁宾、奇普、保罗·西本、，Kurt Steinbrenner，Joe Stone和Stuart Wray。
The version 0.1 of MGCP is heavily inspired by the "Internet Protocol Device Control" (IPDC) designed by the Technical Advisory Committee set up by Level 3 Communications. Whole sets of text have been retrieved from the IP Connection Control protocol, IP Media Control protocol, and IP Device Management. The authors wish to acknowledge the contribution to these protocols made by Ilya Akramovich, Bob Bell, Dan Brendes, Peter Chung, John Clark, Russ Dehlinger, Andrew Dugan, Isaac Elliott, Cary FitzGerald, Jan Gronski, Tom Hess, Geoff Jordan, Tony Lam, Shawn Lewis, Dave Mazik, Alan Mikhak, Pete O'Connell, Scott Pickett, Shyamal Prasad, Eric Presworsky, Paul Richards, Dale Skran, Louise Spergel, David Sprague, Raj Srinivasan, Tom Taylor and Michael Thomas.
MGCP的0.1版深受3级通信公司成立的技术咨询委员会设计的“互联网协议设备控制”（IPDC）的启发。已从IP连接控制协议、IP媒体控制协议和IP设备管理中检索到整套文本。作者希望感谢Ilya Akramovich、Bob Bell、Dan Brendes、Peter Chung、John Clark、Russ Dehlinger、Andrew Dugan、Isaac Elliott、Cary FitzGerald、Jan Gronski、Tom Hess、Geoff Jordan、Tony Lam、Shawn Lewis、Dave Mazik、Alan Mikhak、Pete O'Connell、Scott Pickett、Shymal Prasad、，Eric Presworsky、Paul Richards、Dale Skran、Louise Spergel、David Sprague、Raj Srinivasan、Tom Taylor和Michael Thomas。
* Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
* Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
* Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
* Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
* Handley, M and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
* Handley，M和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
* Handley, M., "SAP - Session Announcement Protocol", Work in Progress.
* 汉德利，M.，“SAP-会话公告协议”，正在进行中。
* Handley, M., Schulzrinne, H. and E. Schooler, "Session Initiation Protocol (SIP)", RFC 2543, March 1999.
* Handley，M.，Schulzrinne，H.和E.Schooler，“会话启动协议（SIP）”，RFC 25431999年3月。
* Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
* Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
* ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993)
* ITU-T，建议Q.761，“第7号信令系统ISDN用户部分的功能描述”（马拉加·托雷莫利诺斯，1984年；在赫尔辛基修改，1993年）
* ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIGNALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (MalagaTorremolinos, 1984; modified at Helsinki, 1993)
* ITU-T，建议Q.762，“第7号信令系统ISDN用户部分消息和信号的一般功能”，（Malagatoremolinos，1984年；在赫尔辛基修改，1993年）
* ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA COMMUNICATIONS SYSTEMS."
* ITU-T，建议H.323（02/98），“基于分组的多媒体通信系统。”
* ITU-T, Recommendation H.225, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems."
* ITU-T，建议H.225，“基于分组的多媒体通信系统的呼叫信令协议和媒体流分组。”
* ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MULTIMEDIA COMMUNICATION."
* ITU-T，建议H.245（02/98），“多媒体通信控制协议”
* Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
* Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
* Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
* Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
* Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
* Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
* Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
* Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
Mauricio Arango RSL COM Latin America 6300 N.W. 5th Way, Suite 100 Ft. Lauderdale, FL 33309
Mauricio Arango RSL COM拉丁美洲6300西北五路，劳德代尔100英尺套房，佛罗里达州33309
Phone: (954) 492-0913 EMail: marango@rslcom.com
电话：（954）492-0913电子邮件：marango@rslcom.com
Andrew Dugan Level3 Communications 1450 Infinite Drive Louisville, CO 80027
美国科罗拉多州路易斯维尔无限大道1450号安德鲁·杜根三级通信公司80027
Phone: (303)926 3123 EMail: andrew.dugan@l3.com
电话：（303）9263123电子邮件：安德鲁。dugan@l3.com
Isaac Elliott Level3 Communications 1450 Infinite Drive Louisville, CO 80027
美国科罗拉多州路易斯维尔无限大道1450号艾萨克·艾略特三级通信公司，邮编80027
Phone: (303)926 3123 EMail: ike.elliott@l3.com
电话：（303）9263123电子邮件：ike。elliott@l3.com
Christian Huitema Telcordia Technologies MCC 1J236B 445 South Street Morristown, NJ 07960 U.S.A.
Christian Huitema Telcordia Technologies MCC 1J236B 445美国新泽西州莫里斯镇南街07960号。
Phone: +1 973-829-4266
EMail: huitema@research.telcordia.com
Phone: +1 973-829-4266
EMail: huitema@research.telcordia.com
Scott Pickett Vertical Networks 1148 East Arques Ave Sunnyvale, CA 94086
斯科特·皮克特垂直网络加利福尼亚州桑尼维尔东阿克斯大道1148号，邮编94086
Phone: (408) 523-9700 extension 200 EMail: ScottP@vertical.com
电话：（408）523-9700分机200电子邮件：ScottP@vertical.com
Further information is available on the SGCP web site:
有关更多信息，请访问SGCP网站：
http://www.argreenhouse.com/SGCP/
http://www.argreenhouse.com/SGCP/
It has been proposed to create a new command, that would move an existing connection from one endpoint to another, on the same gateway. This command would be specially useful for handling certain call services, such as call forwarding between endpoints served by the same gateway.
有人建议在同一网关上创建一个新命令，将现有连接从一个端点移动到另一个端点。此命令对于处理某些呼叫服务特别有用，例如由同一网关服务的端点之间的呼叫转发。
[SecondEndPointId,]
[ConnectionId,]
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
SecondEndPointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
[SecondEndPointId,]
[ConnectionId,]
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
SecondEndPointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
The parameters used are the same as in the ModifyConnection command, with the addition of a SecondEndpointId that identifies the endpoint towards which the connection is moved.
使用的参数与ModifyConnection命令中的参数相同，只是添加了一个SecondEndpointId，用于标识连接移动到的端点。
The EndpointId should be the fully qualified endpoint identifier of the endpoint on which the connection has been created. The local name shall not use the wildcard convention.
EndpointId应该是在其上创建连接的端点的完全限定端点标识符。本地名称不得使用通配符约定。
The SecondEndpointId shall be the endpoint identifier of the endpoint towards which the connection has been created. The "any of" wildcard convention can be used, but not the "all of" convention. If the SecondEndpointId parameter is unqualified, the gateway will choose a value, that will be returned to the call agent as a response parameter.
SecondEndpointId应为已创建连接的端点的端点标识符。可以使用“任意”通配符约定，但不能使用“全部”约定。如果SecondEndpointId参数不合格，网关将选择一个值，该值将作为响应参数返回给调用代理。
The command will result in the "move" of the existing connection to the second endpoint. Depending on gateway implementations, the connection identifier of the connection after the move may or may not be the same as the connection identifier before the move. If it is not the same, the new value is returned as a response parameter.
该命令将导致现有连接“移动”到第二个端点。根据网关实现，移动后连接的连接标识符可能与移动前的连接标识符相同，也可能不同。如果不相同，则新值将作为响应参数返回。
The intent of the command is to effect a local relocation of the connection, without having to modify such transmission parameters as IP addresses and port, and thus without forcing the call agent to signal the change of parameters to the remote gateway, at the other
该命令的目的是实现连接的本地重新定位，而无需修改诸如IP地址和端口之类的传输参数，从而无需强制呼叫代理在另一方向远程网关发送参数更改的信号
end of the connection. However, gateway architectures may not always allow such transparent moves. For example, some architectures could allow specific IP addresses to different boards that handles specific group of endpoints. If for any reason the transmission parameters have to be changed as a result of the move, the new LocalConnectionDescriptor is returned as a response parameter.
连接结束。然而，网关架构可能并不总是允许这种透明的移动。例如，某些体系结构可能允许将特定IP地址发送到处理特定端点组的不同板。如果由于任何原因，传输参数必须因移动而更改，则新的LocalConnectionDescriptor将作为响应参数返回。
The LocalConnectionOptions, Mode, and RemoteConnectionDescriptor, when present, are applied after the move.
LocalConnectionOptions、Mode和RemoteConnectionDescriptor（如果存在）将在移动后应用。
The RequestedEvents, RequestIdentifier, DigitMap, SignalRequests, QuarantineHandling and DetectEvents parameters are optional. They can be used by the Call Agent to transmit a NotificationRequest that is executed simultaneously with the move of the connection. When these parameters are present, the NotificationRequest applies to the second endpoint.
RequestedEvents、RequestIdentifier、DigitMap、SignalRequests、QuarantineHandling和DetectedEvents参数是可选的。呼叫代理可以使用它们来传输NotificationRequest，该NotificationRequest与连接的移动同时执行。当这些参数存在时，NotificationRequest将应用于第二个端点。
When these parameters are present, the move and the NotificationRequests should be synchronized, which means that both should be accepted, or both refused. The NotifiedEntity parameter, if present, applies to both the ModifyConnection and the NotificationRequest command.
当这些参数存在时，move和NotificationRequests应该同步，这意味着两者都应该被接受，或者两者都被拒绝。NotifiedEntity参数（如果存在）同时应用于ModifyConnection和NotificationRequest命令。
The command may carry an encapsulated EndpointConfiguration command, that will also apply to the second endpoint. When this command is present, the parameters of the EndpointConfiguration command are inserted after the normal parameters of the MoveConnection with the exception of the SecondEndpointId, which is not replicated. The End-pointConfiguration command may be encapsulated together with an encapsulated NotificationRequest command.
该命令可以携带封装的EndpointConfiguration命令，该命令也将应用于第二个端点。存在此命令时，EndpointConfiguration命令的参数将插入到MoveConnection的正常参数之后，但SecondEndpointId除外，它不会被复制。端点配置命令可以与封装的NotificationRequest命令一起封装。
The encapsulated EndpointConfiguration command shares the fate of the MoveConnection command. If the MoveConnection is rejected, the End-pointConfiguration is not executed.
封装的EndpointConfiguration命令共享MoveConnection命令的命运。如果MoveConnection被拒绝，则不会执行端点配置。
The only syntax modification necessary for the addition of the moveConnection command is the addition of the keyword MOVE to the authorized values in the MGCPVerb clause of the formal syntax.
添加moveConnection命令所需的唯一语法修改是将关键字MOVE添加到形式语法的MGCPVerb子句中的授权值中。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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编辑功能的资金目前由互联网协会提供。