One document matched: draft-andreasen-mgcp-moveconnection-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:43:43 |