idnits 2.17.1 draft-andreasen-mgcp-moveconnection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7864 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'LocalConnectionDescriptor' on line 92 ** Obsolete normative reference: RFC 2705 (ref. '4') (Obsoleted by RFC 3435) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Andreasen 3 Internet Draft B. Foster 4 Document: draft-andreasen-mgcp-moveconnection-00.txt Cisco Systems 5 Category: Informational October 2002 7 Media Gateway Control Protocol (MGCP) 8 MoveConnection Package 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 For potential updates to the above required-text see: 30 http://www.ietf.org/ietf/1id-guidelines.txt 32 Abstract 34 This document defines a Media Gateway Control Protocol (MGCP) 35 package containing the MoveConnection command which was originally 36 proposed in RFC 2705 [4]. The MoveConnection command can move an 37 MGCP connection from one endpoint in a media gateway to another 38 endpoint in the same gateway. This can be very useful in order to 39 support redirection of media streams across endpoints in a media 40 gateway. 42 1. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED, "MAY", and 46 "OPTIONAL" in this document are to be interpreted as described in 47 RFC-2119 [2]. 49 2. Introduction 51 The base MGCP specification [3] defines three commands for operating 52 on connections: 53 * CreateConnection, which allows a connection to be created on an 54 endpoint, 55 * ModifyConnection, which allows the media parameters of a 56 connection to be modified, and 57 * DeleteConnection, which allows a connection to be deleted. 59 The base MGCP protocol however does not define a way for a 60 connection to be moved from one endpoint to another. Instead, a new 61 connection would have to be created and the old one deleted. Such 62 operation however would most likely not be transparent to the peer 63 on a connection. In order to address this, RFC 2705 defined a 64 proposed MoveConnection command, however it was not an integral part 65 of the protocol, and hence it was not included in the updated MGCP 66 specification [3] either. 68 Although MGCP packages are not supposed to define new verbs, an 69 exception is made in this case in order to add important 70 functionality to the protocol. In this document, we define a 71 MoveConnection package, which contains the MoveConnection command. 72 The MoveConnection command can move an MGCP connection from one 73 endpoint in a media gateway to another endpoint in the same gateway. 74 This can be very useful in order to support redirection of media 75 streams across endpoints in a media gateway. 77 3. Package Definition 79 Package Name: MOVE 80 Package Version: 0 82 This package defines a new MGCP command, that moves an existing 83 connection from one endpoint to another in the same media gateway. 84 This command is useful for handling certain call services, such as 85 call forwarding between endpoints served by the same gateway, or 86 redirection between endpoints on different gateways by using a 87 virtual endpoint in the original media gateway as a relay function. 89 ReturnCode, 90 [SpecificEndPointId,] 91 [ConnectionId,] 92 [LocalConnectionDescriptor] 93 <--- MoveConnection(CallId, 94 EndpointId, 95 ConnectionId, 96 SecondEndPointId, 97 [Transparent,] 98 [NotifiedEntity,] 99 [LocalConnectionOptions,] 100 [Mode,] 101 [RemoteConnectionDescriptor,] 102 [Encapsulated NotificationRequest,] 103 [Encapsulated EndpointConfiguration]) 105 The parameters used are the same as in the ModifyConnection command, 106 with the addition of a SecondEndpointId that identifies the endpoint 107 towards which the connection is moved. 109 The EndpointId MUST be the fully qualified endpoint identifier of 110 the endpoint on which the connection has been created. The local 111 name part MUST NOT use the wildcard conventions. 113 The SecondEndpointId MUST be the endpoint identifier of the endpoint 114 towards which the connection is to be moved. The "any of" wildcard 115 convention can be used, but not the "all of" convention. If the 116 SecondEndpointId parameter includes the "any of" wildcard, the 117 endpoint identifier SHALL be assigned by the gateway and its 118 complete value returned in the SpecificEndPointId parameter of the 119 response. When the "any of" wildcard is used, the endpoint assigned 120 MUST be in-service and MUST NOT already have any connections on it. 121 If no such endpoint is available, error code 410 (no endpoint 122 available) SHOULD be returned. 124 The command will result in the "move" of the existing connection to 125 the second endpoint. Depending on gateway implementations, the 126 connection identifier of the connection after the move may or may 127 not be the same as the connection identifier before the move. If it 128 is not the same, the new value is returned in the ConnectionId 129 response parameter. 131 The intent of the command is to effect a local relocation of the 132 connection without having to modify such transmission parameters as 133 IP addresses and port and thus without forcing the call agent to 134 signal the change of parameters to the remote gateway at the other 135 end of the connection. However, gateway architectures may not always 136 allow such transparent moves. For example, some architectures could 137 restrict specific IP addresses to be associated with specific boards 138 that handle a specific group of endpoints. If for any reason the 139 transmission parameters have to be changed as a result of the move, 140 the outcome of the command depends on the boolean parameter 141 Transparent. If the Transparent parameter is set to "no" (which is 142 the default value), a new LocalConnectionDescriptor is returned as a 143 response parameter. If the Transparent parameter is set to "yes", 144 the command will fail with error code 502 (insufficient resources) 145 if it cannot be performed transparently. 147 The LocalConnectionOptions, Mode, and RemoteConnectionDescriptor, 148 when present, are applied after the move. 150 The NotifiedEntity parameter, if present, applies to the second 151 endpoint. 153 The Encapsulated NotificationRequest is optional. It can be used by 154 the Call Agent to transmit a NotificationRequest that is executed 155 simultaneously with the move of the connection. When the 156 Encapsulated NotificationRequest is present, it is applied to the 157 second endpoint. When the Encapsulated NotificationRequest is 158 present, the move and the NotificationRequests MUST be synchronized, 159 which means that both must be accepted, or both refused. 161 The command may carry an Encapsulated EndpointConfiguration command, 162 which will also apply to the second endpoint. The 163 EndpointConfiguration command may be encapsulated together with an 164 encapsulated NotificationRequest command. 166 The encapsulated EndpointConfiguration command shares the fate of 167 the MoveConnection command. If the MoveConnection is rejected, the 168 EndpointConfiguration is not executed. 170 3.1 Syntax Modification 172 The only syntax modification necessary for the addition of the 173 MoveConnection command is the addition of the keyword "MOVE" to the 174 authorized values in the MGCPVerb clause of the formal syntax in 175 [3]. 177 Furthermore, the Transparent parameter is a package specific 178 ParameterValue defined by the following ABNF: 180 Transparent = "MOVE" "/" "TRP" ":" 0*(WSP) ("yes" / "no") 182 4. Examples 184 The following example illustrates the MoveConnection command: 186 MOVE 1209 aaln/1@rgw-2567.whatever.net MGCP 1.0 187 C: A3C47F21456789F0 188 I: FDE234C8 189 Z2: aaln/2@rgw-2567.whatever.net 190 MOVE/TRP: yes 192 The response indicates that the transaction was successful: 194 200 1209 OK 196 Note that a new connection identifier could have been returned as 197 well. 199 In the example below, we do not request transparent operation: 201 MOVE 1210 aaln/2@rgw-2567.whatever.net MGCP 1.0 202 C: A3C47F21456789F0 203 I: FDE234C8 204 Z2: aaln/3@rgw-2567.whatever.net 206 In this case the response indicates that the move was not 207 transparent, since a LocalConnectionDescriptor is returned. In this 208 example, we also get a new connection identifier assigned: 210 200 1210 OK 211 I: DFE233D1 213 v=0 214 o=- 4723891 7428910 IN IP4 128.96.63.25 215 s=- 216 c=IN IP4 128.96.63.25 217 t=0 0 218 m=audio 3456 RTP/AVP 0 220 5. Changes from RFC 2705 222 The MoveConnection command was originally defined as a proposed MGCP 223 extension in Appendix A of RFC 2705 [4]. The changes from the 224 original RFC 2705 text are described below: 226 * Added a new "Transparent" parameter to control whether a 227 MoveConnection that will not be transparent to a peer endpoint 228 should fail or succeed. 230 * Added an Example Section. 232 * Various editorial changes and clarifications. 234 6. Acknowledgements 236 The MoveConnection command was originally proposed in RFC 2705, and 237 hence credit for it belongs to the original MGCP authors: Mauricio 238 Arango, Andrew Dugan, Isaac Elliott, Christian Huitema, and Scott 239 Picket. 241 7. References 243 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 244 BCP 9, RFC 2026, October 1996. 246 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 247 Levels", BCP 14, RFC 2119, March 1997. 249 [3] Andreasen, F., and Foster, B., "Media Gateway Control Protocol 250 1.0", draft-andreasen-mgcp-rfc2705bis-05.txt, May 2002. 252 [4] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S., 253 Andreasen, F., Foster, B. and Kumar, R., "Media Gateway Control 254 Protocol 1.0", RFC 2705. 256 Full Copyright Statement 258 Copyright (C) The Internet Society (2002). All Rights Reserved. 260 This document and translations of it may be copied and furnished to 261 others, and derivative works that comment on or otherwise explain it 262 or assist in its implementation may be prepared, copied, published 263 and distributed, in whole or in part, without restriction of any 264 kind, provided that the above copyright notice and this paragraph 265 are included on all such copies and derivative works. However, this 266 document itself may not be modified in any way, such as by removing 267 the copyright notice or references to the Internet Society or other 268 Internet organizations, except as needed for the purpose of 269 developing Internet standards in which case the procedures for 270 copyrights defined in the Internet Standards process must be 271 followed, or as required to translate it into languages other than 272 English. 274 The limited permissions granted above are perpetual and will not be 275 revoked by the Internet Society or its successors or assigns. 277 This document and the information contained herein is provided on an 278 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 279 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 280 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 281 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 282 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Acknowledgement 286 Funding for the RFC Editor function is currently provided by the 287 Internet Society.