Network Working Group B. Foster
Request for Comments: 3992 F. Andreasen
Category: Informational Cisco Systems
February 2005
Network Working Group B. Foster
Request for Comments: 3992 F. Andreasen
Category: Informational Cisco Systems
February 2005
Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
媒体网关控制协议（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
摘要
A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures.
遇到不利故障条件的媒体网关控制协议（MGCP）终结点（例如，在发生呼叫代理故障转移时涉及暂时呼叫）可能处于锁定状态，从而隔离事件但不通知事件。本文档中描述的MGCP包提供了一种报告这些情况的机制，以便新的呼叫代理可以执行必要的故障恢复过程。
In the Media Gateway Control Protocol (MGCP) [2], when an endpoint operating in "step" mode generates a Notify, it will enter the notification state, where it waits for a response to the Notify. Furthermore, the endpoint must wait for a new NotificationRequest before it can resume event processing. As long as the endpoint is waiting for this NotificationRequest, we say that it is in the lockstep state.
在媒体网关控制协议（MGCP）[2]中，当在“步骤”模式下运行的端点生成通知时，它将进入通知状态，等待对通知的响应。此外，端点必须等待新的NotificationRequest，然后才能恢复事件处理。只要端点正在等待此NotificationRequest，我们就说它处于lockstep状态。
An endpoint that is in the lockstep state cannot perform any event processing and therefore also cannot generate a new Notify. Endpoints should only be in the lockstep state for a very short time. However, in adverse conditions, an endpoint could potentially end in the lockstep state without the Call Agent realizing it. Clearly, this could have very negative consequences in terms of the service provided.
处于lockstep状态的端点无法执行任何事件处理，因此也无法生成新通知。端点应仅在很短的时间内处于锁定状态。但是，在不利条件下，端点可能会在调用代理未实现的情况下以锁定状态结束。显然，这可能对所提供的服务产生非常负面的影响。
The Lockstep package defined in this document defines extensions to the EndpointConfiguration and RestartInProgress commands that allow a Call Agent to request an endpoint to inform it when the endpoint is in the lockstep state for a specified period of time.
本文档中定义的Lockstep包定义了EndpointConfiguration和RestartInProgress命令的扩展，这些命令允许呼叫代理请求端点在指定时间段内处于Lockstep状态时通知它。
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: LCK Version: 0
包名称：LCK版本：0
Package Description: The purpose of this package is to provide a mechanism for reporting a condition in which an endpoint has been in the "lockstep state" for a specified period of time.
包说明：此包的目的是提供一种机制，用于报告端点在指定时间段内处于“锁定步骤状态”的情况。
There are two aspects of this package:
该方案有两个方面：
* The ability for a Call Agent to request endpoints to report if they are in lockstep state for a specified period of time. This is done with the EndpointConfiguration command, as described in section 2.1.
* 呼叫代理请求端点报告其在指定时间段内是否处于锁定状态的能力。这是通过EndpointConfiguration命令完成的，如第2.1节所述。
* The reporting mechanism itself, which is done with a new "lockstep" RestartMethod for the RSIP command as described in section 2.2.
* 报告机制本身，如第2.2节所述，通过RSIP命令的新“lockstep”重启方法完成。
The new "LCK/LST" EndpointConfiguration parameter is used by the Call Agent to request the reporting of "lockstep" state. It uses the following ABNF:
调用代理使用新的“LCK/LST”EndpointConfiguration参数来请求报告“lockstep”状态。它使用以下ABNF：
"LCK/LST:" 0*WSP LSTIME
"LCK/LST:" 0*WSP LSTIME
LSTIME = 1*(4DIGIT)
LSTIME = 1*(4DIGIT)
where LSTIME is expressed in seconds, with a value ranging from 0 to 9999. A value greater than 2*T-HIST (refer to [2]) is RECOMMENDED.
其中，LSTIME以秒表示，其值范围为0到9999。建议使用大于2*T-HIST的值（参考[2]）。
LSTIME is the amount of time the endpoint is in the lockstep state before reporting. The timer starts when the endpoint enters the lockstep state and is canceled if the endpoint leaves the lockstep state before the timeout occurs. The value provided remains in effect until explicitly changed (or a restart occurs). If the endpoint is already in the lockstep state when a non-zero timer value is provided, the lockstep timer is simply started with the value provided; any existing lockstep timer is cancelled. The value zero is used to turn off reporting.
LSTIME是端点在报告之前处于锁定步骤状态的时间量。当端点进入锁步状态时计时器启动，如果端点在超时发生之前离开锁步状态，则计时器取消。提供的值在显式更改（或重新启动）之前保持有效。如果在提供非零计时器值时端点已经处于锁步状态，则仅使用提供的值启动锁步计时器；任何现有的锁步计时器都将被取消。值零用于关闭报告。
This parameter can be audited by using the AuditEndpoint command. The value returned is the last configured value, or the value zero when no value was configured.
可以使用AuditEndpoint命令审核此参数。返回的值是上次配置的值，或者在未配置值时为零。
A new "lockstep" restart method is defined in the "LCK" package. A RestartInProgress (RSIP) will be sent with this RestartMethod if the endpoint has been configured with a non-zero value for LSTIME and that timer has expired. Note that once the lockstep timer has been set, it can fire only once per Notify command; however it is possible to set the timer more than once while an endpoint is in lockstep state (and hence rearm it for that particular Notify). The syntax of the restart method is as per [2]:
“LCK”包中定义了一种新的“lockstep”重启方法。如果端点配置了LSTIME的非零值，并且该计时器已过期，则将使用此RestartMethod发送RestartInProgress（RSIP）。请注意，一旦设置了lockstep定时器，则每个Notify命令只能触发一次；但是，当端点处于锁步状态时，可以多次设置计时器（从而为该特定通知重新设置计时器）。重启方法的语法如[2]所示：
"RM" ":" 0*(WSP) "LCK/lockstep"
"RM" ":" 0*(WSP) "LCK/lockstep"
RestartDelay (see [2]) is not used with the "lockstep" RestartMethod. Also, the "lockstep" RestartMethod does not define a service-state, and thus it will never be returned when auditing the RestartMethod.
RestartDelay（参见[2]）不与“lockstep”RestartMethod一起使用。此外，“lockstep”RestartMethod没有定义服务状态，因此在审核RestartMethod时将永远不会返回服务状态。
The MGCP package title "Lockstep" with the name "LCK" and version number zero has been registered with IANA as indicated in Appendix C.1 in [2].
如[2]中附录C.1所示，名称为“LCK”且版本号为零的MGCP包标题“Lockstep”已向IANA注册。
Section 5 of the base MGCP specification [2] discusses security requirements for the base MGCP protocol that apply equally to the package defined in this document. Use of a security Protocol such as IPsec (RFC 2401, RFC 2406) that provides per message authentication and integrity services is required to ensure that requests and responses are obtained from authenticated sources and that messages
基本MGCP规范[2]第5节讨论了基本MGCP协议的安全要求，这些要求同样适用于本文件中定义的包。需要使用诸如IPsec（RFC 2401、RFC 2406）之类的安全协议，该协议提供每条消息的身份验证和完整性服务，以确保从经过身份验证的源获得请求和响应，并确保消息
have not been modified. Without these services, gateways and Call Agents are open to attacks.
没有修改。如果没有这些服务，网关和呼叫代理就会受到攻击。
[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月。
Authors' Addresses
作者地址
Bill Foster
比尔·福斯特
Phone: +1 250 758 9418
EMail: bfoster@cisco.com
Phone: +1 250 758 9418
EMail: bfoster@cisco.com
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
弗莱明·安德里森思科系统公司，地址：新泽西州爱迪生市索纳尔街499号8楼，邮编：08837
EMail: fandreas@cisco.com
EMail: fandreas@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编辑功能的资金目前由互联网协会提供。