RFC 2705
Media Gateway Control Protocol (MGCP) Version 1.0
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 SDP. * 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
RestartInProgress commands.
* Aligned the handling of retransmission with the CableLabs NCS
specification.
* 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
names,
* 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.
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 command, * Modification of the package wildcards from "$/$" to "*/all" at the Request of early implementors, * Revision of some package definitions to better align with external specifications. * 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 proposals.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.
* Syntax modification for event reporting, to incorporate package
names.
* 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
1.0:
* 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
examples.)
* Added a "data" mode.
* Added a description of SDP parameters for the network access mode
(NAS).
* 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
test.
* 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.
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 Progress. * 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 COMMUNICATIONS SYSTEMS." * ITU-T, Recommendation H.225, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems." * ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MULTIMEDIA COMMUNICATION." * 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.
* 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
EMail: marango@rslcom.com
Andrew Dugan
Level3 Communications
1450 Infinite Drive
Louisville, CO 80027
Phone: (303)926 3123
EMail: andrew.dugan@l3.com
Isaac Elliott
Level3 Communications
1450 Infinite Drive
Louisville, CO 80027
Phone: (303)926 3123
EMail: ike.elliott@l3.com
Christian Huitema
Telcordia Technologies
MCC 1J236B
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 973-829-4266
EMail: huitema@research.telcordia.com
Scott Pickett
Vertical Networks
1148 East Arques Ave
Sunnyvale, CA 94086
Phone: (408) 523-9700 extension 200
EMail: ScottP@vertical.com
Further information is available on the SGCP web site:
http://www.argreenhouse.com/SGCP/
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. [SecondEndPointId,] [ConnectionId,] [LocalConnectionDescriptor] <--- ModifyConnection(CallId, EndpointId, ConnectionId, SecondEndPointId, [NotifiedEntity,] [LocalConnectionOptions,] [Mode,] [RemoteConnectionDescriptor,] [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 parameter. 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 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.
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 English. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.