Internet Engineering Task Force F. Andreasen Internet Draft B. Foster Document: draft-andreasen-mgcp-moveconnection-00.txt Cisco Systems Category: Informational October 2002 Media Gateway Control Protocol (MGCP) MoveConnection Package Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document defines a Media Gateway Control Protocol (MGCP) package containing the MoveConnection command which was originally proposed in RFC 2705 [4]. The MoveConnection command can move an MGCP connection from one endpoint in a media gateway to another endpoint in the same gateway. This can be very useful in order to support redirection of media streams across endpoints in a media gateway. 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Andreasen, Foster Informational - Expires April 2003 [Page 1] Internet Draft MGCP MoveConnection Package October 2003 2. Introduction The base MGCP specification [3] defines three commands for operating on connections: * CreateConnection, which allows a connection to be created on an endpoint, * ModifyConnection, which allows the media parameters of a connection to be modified, and * DeleteConnection, which allows a connection to be deleted. The base MGCP protocol however does not define a way for a connection to be moved from one endpoint to another. Instead, a new connection would have to be created and the old one deleted. Such operation however would most likely not be transparent to the peer on a connection. In order to address this, RFC 2705 defined a proposed MoveConnection command, however it was not an integral part of the protocol, and hence it was not included in the updated MGCP specification [3] either. Although MGCP packages are not supposed to define new verbs, an exception is made in this case in order to add important functionality to the protocol. In this document, we define a MoveConnection package, which contains the MoveConnection command. The MoveConnection command can move an MGCP connection from one endpoint in a media gateway to another endpoint in the same gateway. This can be very useful in order to support redirection of media streams across endpoints in a media gateway. 3. Package Definition Package Name: MOVE Package Version: 0 This package defines a new MGCP command, that moves an existing connection from one endpoint to another in the same media gateway. This command is useful for handling certain call services, such as call forwarding between endpoints served by the same gateway, or redirection between endpoints on different gateways by using a virtual endpoint in the original media gateway as a relay function. Andreasen, Foster Informational - Expires April 2003 [Page 2] Internet Draft MGCP MoveConnection Package October 2003 ReturnCode, [SpecificEndPointId,] [ConnectionId,] [LocalConnectionDescriptor] <--- MoveConnection(CallId, EndpointId, ConnectionId, SecondEndPointId, [Transparent,] [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 MUST be the fully qualified endpoint identifier of the endpoint on which the connection has been created. The local name part MUST NOT use the wildcard conventions. The SecondEndpointId MUST be the endpoint identifier of the endpoint towards which the connection is to be moved. The "any of" wildcard convention can be used, but not the "all of" convention. If the SecondEndpointId parameter includes the "any of" wildcard, the endpoint identifier SHALL be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response. When the "any of" wildcard is used, the endpoint assigned MUST be in-service and MUST NOT already have any connections on it. If no such endpoint is available, error code 410 (no endpoint available) SHOULD be returned. 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 in the ConnectionId 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 restrict specific IP addresses to be associated with specific boards that handle a specific group of endpoints. If for any reason the transmission parameters have to be changed as a result of the move, the outcome of the command depends on the boolean parameter Andreasen, Foster Informational - Expires April 2003 [Page 3] Internet Draft MGCP MoveConnection Package October 2003 Transparent. If the Transparent parameter is set to "no" (which is the default value), a new LocalConnectionDescriptor is returned as a response parameter. If the Transparent parameter is set to "yes", the command will fail with error code 502 (insufficient resources) if it cannot be performed transparently. The LocalConnectionOptions, Mode, and RemoteConnectionDescriptor, when present, are applied after the move. The NotifiedEntity parameter, if present, applies to the second endpoint. The Encapsulated NotificationRequest is optional. It can be used by the Call Agent to transmit a NotificationRequest that is executed simultaneously with the move of the connection. When the Encapsulated NotificationRequest is present, it is applied to the second endpoint. When the Encapsulated NotificationRequest is present, the move and the NotificationRequests MUST be synchronized, which means that both must be accepted, or both refused. The command may carry an Encapsulated EndpointConfiguration command, which will also apply to the second endpoint. The EndpointConfiguration 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 EndpointConfiguration is not executed. 3.1 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 in [3]. Furthermore, the Transparent parameter is a package specific ParameterValue defined by the following ABNF: Transparent = "MOVE" "/" "TRP" ":" 0*(WSP) ("yes" / "no") 4. Examples The following example illustrates the MoveConnection command: MOVE 1209 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 Z2: aaln/2@rgw-2567.whatever.net MOVE/TRP: yes The response indicates that the transaction was successful: Andreasen, Foster Informational - Expires April 2003 [Page 4] Internet Draft MGCP MoveConnection Package October 2003 200 1209 OK Note that a new connection identifier could have been returned as well. In the example below, we do not request transparent operation: MOVE 1210 aaln/2@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 Z2: aaln/3@rgw-2567.whatever.net In this case the response indicates that the move was not transparent, since a LocalConnectionDescriptor is returned. In this example, we also get a new connection identifier assigned: 200 1210 OK I: DFE233D1 v=0 o=- 4723891 7428910 IN IP4 128.96.63.25 s=- c=IN IP4 128.96.63.25 t=0 0 m=audio 3456 RTP/AVP 0 5. Changes from RFC 2705 The MoveConnection command was originally defined as a proposed MGCP extension in Appendix A of RFC 2705 [4]. The changes from the original RFC 2705 text are described below: * Added a new "Transparent" parameter to control whether a MoveConnection that will not be transparent to a peer endpoint should fail or succeed. * Added an Example Section. * Various editorial changes and clarifications. 6. Acknowledgements The MoveConnection command was originally proposed in RFC 2705, and hence credit for it belongs to the original MGCP authors: Mauricio Arango, Andrew Dugan, Isaac Elliott, Christian Huitema, and Scott Picket. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Andreasen, Foster Informational - Expires April 2003 [Page 5] Internet Draft MGCP MoveConnection Package October 2003 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Andreasen, F., and Foster, B., "Media Gateway Control Protocol 1.0", draft-andreasen-mgcp-rfc2705bis-05.txt, May 2002. [4] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S., Andreasen, F., Foster, B. and Kumar, R., "Media Gateway Control Protocol 1.0", RFC 2705. Andreasen, Foster Informational - Expires April 2003 [Page 6] Internet Draft MGCP MoveConnection Package October 2003 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Andreasen, Foster Informational - Expires April 2003 [Page 7] Internet Draft MGCP MoveConnection Package October 2003 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Andreasen, Foster Informational - Expires April 2003 [Page 8]