Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 2705


Media Gateway Control Protocol (MGCP) Version 1.0

Part 5 of 5, p. 124 to 134
Prev RFC Part


prevText      Top      Up      ToC       Page 124 
7.  Versions and compatibility

7.1.  Differences between version 1.0 and draft 0.5

   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:

   *  Specified more clearly that the encoding of three
      LocalConnectionOptions parameters, Encoding Method, Packetization
      Period and Bandwidth, shall follow the conventions laid out in

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

   *  Corrected miscellaneous bugs in the formal syntax description.

   *  Aligned specification of commands with the CableLabs NCS
      specification.  This mostly affects the AuditEndpoint and

Top      Up      ToC       Page 125 
      RestartInProgress commands.

   *  Aligned the handling of retransmission with the 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.

7.2.  Differences between draft-04 and draft-05

   Differences are minor: corrected the copyright statement, and
   corrected a bug in the formal description.

7.3.  Differences between draft-03 and draft-04

   Draft 04 corrects a number of minor editing mistakes that were
   pointed out during the review of draft 03, issued on February 1.

7.4.  Differences between draft-02 and draft-03

   The main differences between draft-02, issued in January 22 1998, and
   draft 03 are:

   *  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

   *  Documented the extension procedure for the LocalConnectionOptions
      parameter and for the ConnectionParameters parameter,

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

   *  Expanded the security section to include a discussion of
      "uncontrolled barge-in."

   *  Propsed a "create two connections" command, as an appendix.

Top      Up      ToC       Page 126 
7.5.  Differences between draft-01 and draft-02

   The main differences between draft-01, issued in November 1998, and
   draft 02 are:

   *  Added an ABNF description of the protocol.

   *  Specification of an EndpointConfiguration command,

   *  Addition of a "two endpoints" mode in the create connection

   *  Modification of the package wildcards from "$/$" to "*/all" at the
      Request of early implementors,

   *  Revision of some package definitions to better align with external

   *  Addition of a specification for the handling of "failover."

   *  Revision of the section on race conditions.

7.6.  The making of MGCP from IPDC and SGCP

   MGCP version 0.1 results from the fusion of the SGCP and IPDC

7.7.  Changes between MGCP and initial versions of SGCP

   MGCP version 0.1 (which subsumes SGCP version 1.2) introduces the
   following changes from SGCP version 1.1:

   *  Protocol name changed to MGCP.

   *  Introduce a formal wildcarding structure in the name of endpoints,
      inspired from IPDC, and detailed the usage of wildcard names in
      each operation.

   *  Naming scheme for events, introducing a package structure inspired
      from IPDC.

   *  New operations for audit endpoint, audit connection (requested by
      the Cablelabs) and restart (inspired from IPDC).

   *  New parameter to control the behavior of the notification request.

   *  Improved text on the detection and handling of race conditions.

Top      Up      ToC       Page 127 
   *  Syntax modification for event reporting, to incorporate package

   *  Definition of basic event packages (inspired from IPDC).

   *  Incorporation of mandatory and optional extension parameters,
      inspired by IPDC.

   SGCP version 1.1 introduces the following changes from version SGCP

   *  Extension parameters (X-??:)

   *  Error Code 511 (Unrecognized extension).

   *  All event codes can be used in RequestEvent, SignalRequest and
      ObservedEvent parameters.

   *  Error Code 512 (Not equipped to detect requested event).

   *  Error Code 513 (Not equipped to generate requested signal).

   *  Error Code 514 (Unrecognized announcement).

   *  Specific Endpoint-ID can be returned in creation commands.

   *  Changed the code for the ASDI display from "ad" to "asdi" to avoid
      conflict with the digits A and D.

   *  Changed the code for the answer tone from "at" to "aw" to avoid
      conflict with the digit A and the timer mark T

   *  Changed the code for the busy tone from "bt" to "bz" to avoid
      conflict with the digit B and the timer mark T

   *  Specified that the continuity tone value is "co" (CT was
      incorrectly used in several instances; CT conflicts with .)

   *  Changed the code for the dial tone from "dt" to "dl" to avoid
      conflict with the digit D and the timer mark T

   *  Added a code point for announcement requests.

   *  Added a code point for the "wink" event.

   *  Set the "octet received" code in the "Connection Parameters" to
      "OR" (was set to RO, but then "OR" was used throughout all

Top      Up      ToC       Page 128 
   *  Added a "data" mode.

   *  Added a description of SDP parameters for the network access mode

   *  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

   *  Added event code "OC", operation completed.

   *  Added the specification of the "quarantine list", which clarifies
      the expected handling of events and notifications.

   *  Added the specification of a "wildcard delete" operation.

8.  Security Considerations

   Security issues are discussed in section 5.

9.  Acknowledgements

   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.

   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.

Top      Up      ToC       Page 129 
10.  References

   *  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
      A Transport Protocol for Real-Time Applications", RFC 1889,
      January 1996.

   *  Schulzrinne, H., "RTP Profile for Audio and Video Conferences with
      Minimal Control", RFC 1890, January 1996.

   *  Handley, M and V. Jacobson, "SDP: Session Description Protocol",
      RFC 2327, April 1998.

   *  Handley, M., "SAP - Session Announcement Protocol", Work in

   *  Handley, M., Schulzrinne, H. and E. Schooler, "Session Initiation
      Protocol (SIP)", RFC 2543, March 1999.

   *  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
      Protocol (RTSP)", RFC 2326, April 1998.

      USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984;
      modified at Helsinki, 1993)

   *  ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND
      (MalagaTorremolinos, 1984; modified at Helsinki, 1993)

   *  ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA

   *  ITU-T, Recommendation H.225, "Call Signaling Protocols and Media
      Stream Packetization for Packet Based Multimedia Communications

   *  ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR

   *  Kent, S. and  R. Atkinson, "Security Architecture for the Internet
      Protocol", RFC 2401, November 1998.

   *  Kent, S. and  R. Atkinson, "IP Authentication Header", RFC 2402,
      November 1998.

   *  Kent, S. and  R. Atkinson, "IP Encapsulating Security Payload
      (ESP)", RFC 2406, November 1998.

Top      Up      ToC       Page 130 
   *  Crocker, D. and  P. Overell, "Augmented BNF for Syntax
      Specifications:  ABNF", RFC 2234, November 1997.

11.  Authors' Addresses

   Mauricio Arango
   RSL COM Latin America
   6300 N.W. 5th Way, Suite 100
   Ft. Lauderdale, FL 33309

   Phone: (954) 492-0913

   Andrew Dugan
   Level3 Communications
   1450 Infinite Drive
   Louisville, CO 80027

   Phone: (303)926 3123

   Isaac Elliott
   Level3 Communications
   1450 Infinite Drive
   Louisville, CO 80027

   Phone: (303)926 3123

Top      Up      ToC       Page 131 
   Christian Huitema
   Telcordia Technologies
   MCC 1J236B
   445 South Street
   Morristown, NJ 07960

   Phone: +1 973-829-4266

   Scott Pickett
   Vertical Networks
   1148 East Arques Ave
   Sunnyvale, CA 94086

   Phone: (408) 523-9700 extension 200

   Further information is available on the SGCP web site:


Top      Up      ToC       Page 132 
12.  Appendix A: Proposed "MoveConnection" command

   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.

          <--- ModifyConnection(CallId,
                                [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.

   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.

   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

   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

Top      Up      ToC       Page 133 
   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.

   The LocalConnectionOptions, Mode, and RemoteConnectionDescriptor,
   when present, are applied after the move.

   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.

   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.

   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.

   The encapsulated EndpointConfiguration command shares the fate of the
   MoveConnection command.  If the MoveConnection is rejected, the End-
   pointConfiguration is not executed.

12.1.  Proposed syntax modification

   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.

Top      Up      ToC       Page 134 
13.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.