RFC 3992

Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism 🎀

• RFC number: 3992
• Authors: Bill Foster and Flemming Andreasen, both at Cisco Systems 💅
• Category: Informational
• Date: February 2005
• Obsoletes/Updates: the title block doesn't list any ✨

---

Status of This Memo 📋

okay so this memo is just here to share info with the Internet community 🌸 it is NOT a standard of any kind, so don't go treating it like one. anyone can read it, and it can be shared freely (distribution is unlimited) 🦋

Copyright Notice ©️

Copyright (C) The Internet Society (2005). 💜

IESG Note 📢

bestie, this one is a little plot twist 😭 this doc is being published for info only. it describes a non-IETF protocol that's already getting deployed in a bunch of products. implementers should be aware of RFC 3015, which came out of the IETF Megaco Working Group and the ITU-T SG16. that's the standards-based way (with reviewed security considerations!) to meet the same needs MGCP was built for, according to the IETF and the ITU-T. so yeah, go look at RFC 3015 🔥

Abstract 🧚

so picture this: an MGCP endpoint hits a nasty failure, like being in the middle of a transient call when the Call Agent fails over. it can get stuck in a lockstep state where events get quarantined and nobody gets notified 💀 this doc gives the new Call Agent a way to find out about these situations so it can run the right fault recovery procedures 🫶

1. Introduction 🌈

okay so in the Media Gateway Control Protocol (MGCP) [2], an endpoint working in "step" mode sends a Notify and then enters the notification state, where it waits for a response to that Notify. the endpoint must wait for a brand new NotificationRequest before it can resume event processing ⏳ while it's stuck waiting for that NotificationRequest, we call it being in the lockstep state 🔒

being in lockstep means no event processing, which also means no new Notify. endpoints should only be in lockstep for a super short time 🙈 but in rough conditions, an endpoint could end up stuck in lockstep and the Call Agent wouldn't even realise it. ngl that could be really bad for the service 😭

the Lockstep package in this doc adds extensions to the EndpointConfiguration and RestartInProgress commands. with those, a Call Agent can ask an endpoint to tell it when the endpoint has been in lockstep 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 🦋

this package is the lockstep reporting bit 💅 here are the details:

• Package Name: LCK
• Version: 0

Package Description: the whole point of this package is to give a way to report when an endpoint has been in the "lockstep state" for a specified period of time ✨

there are two sides to this package:

• the Call Agent can ask endpoints to report if they're in lockstep for a specified period. that happens with the EndpointConfiguration command, which we cover in section 2.1.
• the reporting itself happens through a new "lockstep" RestartMethod for the RSIP command, covered in section 2.2.

2.1. Request to Report Lockstep State 💌

the new LCK/LST EndpointConfiguration parameter is how the Call Agent asks for "lockstep" state to be reported. the syntax is:

"LCK/LST:" 0*WSP LSTIME

LSTIME = 1*(4DIGIT)

LSTIME is in seconds, and it can go from 0 to 9999 🔢 a value greater than 2*T-HIST (see [2]) is RECOMMENDED, so that's the move 🍓

LSTIME is how long the endpoint sits in lockstep before it reports. the timer starts when the endpoint enters lockstep and gets canceled if the endpoint leaves lockstep before it times out ⏱️ the value you give stays in effect until someone explicitly changes it (or a restart happens) 🫶

if the endpoint is already in lockstep when a non-zero timer value comes in, the lockstep timer just starts with that value, and any existing lockstep timer gets canceled 🧚 and the value zero turns reporting off 🙅‍♀️

you can audit this parameter with the AuditEndpoint command. it returns the last configured value, or zero if nothing was ever configured 👀

2.2. Lockstep Restart Method 🔁

there's a new "lockstep" restart method in the "LCK" package 🔥 an RSIP (RestartInProgress) gets sent with this RestartMethod if the endpoint has been set to a non-zero LSTIME and that timer has expired ⏰

quick note: once the lockstep timer's been set, it can fire only once per Notify command. BUT you can set the timer more than once while the endpoint is in lockstep (which rearms it for that particular Notify) 🌀 the syntax of the restart method follows [2]:

"RM" ":" 0*(WSP) "LCK/lockstep"

RestartDelay (see [2]) is not used with the "lockstep" RestartMethod 🙅‍♀️ also, the "lockstep" RestartMethod doesn't define a service-state, so it'll never be returned when you audit the RestartMethod 💀

3. IANA Considerations 📚

the MGCP package titled "Lockstep" with the name "LCK" and version number zero has been registered with IANA, as shown in Appendix C.1 in [2] 🎀

4. Security Considerations 🔐

bestie, this part is SERIOUS 😭🚨

section 5 of the base MGCP specification [2] covers the security requirements for base MGCP, and those requirements apply just as much to the package in this doc 💜 a security Protocol like IPsec (RFC 2401, RFC 2406) is required to make sure requests and responses come from authenticated sources and that messages haven't been modified in transit. it has to give per message authentication and integrity services. without those, gateways and Call Agents are wide open to attacks 💀🔥 do not skip this, literally.

5. Normative References 📖

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.

Authors' Addresses 💌

Bill Foster

Phone: +1 250 758 9418
EMail: bfoster@cisco.com


Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th Floor
Edison, NJ 08837

EMail: fandreas@cisco.com

Full Copyright Statement ©️

Copyright (C) The Internet Society (2005).

this document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org. except as set forth therein, the authors keep all their rights 🫶

this document and the information in it are provided on an "AS IS" basis. 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights might be available. it also doesn't say it has independently tried to find any such rights. info on ISOC's procedures for rights in ISOC Documents is in BCP 78 and BCP 79 📚

copies of IPR disclosures sent to the IETF Secretariat, assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗

the IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society 💖