Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
RFC 3992

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

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).

IESG Note

   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.

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.

1.  Introduction

   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.

Foster & Andreasen           Informational                      [Page 1]
RFC 3992        MGCP Lockstep State Reporting Mechanism    February 2005

   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.

   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.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

2.  Lockstep Package

   Package Name: LCK
   Version: 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.

      *  The reporting mechanism itself, which is done with a new
         "lockstep" RestartMethod for the RSIP command as described in
         section 2.2.

2.1.  Request to Report Lockstep State

   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:" 0*WSP LSTIME

      LSTIME = 1*(4DIGIT)

Foster & Andreasen           Informational                      [Page 2]
RFC 3992        MGCP Lockstep State Reporting Mechanism    February 2005

   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 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