* 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", RFC1889,
January 1996.
* Schulzrinne, H., "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC1890, January 1996.
* Handley, M and V. Jacobson, "SDP: Session Description Protocol",
RFC2327, April 1998.
* Handley, M., "SAP - Session Announcement Protocol", Work in
Progress.
* Handley, M., Schulzrinne, H. and E. Schooler, "Session Initiation
Protocol (SIP)", RFC2543, March 1999.
* Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC2326, 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", RFC2401, November 1998.
* Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
* Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC2406, November 1998.
* Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, 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 RFCEditor function is currently provided by the
Internet Society.