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
* Aligned the handling of retransmission with the CableLabs NCS
* Added the provisional response return code and corresponding
* 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
* Propsed a "create two connections" command, as an appendix.
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
* Naming scheme for events, introducing a package structure inspired
* 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.
* 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
* 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
* 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.
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.
* Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
* 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.
* ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN
USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984;
modified at Helsinki, 1993)
* ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND
SIGNALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7",
(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,
* Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
* Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
11. Authors' Addresses
RSL COM Latin America
6300 N.W. 5th Way, Suite 100
Ft. Lauderdale, FL 33309
Phone: (954) 492-0913
1450 Infinite Drive
Louisville, CO 80027
Phone: (303)926 3123
1450 Infinite Drive
Louisville, CO 80027
Phone: (303)926 3123
445 South Street
Morristown, NJ 07960
Phone: +1 973-829-4266
1148 East Arques Ave
Sunnyvale, CA 94086
Phone: (408) 523-9700 extension 200
Further information is available on the SGCP web site:
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.
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
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
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
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.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the