Network Working Group B. Foster
Request for Comments: 3991 F. Andreasen
Category: Informational Cisco Systems
February 2005
Network Working Group B. Foster
Request for Comments: 3991 F. Andreasen
Category: Informational Cisco Systems
February 2005
Media Gateway Control Protocol (MGCP) Redirect and Reset Package
媒体网关控制协议（MGCP）重定向和重置包
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 (2005).
版权所有（C）互联网协会（2005年）。
IESG Note
IESG注释
This document is being published for the information of the community. It describes a non-IETF protocol that is currently being deployed in a number of products. Implementers should be aware of RFC 3015, which was developed in the IETF Megaco Working Group and the ITU-T SG16, and which is considered the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address by the IETF and the ITU-T.
本文件发布供社区参考。它描述了目前正在许多产品中部署的非IETF协议。实施者应了解RFC 3015，它是在IETF Megaco工作组和ITU-T SG16中开发的，被认为是基于标准（包括经审查的安全考虑）的方式，以满足IETF和ITU-T设计的MGCP的需求。
Abstract
摘要
The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order.
基本媒体网关控制协议（MGCP）规范（RFC 3435）允许将端点一次重定向到一个端点。本文档以新MGCP包的形式提供扩展，该包提供重定向和重置一组端点的机制。它还包括通过允许按首选顺序指定调用代理列表来更准确地重定向端点的能力。
Table of Contents
目录
1. Introduction.................................................. 2
1.1. Conventions Used in This Document....................... 3
2. Redirect and Reset Package.................................... 3
2.1. NotifiedEntityList Extension Parameter.................. 3
2.2. Endpoint Specifier...................................... 4
2.2.1. EndpointList and EndpointMap Extension
Parameters...................................... 4
2.2.2. Application to Out-of-Service Endpoints......... 6
2.3. Redirect................................................ 6
2.4. Reset Extension Parameter............................... 7
2.5. Return Codes............................................ 8
3. IANA Considerations........................................... 9
4. Security Considerations....................................... 9
5. Normative References.......................................... 9
Authors' Addresses................................................ 10
Full Copyright Statement.......................................... 11
1. Introduction.................................................. 2
1.1. Conventions Used in This Document....................... 3
2. Redirect and Reset Package.................................... 3
2.1. NotifiedEntityList Extension Parameter.................. 3
2.2. Endpoint Specifier...................................... 4
2.2.1. EndpointList and EndpointMap Extension
Parameters...................................... 4
2.2.2. Application to Out-of-Service Endpoints......... 6
2.3. Redirect................................................ 6
2.4. Reset Extension Parameter............................... 7
2.5. Return Codes............................................ 8
3. IANA Considerations........................................... 9
4. Security Considerations....................................... 9
5. Normative References.......................................... 9
Authors' Addresses................................................ 10
Full Copyright Statement.......................................... 11
The base Media Gateway Control Protocol (MGCP) specification [2] allows a Call Agent to specify a new NotifiedEntity parameter in order to redirect one or more endpoints to a new Call Agent. This must be done in a NotificationRequest or a connection handling command. However, because these commands affect endpoint or connection state, such a request cannot typically be sent to a group of endpoints with a single command. This means that if a new Call Agent takes over for a failed one, the new Call Agent must redirect endpoints one at a time. If there is a large number of endpoints (e.g., within a large trunking gateway), this could take considerable time.
基本媒体网关控制协议（MGCP）规范[2]允许呼叫代理指定新的NotifiedIdentity参数，以便将一个或多个端点重定向到新的呼叫代理。这必须在NotificationRequest或连接处理命令中完成。但是，由于这些命令会影响端点或连接状态，因此通常无法使用单个命令将此类请求发送到一组端点。这意味着，如果一个新的调用代理接管了一个失败的调用代理，那么新的调用代理必须一次重定向一个端点。如果存在大量端点（例如，在大型集群网关内），这可能需要相当长的时间。
This document defines a new redirect and reset package for MGCP that allows the Call Agent to redirect a group of endpoints without affecting endpoint or connection state.
本文档为MGCP定义了一个新的重定向和重置包，该包允许调用代理重定向一组端点，而不影响端点或连接状态。
Also included is a new NotifiedEntityList parameter, which is similar to the NotifiedEntity parameter but allows for multiple domain names to be provided. This allows the Call Agent to more accurately direct endpoints to a preferred ordered list of alternate Call Agents.
还包括一个新的NotifiedEntityList参数，该参数类似于NotifiedEntity参数，但允许提供多个域名。这允许呼叫代理更准确地将端点指向备用呼叫代理的首选有序列表。
A third capability contained in this package is the ability to reset and re-initialize one or more groups of endpoints efficiently. This capability is useful in Call Agent failover situations.
此包中包含的第三个功能是能够高效地重置和重新初始化一个或多个端点组。此功能在呼叫代理故障切换情况下非常有用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
Package Name: RED Version: 0
包名称：红色版本：0
This package does the following:
此程序包执行以下操作：
* Defines a new NotifiedEntityList extension parameter. This works the same as the NotifiedEntity parameter in [2] but allows more than one domain name to be specified.
* 定义新的NotifiedEntityList扩展参数。其工作原理与[2]中的NotifiedEntity参数相同，但允许指定多个域名。
* Allows a Call Agent to pass a new NotifiedEntity or NotifiedEntityList to a collection of endpoints specified by an "all of" wildcard. This is useful if a new Call Agent takes over from a previous one and wants to redirect endpoint(s) to send messages to it from now on.
* 允许调用代理将新的NotifiedEntity或NotifiedEntityList传递给由“全部”通配符指定的端点集合。如果一个新的调用代理从以前的调用代理接管，并希望从现在起重定向端点以向其发送消息，那么这将非常有用。
* Allows a Call Agent to request one or more groups of endpoints to do a reset, which can be useful following certain types of failures.
* 允许呼叫代理请求一个或多个端点组执行重置，这在某些类型的故障后非常有用。
The NotifiedEntityList parameter is encoded as "NL" and is followed by a colon and a comma-separated list of NotifiedEntity values as defined in the MGCP specification [2], as follows:
NotifiedEntityList参数编码为“NL”，后跟一个冒号和一个逗号分隔的NotifiedEntityValue列表，如MGCP规范[2]中所定义，如下所示：
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
The NotifiedEntityList works in a way similar to the NotifiedEntity parameter, except that it allows multiple domain names to be listed. The NotifiedEntityList thus specifies a new "notified entity" for the endpoint.
NotifiedEntityList的工作方式与NotifiedEntity参数类似，只是它允许列出多个域名。因此，NotifiedEntityList为端点指定了一个新的“通知实体”。
The NotifiedEntityList parameter is optional in any command or response where the NotifiedEntity parameter is allowed. Following a restart, the NotifiedEntityList is initially empty, unless provisioned otherwise. In subsequent commands, it retains its current value until explicitly changed. If both a NotifiedEntity parameter and a non-empty NotifiedEntityList parameter have been set (not necessarily at the same time), the NotifiedEntity parameter value will be viewed as being implicitly added to the beginning of
NotifiedEntityList参数在允许NotifiedEntityList参数的任何命令或响应中都是可选的。重新启动后，NotifiedEntityList最初为空，除非另有规定。在后续命令中，它将保留其当前值，直到显式更改为止。如果同时设置了NotifiedEntity参数和非空NotifiedEntityList参数（不一定同时设置），则NotifiedEntity参数值将被视为隐式添加到
the NotifiedEntityList parameter. The NotifiedEntity parameter thus always defines the first domain name to contact unless it has explicitly been set to empty. In that case, the NotifiedEntityList defines the "notified entity". If the NotifiedEntityList is also empty, then the normal MGCP handling of an empty "notified entity" applies. We will refer to the list of domain names that result from the above rules as the "notified entity list".
NotifiedEntityList参数。因此，NotifiedEntity参数始终定义要联系的第一个域名，除非它已显式设置为空。在这种情况下，NotifiedEntityList定义了“通知实体”。如果NotifiedEntityList也为空，则适用空“NotifiedEntity”的正常MGCP处理。我们将上述规则产生的域名列表称为“通知实体列表”。
When the "notified entity list" is non-empty, transmission is first attempted with the first domain name in the list, as in the normal MGCP retransmission procedures described in [2]. Each of the IP addresses for this domain name MUST first be tried as specified in [2], and if this is unsuccessful, each of the IP-addresses for the second domain name MUST then be attempted, etc., following the normal MGCP retransmission procedures, with "N" (the number of retransmissions) set to zero for each domain name (see Section 4.3 in [2]). Whenever retransmission to a new domain name is initiated, the default retransmission timer value (RTO), etc., SHOULD be used. The estimator (T-DELAY) and measurements (AAD and ADEV) used for the transmission to the previous domain name are considered obsolete. Note, however, that the maximum transaction lifetime considerations apply as usual; therefore, retransmission to any of the IP addresses for any of the domain names MUST NOT occur more than T-Max seconds after the command is initially sent, irrespective of where it was sent. The Max1 DNS query MAY be performed for each of the domain names, or it MAY simply be performed for the first domain name. The Max2 DNS query however MUST NOT be performed for any but the last domain name. Also note that only the last IP-address for the last domain name can reach Max2 retransmissions; therefore, retransmission to all IP addresses other than the last IP address of the last domain name in the list MUST end after Max1 retransmissions.
当“通知实体列表”为非空时，首先尝试使用列表中的第一个域名进行传输，如[2]中所述的正常MGCP重传过程。必须首先按照[2]中的规定尝试该域名的每个IP地址，如果不成功，则必须按照正常的MGCP重传程序尝试第二个域名的每个IP地址，并将每个域名的“N”（重传次数）设置为零（见[2]中的第4.3节）. 无论何时开始重新传输到新域名，都应使用默认的重新传输计时器值（RTO）等。用于传输到先前域名的估计器（T延迟）和测量值（AAD和ADEV）被认为是过时的。但是，请注意，最大事务生存期考虑因素照常适用；因此，任何域名的任何IP地址的重传在命令最初发送后不得超过T-Max秒，无论命令发送到何处。可以对每个域名执行Max1 DNS查询，也可以仅对第一个域名执行Max1 DNS查询。但是，除最后一个域名外，不得对任何其他域名执行Max2 DNS查询。还要注意，只有最后一个域名的最后一个IP地址才能达到Max2重传；因此，对列表中最后一个域名的最后一个IP地址以外的所有IP地址的重新传输必须在Max1重新传输后结束。
The current value of the NotifiedEntityList parameter can be audited via AuditEndpoint; the value of the NotifiedEntity parameter will not be included here and must be audited separately. Support for the NotifiedEntityList in AuditConnection is permissible, but it is neither required nor recommended.
NotifiedEntityList参数的当前值可以通过AuditEndpoint进行审核；此处不包括NotifiedEntity参数的值，必须单独审核。允许在AuditConnection中支持NotifiedEntityList，但既不是必需的，也不是推荐的。
A simple "all-of" wildcard, as defined in [2], may not be sufficient to accurately specify endpoints of interest. An example of this is a case where a Call Agent fails over, resulting in a state mismatch for endpoints involved with transient calls. To re-synchronize, the Call Agent can use the reset extension parameter described in section 2.4 of this document, to ensure that idle endpoints are in fact idle.
[2]中定义的简单“全部”通配符可能不足以准确指定感兴趣的端点。这方面的一个例子是调用代理发生故障切换，导致与瞬时调用相关的端点的状态不匹配。要重新同步，调用代理可以使用本文档第2.4节中描述的重置扩展参数，以确保空闲端点实际上是空闲的。
However, these endpoints may be randomly distributed across the available endpoints in a large trunk gateway.
但是，这些端点可以随机分布在大型中继网关中的可用端点上。
To satisfy this requirement, the RED package introduces some new parameters that may be used to specify the endpoints of interest for the EndpointConfiguration Command. These are the EndpointList and the EndpointMap extension parameters. These parameters MUST only be used when a virtual endpoint corresponding to the gateway is specified as the LocalEndpointName, such as:
为了满足这一要求，红色包引入了一些新参数，这些参数可用于为EndpointConfiguration命令指定感兴趣的端点。这些是EndpointList和EndpointMap扩展参数。仅当与网关对应的虚拟端点指定为LocalEndpointName时，才能使用这些参数，例如：
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
EPCF 1200MG@gw1.whatever.netMGCP 1.0
where "MG" is the virtual endpoint name associated with the gateway.
其中“MG”是与网关关联的虚拟端点名称。
The EndPointList parameters is a list of endpoint names that can include one or more lines in the following format:
EndPointList参数是端点名称的列表，可以包括以下格式的一行或多行：
"RED/EL:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
"RED/EL:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
RangedLocalName is a LocalEndpointName that may include the range wildcard notation described in Appendix E (section E.5) of [2] as well as an "all" wildcard, but the two forms MUST NOT be mixed in a single command:
RangedLocalName是一个LocalEndpointName，它可能包括[2]附录E（第E.5节）中所述的范围通配符符号以及“全部”通配符，但不能在单个命令中混合使用这两种形式：
RangeWildcard = "*" / "[" NumericalRange *("," NumericalRange)"]"
NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]
RangeWildcard = "*" / "[" NumericalRange *("," NumericalRange)"]"
NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]
Example:
例子：
RED/EL: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
RED/EL: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
Including an EndpointMap parameter with the following format can further specify the endpoints:
包含具有以下格式的EndpointMap参数可以进一步指定端点：
"RED/MP:" 0*WSP TrueOrFalse 0*(TrueOrFalse)
"RED/MP:" 0*WSP TrueOrFalse 0*(TrueOrFalse)
TrueOrFalse = "T" / "F"
TrueOrFalse = "T" / "F"
"T" indicates that the command should be applied to the corresponding endpoint, and "F" indicates that it should not. This parameter can be used in conjunction with the reset extension parameter described in section 2.4 of this document to force arbitrarily distributed endpoints into an idle state.
“T”表示该命令应应用于相应的端点，“F”表示不应应用于该端点。此参数可与本文档第2.4节中描述的重置扩展参数结合使用，以强制任意分布的端点进入空闲状态。
If the EndpointMap parameter is used, it MUST be immediately preceded (i.e., on the previous line) by an EndPointList parameter to specify the endpoints the EndpointMap is referring to (the EndPointList MUST NOT contain the "all" wildcard). Several EndpointList and
如果使用EndpointMap参数，则必须在该参数之前（即在前一行）立即使用EndPointList参数来指定EndpointMap所引用的端点（EndPointList不得包含“all”通配符）。几个端点列表和
EndpointMap parameter lines can be provided. It is considered an error if an EndpointMap parameter extends beyond the endpoints specified in the preceding EndPointList parameter. In that case, return code 800 MUST be used (see section 2.5).
可以提供EndpointMap参数行。如果EndpointMap参数超出了前面的EndPointList参数中指定的端点，则视为错误。在这种情况下，必须使用返回码800（见第2.5节）。
The EndpointList and EndpointMap parameters MUST only be used with the EndpointConfiguration command. The EndpointList parameter MAY be provided without an EndpointMap parameter. However, as indicated earlier, an EndpointMap parameter MUST be immediately preceded by an EndpointList parameter. Neither of these parameters is auditable.
EndpointList和EndpointMap参数只能与EndpointConfiguration命令一起使用。EndpointList参数可以在没有EndpointMap参数的情况下提供。但是，如前所述，EndpointMap参数前面必须紧跟EndpointList参数。这两个参数都不可审核。
For an example of EndpointMap parameter usage, see Section 2.4.
有关EndpointMap参数用法的示例，请参见第2.4节。
Note that the EndpointConfiguration command is normally only valid for in-service endpoints. If an EndpointConfiguration request is sent to a wildcarded LocalEndpointName [2] and any of the endpoints specified are out-of-service, the command will fail with return code 501 (endpoint not ready).
请注意，EndpointConfiguration命令通常仅对服务中的端点有效。如果向通配符的LocalEndpointName[2]发送EndpointConfiguration请求，并且指定的任何端点都已停止服务，则该命令将失败，返回代码501（端点未就绪）。
However, as long as the gateway is in service and able to respond to MGCP commands, it can apply the endpoint configuration command to endpoints specified by the EndpointList and/or EndpointMap parameters (regardless of whether those endpoints are in-service). Of course, the endpoint configuration information will not be maintained over gateway restarts (as the Call Agent would have to reapply the endpoint configuration after it receives an RSIP with the restart method "restart"). For example, if a new "notified entity" was provided, it would have no effect since the provisioned value would be used upon restart.
但是，只要网关处于服务状态并且能够响应MGCP命令，它就可以将端点配置命令应用于端点列表和/或端点映射参数指定的端点（无论这些端点是否处于服务状态）。当然，端点配置信息不会在网关重新启动时维护（因为调用代理必须在收到带有重新启动方法“restart”的RSIP后重新应用端点配置）。例如，如果提供了一个新的“通知实体”，它将没有任何效果，因为重新启动时将使用提供的值。
EndpointList and/or EndpointMap parameters MUST only be used with a virtual endpoint name corresponding to the gateway (as indicated above). If it is used with any other endpoint name (whether wild-carded or not), then error code 801 (section 2.5) MUST be returned.
EndpointList和/或EndpointMap参数只能与网关对应的虚拟端点名称一起使用（如上所述）。如果它与任何其他端点名称（无论是否通配符）一起使用，则必须返回错误代码801（第2.5节）。
A new extension parameter for use with the EndpointConfiguration command is defined. A new NotifiedEntity value can be included with a "RED/N" parameter as follows:
定义了用于EndpointConfiguration命令的新扩展参数。新的NotifiedEntity值可以包含在“RED/N”参数中，如下所示：
EPCF 1200 *@gw1.whatever.net MGCP 1.0
RED/N: ca1@ca1234.whatever.net
EPCF 1200 *@gw1.whatever.net MGCP 1.0
RED/N: ca1@ca1234.whatever.net
This changes the "notified entity" for the endpoint(s) to the value specified. If the "all of" wildcard convention is used, the NotifiedEntity value replaces all of the existing "notified entities" for those endpoints. If NotifiedEntity is omitted in a subsequent EndpointConfiguration command, the "notified entity" remains unchanged.
这将端点的“通知实体”更改为指定的值。如果使用“全部”通配符约定，则NotifiedEntity值将替换这些端点的所有现有“通知实体”。如果在后续的EndpointConfiguration命令中省略NotifiedEntity，则“通知的实体”保持不变。
If the "notified entity" is a domain name that resolves to multiple IP addresses, one of the resolved addresses MUST be selected. If one of those IP addresses is the IP address of the Call Agent sending the request, that IP address SHOULD be selected first.
如果“通知实体”是解析为多个IP地址的域名，则必须选择其中一个解析的地址。如果其中一个IP地址是发送请求的呼叫代理的IP地址，则应首先选择该IP地址。
The NotifiedEntityList parameter can also be specified in an endpoint configuration command, such as follows:
还可以在端点配置命令中指定NotifiedEntityList参数，如下所示：
EPCF 1200 *@gw1.whatever.net MGCP 1.0
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
EPCF 1200 *@gw1.whatever.net MGCP 1.0
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
Note that this command will only succeed if all the endpoints on the gateway are in-service.
请注意，只有当网关上的所有端点都在使用中时，此命令才会成功。
As indicated in section 2.2, it can also apply this to the gateway virtual endpoint:
如第2.2节所述，它还可以将此应用于网关虚拟端点：
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
RED/EL: *
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
RED/EL: *
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
Note that the outcome of this command is not affected by the service state of the endpoints on the gateway.
请注意，此命令的结果不受网关上端点的服务状态的影响。
As indicated in section 2.1, the NotifiedEntityList ("RED/NL") parameter may be used with any command for which a NotifiedEntity parameter is allowed. However, the "RED/N" parameter SHOULD only be used with the endpoint configuration command.
如第2.1节所述，NotifiedEntityList（“RED/NL”）参数可与允许使用NotifiedEntity参数的任何命令一起使用。但是，“RED/N”参数只能与endpoint configuration命令一起使用。
The "RED/N" parameter does not have a default value, and the auditing behavior for auditing the "NotifiedEntity" is unchanged from that specified in [2], regardless of how the "NotifiedEntity" was set (i.e., there is no specific audit associated with the "RED/N" parameter, and therefore the "RED/N" parameter cannot be audited).
“RED/N”参数没有默认值，并且审核“NotifiedEntity”的审核行为与[2]中指定的审核行为保持不变，无论“NotifiedEntity”是如何设置的（即，没有与“RED/N”参数关联的特定审核，因此无法审核“RED/N”参数）。
Another EndpointConfiguration parameter ("RED/R") allows the Call Agent to reset one or more endpoints. The ABNF syntax for the parameter line is as follows:
另一个EndpointConfiguration参数（“红色/R”）允许调用代理重置一个或多个端点。参数行的ABNF语法如下所示：
"RED/R:" 0*WSP "reset"
"RED/R:" 0*WSP "reset"
This has the effect of resetting and re-initializing the specified endpoints (i.e., any connections on the endpoint will be deleted, and the endpoint will be returned to its clean default state without any active signals).
这具有重置和重新初始化指定端点的效果（即，端点上的任何连接都将被删除，并且端点将返回到其干净的默认状态，而没有任何活动信号）。
Example:
例子：
EPCF 1200 mg@gw1.whatever.net MGCP 1.0
RED/EL: ds/e1-3/[1-30]
RED/MP: TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF
RED/EL: ds/e1-5/[1-30]
RED/MP: TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT
RED/R: reset
EPCF 1200 mg@gw1.whatever.net MGCP 1.0
RED/EL: ds/e1-3/[1-30]
RED/MP: TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF
RED/EL: ds/e1-5/[1-30]
RED/MP: TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT
RED/R: reset
In this case, the particular endpoints specified by "T" by the EndpointMap parameter in the E1 spans ds/e1-3 and ds/e1-5 are reset.
在这种情况下，将重置由E1跨度ds/E1-3和ds/E1-5中的EndpointMap参数“T”指定的特定端点。
The "RED/R" parameter MUST NOT be used with any command other than the endpoint configuration command. There is no default value for the parameter, and therefore it is unaffected when omitted. There is no specific audit behavior associated with this parameter, i.e., it cannot be audited.
“RED/R”参数不得与端点配置命令以外的任何命令一起使用。该参数没有默认值，因此省略时不受影响。没有与此参数关联的特定审核行为，即无法对其进行审核。
The following package-specific return codes are defined for the "RED" package:
为“红色”包装定义了以下特定于包装的返回代码：
Code Text Explanation
代码文本解释
800 EndpointMap Either the EndpointMap parameters Out of Range are outside the range specified by the EndpointList parameter, or the EndpointList Parameter was not included when an EndpointMap parameter was included.
800 EndpointMap范围之外的EndpointMap参数超出EndpointList参数指定的范围，或者在包含EndpointMap参数时未包含EndpointList参数。
801 Incorrect Usage Incorrect usage of parameters, Of Parameters such as EndpointList parameter, used where the endpoint name was not the virtual endpoint name corresponding to the gateway.
801错误用法在端点名称不是与网关对应的虚拟端点名称的情况下使用的参数（如EndpointList参数）的错误用法。
The MGCP package title "Redirect and Reset" with the name "RED" and version number 0 has been registered with IANA, as indicated in Appendix C.1 in [2].
如[2]中附录C.1所示，名称为“RED”且版本号为0的MGCP包标题“重定向和重置”已向IANA注册。
Section 5 of the base MGCP specification [2] discusses security requirements for the base protocol that apply equally to the package defined in this document. Use of a security protocol that provides per message authentication and integrity services, such as IPsec (RFC 2401 [3], RFC 2406 [4]), is required in order to ensure that requests and responses are obtained from authenticated sources and that messages have not been modified. Without these services, gateways and Call Agents are open to attacks.
基本MGCP规范[2]第5节讨论了基本协议的安全要求，这些要求同样适用于本文件中定义的包。需要使用提供每条消息的身份验证和完整性服务的安全协议，如IPsec（RFC 2401[3]，RFC 2406[4]），以确保从经过身份验证的源获得请求和响应，并且消息未被修改。如果没有这些服务，网关和呼叫代理就会受到攻击。
For example, an attacker could masquerade as a Call Agent and initiate a denial of service attack by resetting endpoints that were involved in valid calls. Another attack using the package described in this document could involve redirecting endpoints to the attacker so that it acts as the Call Agent for those endpoints.
例如，攻击者可以伪装成呼叫代理，通过重置有效呼叫中涉及的端点来发起拒绝服务攻击。使用本文档中描述的包进行的另一次攻击可能涉及将端点重定向到攻击者，使其充当这些端点的调用代理。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2] Andreasen，F.和B.Foster，“媒体网关控制协议（MGCP）1.0版”，RFC 3435，2003年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
Authors' Addresses
作者地址
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
弗莱明·安德里森思科系统公司，地址：新泽西州爱迪生市索纳尔街499号8楼，邮编：08837
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com
Bill Foster Cisco Systems
比尔·福斯特思科系统公司
EMail: bfoster@cisco.com
EMail: bfoster@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。