tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

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

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

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

Top      Up      ToC       Page 127 
   *  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.)

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

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

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

Top      Up      ToC       Page 131 
   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/

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.

         [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

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