diff --git a/examples/rfc3525.txt b/examples/rfc3525.txt
new file mode 100644
index 0000000..80663cc
--- /dev/null
+++ b/examples/rfc3525.txt
@@ -0,0 +1,11931 @@
+
+
+
+
+
+
+Network Working Group                                          C. Groves
+Request for Comments: 3525                                   M. Pantaleo
+Obsoletes: 3015                                              LM Ericsson
+Category: Standards Track                                    T. Anderson
+                                                              Consultant
+                                                               T. Taylor
+                                                         Nortel Networks
+                                                                 Editors
+                                                               June 2003
+
+
+                  Gateway Control Protocol Version 1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines the protocol used between elements of a
+   physically decomposed multimedia gateway, i.e., a Media Gateway and a
+   Media Gateway Controller.  The protocol presented in this document
+   meets the requirements for a media gateway control protocol as
+   presented in RFC 2805.
+
+   This document replaces RFC 3015.  It is the result of continued
+   cooperation between the IETF Megaco Working Group and ITU-T Study
+   Group 16.  It incorporates the original text of RFC 3015, modified by
+   corrections and clarifications discussed on the Megaco
+   E-mail list and incorporated into the Study Group 16 Implementor's
+   Guide for Recommendation H.248.  The present version of this document
+   underwent  ITU-T Last Call as Recommendation H.248 Amendment 1.
+   Because of ITU-T renumbering, it was published by the ITU-T as
+   Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.
+
+   Users of this specification are advised to consult the H.248 Sub-
+   series Implementors' Guide at http://www.itu.int/itudoc/itu-
+   t/com16/implgd for additional corrections and clarifications.
+
+
+
+
+
+Groves, et al.              Standards Track                     [Page 1]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Table of Contents
+
+   1 Scope.........................................................5
+     1.1 Changes From RFC 3015.....................................5
+     1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)...5
+   2 References....................................................6
+     2.1 Normative references......................................6
+     2.2 Informative references....................................9
+   3 Definitions..................................................10
+   4 Abbreviations................................................11
+   5 Conventions..................................................12
+   6 Connection model.............................................13
+     6.1 Contexts.................................................16
+     6.2 Terminations.............................................17
+       6.2.1 Termination dynamics.................................21
+       6.2.2 TerminationIDs.......................................21
+       6.2.3 Packages.............................................22
+       6.2.4 Termination properties and descriptors...............23
+       6.2.5 Root Termination.....................................25
+   7 Commands.....................................................26
+     7.1 Descriptors..............................................27
+       7.1.1 Specifying parameters................................27
+       7.1.2 Modem descriptor.....................................28
+       7.1.3 Multiplex descriptor.................................28
+       7.1.4 Media descriptor.....................................29
+       7.1.5 TerminationState descriptor..........................29
+       7.1.6 Stream descriptor....................................30
+       7.1.7 LocalControl descriptor..............................31
+       7.1.8 Local and Remote descriptors.........................32
+       7.1.9 Events descriptor....................................35
+       7.1.10 EventBuffer descriptor..............................38
+       7.1.11 Signals descriptor..................................38
+       7.1.12 Audit descriptor....................................40
+       7.1.13 ServiceChange descriptor............................41
+       7.1.14 DigitMap descriptor.................................41
+       7.1.15 Statistics descriptor...............................46
+       7.1.16 Packages descriptor.................................47
+       7.1.17 ObservedEvents descriptor...........................47
+       7.1.18 Topology descriptor.................................47
+       7.1.19 Error Descriptor....................................50
+     7.2 Command Application Programming Interface................50
+       7.2.1 Add..................................................51
+
+
+
+Groves, et al.              Standards Track                     [Page 2]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+       7.2.2 Modify...............................................52
+       7.2.3 Subtract.............................................53
+       7.2.4 Move.................................................55
+       7.2.5 AuditValue...........................................56
+       7.2.6 AuditCapabilities....................................59
+       7.2.7 Notify...............................................60
+       7.2.8 ServiceChange........................................61
+       7.2.9 Manipulating and Auditing Context Attributes.........65
+       7.2.10 Generic Command Syntax..............................66
+     7.3 Command Error Codes......................................66
+   8 Transactions.................................................66
+     8.1 Common parameters........................................68
+       8.1.1 Transaction Identifiers..............................68
+       8.1.2 Context Identifiers..................................68
+     8.2 Transaction Application Programming Interface............69
+       8.2.1 TransactionRequest...................................69
+       8.2.2 TransactionReply.....................................69
+       8.2.3 TransactionPending...................................71
+     8.3 Messages.................................................72
+   9 Transport....................................................72
+     9.1 Ordering of Commands.....................................73
+     9.2 Protection against Restart Avalanche.....................74
+   10 Security Considerations.....................................75
+     10.1 Protection of Protocol Connections......................75
+     10.2 Interim AH scheme.......................................76
+     10.3 Protection of Media Connections.........................77
+   11 MG-MGC Control Interface....................................78
+     11.1 Multiple Virtual MGs....................................78
+     11.2 Cold start..............................................79
+     11.3 Negotiation of protocol version.........................79
+     11.4 Failure of a MG.........................................80
+     11.5 Failure of an MGC.......................................81
+   12 Package definition..........................................82
+     12.1 Guidelines for defining packages........................82
+       12.1.1 Package.............................................83
+       12.1.2 Properties..........................................84
+       12.1.3 Events..............................................85
+       12.1.4 Signals.............................................85
+       12.1.5 Statistics..........................................86
+       12.1.6 Procedures..........................................86
+     12.2 Guidelines to defining Parameters to Events and Signals.86
+     12.3 Lists...................................................87
+     12.4 Identifiers.............................................87
+     12.5 Package registration....................................88
+   13 IANA Considerations.........................................88
+     13.1 Packages................................................88
+     13.2 Error codes.............................................89
+     13.3 ServiceChange reasons...................................89
+
+
+
+Groves, et al.              Standards Track                     [Page 3]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   ANNEX A  Binary encoding of the protocol.......................90
+     A.1 Coding of wildcards......................................90
+     A.2 ASN.1 syntax specification...............................92
+     A.3 Digit maps and path names...............................111
+   ANNEX B Text encoding of the protocol.........................113
+     B.1 Coding of wildcards.....................................113
+     B.2 ABNF specification......................................113
+     B.3 Hexadecimal octet coding................................127
+     B.4 Hexadecimal octet sequence..............................127
+   ANNEX C Tags for media stream properties......................128
+     C.1 General media attributes................................128
+     C.2 Mux properties..........................................130
+     C.3 General bearer properties...............................130
+     C.4 General ATM properties..................................130
+     C.5 Frame Relay.............................................134
+     C.6 IP......................................................134
+     C.7 ATM AAL2................................................134
+     C.8 ATM AAL1................................................136
+     C.9 Bearer capabilities.....................................137
+     C.10 AAL5 properties........................................147
+     C.11 SDP equivalents........................................148
+     C.12 H.245..................................................149
+   ANNEX D Transport over IP.....................................150
+     D.1 Transport over IP/UDP using Application Level Framing ..150
+       D.1.1 Providing At-Most-Once functionality................150
+       D.1.2 Transaction identifiers and three-way handshake.....151
+       D.1.3 Computing retransmission timers.....................152
+       D.1.4 Provisional responses...............................153
+       D.1.5 Repeating Requests, Responses and Acknowledgements..153
+     D.2 Using TCP...............................................155
+       D.2.1 Providing the At-Most-Once functionality............155
+       D.2.2 Transaction identifiers and three-way handshake.....155
+       D.2.3 Computing retransmission timers.....................156
+       D.2.4 Provisional responses...............................156
+       D.2.5 Ordering of commands................................156
+   ANNEX E  Basic packages.......................................157
+     E.1 Generic.................................................157
+     E.2 Base Root Package.......................................159
+     E.3 Tone Generator Package..................................161
+     E.4 Tone Detection Package..................................163
+     E.5 Basic DTMF Generator Package............................166
+     E.6 DTMF detection Package..................................167
+     E.7 Call Progress Tones Generator Package...................169
+     E.8 Call Progress Tones Detection Package...................171
+     E.9 Analog Line Supervision Package.........................172
+     E.10 Basic Continuity Package...............................175
+     E.11 Network Package........................................178
+     E.12 RTP Package............................................180
+
+
+
+Groves, et al.              Standards Track                     [Page 4]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+     E.13 TDM Circuit Package....................................182
+   APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE)...................184
+     A.1 Residential Gateway to Residential Gateway Call.........184
+       A.1.1 Programming Residential GW Analog Line Terminations
+             for Idle Behavior...................................184
+       A.1.2 Collecting Originator Digits and Initiating
+             Termination.........................................186
+   APPENDIX II  Changes From RFC 3015............................195
+   Intellectual Property Rights..................................210
+   Acknowledgments...............................................211
+   Authors' Addresses............................................212
+   Full Copyright Statement......................................213
+
+1  Scope
+
+   The present document, which is identical to the published version of
+   ITU-T Recommendation H.248.1 (03/2002) except as noted below, defines
+   the protocols used between elements of a physically decomposed
+   multimedia gateway.  There are no functional differences from a
+   system view between a decomposed gateway, with distributed sub-
+   components potentially on more than one physical device, and a
+   monolithic gateway such as described in ITU-T Recommendation H.246.
+   This document does not define how gateways, multipoint control units
+   or interactive voice response units (IVRs) work.  Instead it creates
+   a general framework that is suitable for these applications.
+
+   Packet network interfaces may include IP, ATM or possibly others.
+   The interfaces will support a variety of Switched Circuit Network
+   (SCN) signalling systems, including tone signalling, ISDN, ISUP, QSIG
+   and GSM.  National variants of these signalling systems will be
+   supported where applicable.
+
+1.1 Changes From RFC 3015
+
+   The differences between this document and RFC 3015 are documented in
+   Appendix II.
+
+1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)
+
+   This document differs from the corresponding ITU-T publication in the
+   following respects:
+
+   -  Added IETF front matter in place of the corresponding ITU-T
+      material.
+
+   -  The ITU-T summary is too H.323-specific and has been omitted.
+
+
+
+
+
+Groves, et al.              Standards Track                     [Page 5]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  The IETF conventions have been stated as governing this document.
+      As discussed in section 5 below, this gives slightly greater
+      strength to "should" requirements.
+
+   -  The Scope section (just above) has been edited slightly to suit
+      its IETF context.
+
+   -  Added normative references to RFCs 2026 and 2119.
+
+   -  Figures 4, 5, and 6 show the centre of the context for greater
+      clarity.  Also added Figure 6a showing an important additional
+      example.
+
+   -  Added a paragraph in section 7.1.18 which was approved in the
+      Implementor's Guide but lost inadvertently in the ITU-T approved
+      version.
+
+   -  This document incorporates corrections to the informative examples
+      in Appendix I which also appear in H.248.1 version 2, but which
+      were not picked up in H.248.1 (03/2002).
+
+   -  This document includes a new Appendix II listing all the changes
+      from RFC 3015.
+
+   -  This document includes an Acknowledgements section listing the
+      authors of RFC 3015 but also many other people who contributed to
+      the development of the Megaco/H.248.x protocol.
+
+   -  Moved the Intellectual Property declaration to its usual place in
+      an IETF document and added a reference to declarations on the IETF
+      web site.
+
+2  References
+
+   The following ITU-T Recommendations and other references contain
+   provisions which, through reference in this text, constitute
+   provisions of this RFC.  At the time of publication, the editions
+   indicated were valid.  All Recommendations and other references are
+   subject to revision; all users of this RFC are therefore encouraged
+   to investigate the possibility of applying the most recent edition of
+   the Recommendations and other references listed below.  A list of the
+   currently valid ITU-T Recommendations is regularly published.
+
+2.1   Normative references
+
+   -  ITU-T Recommendation H.225.0 (1999), Call signalling protocols and
+      media stream packetization for packet-based multimedia
+      communication systems.
+
+
+
+Groves, et al.              Standards Track                     [Page 6]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  ITU-T Recommendation H.235 (1998), Security and encryption for
+      H-Series (H.323 and other H.245-based) multimedia terminals.
+
+   -  ITU-T Recommendation H.245 (1998), Control protocol for multimedia
+      communication.
+
+   -  ITU-T Recommendation H.246 (1998), Interworking of H-series
+      multimedia terminals with H-series multimedia terminals and
+      voice/voiceband terminals on GSTN and ISDN.
+
+   -  ITU-T Recommendation H.248.8 (2002), H.248 Error Codes and Service
+      Change Reasons.
+
+   -  ITU-T Recommendation H.323 (1999), Packet-based multimedia
+      communication systems.
+
+   -  ITU-T Recommendation I.363.1 (1996), B-ISDN ATM adaptation layer
+      (AAL) specification: Type 1 AAL.
+
+   -  ITU-T Recommendation I.363.2 (1997), B-ISDN ATM adaptation layer
+      (AAL) specification: Type 2 AAL.
+
+   -  ITU-T Recommendation I.363.5 (1996), B-ISDN ATM adaptation layer
+      (AAL) specification: Type 5 AAL.
+
+   -  ITU-T Recommendation I.366.1 (1998), Segmentation and Reassembly
+      Service Specific Convergence Sublayer for the AAL type 2.
+
+   -  ITU-T Recommendation I.366.2 (1999), AAL type 2 service specific
+      convergence sublayer for trunking.
+
+   -  ITU-T Recommendation I.371 (2000), Traffic control and congestion
+      control in B-ISDN.
+
+   -  ITU-T Recommendation Q.763 (1999), Signalling System No. 7 - ISDN
+      user part formats and codes.
+
+   -  ITU-T Recommendation Q.765.5 (2001), Application transport
+      mechanism - Bearer independent call control (BICC).
+
+   -  ITU-T Recommendation Q.931 (1998), ISDN user-network interface
+      layer 3 specification for basic call control.
+
+   -  ITU-T Recommendation Q.2630.1 (1999), AAL type 2 signalling
+      protocol (Capability Set 1).
+
+
+
+
+
+
+Groves, et al.              Standards Track                     [Page 7]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  ITU-T Recommendation Q.2931 (1995), Digital Subscriber Signalling
+      System No. 2 (DSS2) - User-Network Interface (UNI) - Layer 3
+      specification for basic call/connection control.
+
+   -  ITU-T Recommendation Q.2941.1 (1997), Digital Subscriber
+      Signalling System No. 2 - Generic identifier transport.
+
+   -  ITU-T Recommendation Q.2961.1 (1995), Additional signalling
+      capabilities to support traffic parameters for the tagging option
+      and the sustainable call rate parameter set.
+
+   -  ITU-T Recommendation Q.2961.2 (1997), Additional traffic
+      parameters: Support of ATM transfer capability in the broadband
+      bearer capability information element.
+
+   -  ITU-T Recommendation Q.2965.1 (1999), Digital subscriber
+      signalling system No. 2 - Support of Quality of Service classes.
+
+   -  ITU-T Recommendation Q.2965.2 (1999), Digital subscriber
+      signalling system No. 2 - Signalling of individual Quality of
+      Service parameters.
+
+   -  ITU-T Recommendation V.76 (1996), Generic multiplexer using V.42
+      LAPM-based procedures.
+
+   -  ITU-T Recommendation X.213 (1995), Information technology - Open
+      Systems Interconnection - Network service definition plus
+      Amendment 1 (1997), Addition of the Internet protocol address
+      format identifier.
+
+   -  ITU-T Recommendation X.680 (1997), Information technology -
+      Abstract Syntax Notation One (ASN.1): Specification of basic
+      notation.
+
+   -  ITU-T Recommendation X.690 (1997), Information Technology - ASN.1
+      Encoding Rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER).
+
+   -  ATM Forum (1996), ATM User-Network Interface (UNI) Signalling
+      Specification - Version 4.0.
+
+   [RFC 1006] Rose, M. and D. Cass, "ISO Transport Service on top of the
+              TCP, Version 3", STD 35, RFC 1006, May 1987.
+
+   [RFC 2026] Brander, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+
+
+
+Groves, et al.              Standards Track                     [Page 8]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC 2327] Handley, M. and V. Jacobson, "SDP: Session Description
+              Protocol", RFC 2327, April 1998.
+
+   [RFC 2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+              2402, November 1998.
+
+   [RFC 2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+              Payload (ESP)", RFC 2406, November 1998.
+
+2.2   Informative references
+
+   -  ITU-T Recommendation E.180/Q.35 (1998), Technical characteristics
+      of tones for the telephone service.
+
+   -  CCITT Recommendation G.711 (1988), Pulse Code Modulation (PCM) of
+      voice frequencies.
+
+   -  ITU-T Recommendation H.221 (1999), Frame structure for a 64 to
+      1920 kbit/s channel in audiovisual teleservices.
+
+   -  ITU  T Recommendation H.223 (1996), Multiplexing protocol for low
+      bit rate multimedia communication.
+
+   -  ITU-T Recommendation H.226 (1998), Channel aggregation protocol
+      for multilink operation on circuit-switched networks
+
+   -  ITU-T Recommendation Q.724 (1998), Signalling procedures.
+
+   -  ITU-T Recommendation Q.764 (1999), Signalling system No. 7 - ISDN
+      user part signalling procedures.
+
+   -  ITU-T Recommendation Q.1902.4 (2001), Bearer independent call
+      control protocol - Basic call procedures.
+
+   [RFC 768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC 791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC 793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
+              793, September 1981.
+
+
+
+Groves, et al.              Standards Track                     [Page 9]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   [RFC 1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
+              51, RFC 1661, July 1994.
+
+   [RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", RFC 1889, January 1996.
+
+   [RFC 1890] Schulzrinne, H. and G. Fokus, "RTP Profile for Audio and
+              Video Conferences with Minimal Control",  RFC 1890,
+              January 1996.
+
+   [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
+
+   [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
+              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
+              March 1999.
+
+   [RFC 2805] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway
+              Control Protocol Architecture and Requirements", RFC 2805,
+              April 2000.
+
+3  Definitions
+
+   This document defines the following terms:
+
+   Access gateway:
+   A type of gateway that provides a User-Network Interface (UNI) such
+   as ISDN.
+
+   Descriptor:
+   A syntactic element of the protocol that groups related properties.
+   For instance, the properties of a media flow on the MG can be set by
+   the MGC by including the appropriate descriptor in a command.
+
+   Media Gateway (MG):
+   The media gateway converts media provided in one type of network to
+   the format required in another type of network.  For example, a MG
+   could terminate bearer channels from a switched circuit network
+   (e.g., DS0s) and media streams from a packet network (e.g., RTP
+   streams in an IP network).  This gateway may be capable of processing
+   audio, video and T.120 alone or in any combination, and will be
+   capable of full duplex media translations.  The MG may also play
+   audio/video messages and perform other IVR functions, or may perform
+   media conferencing.
+
+
+
+Groves, et al.              Standards Track                    [Page 10]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Media Gateway Controller (MGC):
+   Controls the parts of the call state that pertain to connection
+   control for media channels in a MG.
+
+   Multipoint Control Unit (MCU):
+   An entity that controls the setup and coordination of a multi-user
+   conference that typically includes processing of audio, video and
+   data.
+
+   Residential gateway:
+   A gateway that interworks an analogue line to a packet network.  A
+   residential gateway typically contains one or two analogue lines and
+   is located at the customer premises.
+
+   SCN FAS signalling gateway:
+   This function contains the SCN Signalling Interface that terminates
+   SS7, ISDN or other signalling links where the call control channel
+   and bearer channels are collocated in the same physical span.
+
+   SCN NFAS signalling gateway:
+   This function contains the SCN Signalling Interface that terminates
+   SS7 or other signalling links where the call control channels are
+   separated from bearer channels.
+
+   Stream:
+   Bidirectional media or control flow received/sent by a media gateway
+   as part of a call or conference.
+
+   Trunk:
+   A communication channel between two switching systems such as a DS0
+   on a T1 or E1 line.
+
+   Trunking gateway:
+   A gateway between SCN network and packet network that typically
+   terminates a large number of digital circuits.
+
+4  Abbreviations
+
+   This RFC document uses the following abbreviations:
+
+   ALF   Application Layer Framing
+
+   ATM   Asynchronous Transfer Mode
+
+   CAS   Channel Associated Signalling
+
+   DTMF  Dual Tone Multi-Frequency
+
+
+
+
+Groves, et al.              Standards Track                    [Page 11]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   FAS   Facility Associated Signalling
+
+   GSM   Global System for Mobile communications
+
+   GW    GateWay
+
+   IANA  Internet Assigned Numbers Authority (superseded by Internet
+         Corporation for Assigned Names and Numbers - ICANN)
+
+   IP    Internet Protocol
+
+   ISUP  ISDN User Part
+
+   IVR   Interactive Voice Response
+
+   MG    Media Gateway
+
+   MGC   Media Gateway Controller
+
+   NFAS  Non-Facility Associated Signalling
+
+   PRI   Primary Rate Interface
+
+   PSTN  Public Switched Telephone Network
+
+   QoS   Quality of Service
+
+   RTP   Real-time Transport Protocol
+
+   SCN   Switched Circuit Network
+
+   SG    Signalling Gateway
+
+   SS7   Signalling System No. 7
+
+5  Conventions
+
+   In the H.248.1 Recommendation, "SHALL" refers to a mandatory
+   requirement, while "SHOULD" refers to a suggested but optional
+   feature or procedure.  The term "MAY" refers to an optional course of
+   action without expressing a preference.  Note that these definition
+   are overridden in the present document by the RFC 2119 conventions
+   stated at the beginning of this document.  RFC 2119 has a more
+   precise definition of "should" than is provided by the ITU-T.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 12]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+6  Connection model
+
+   The connection model for the protocol describes the logical entities,
+   or objects, within the Media Gateway that can be controlled by the
+   Media Gateway Controller.  The main abstractions used in the
+   connection model are Terminations and Contexts.
+
+   A Termination sources and/or sinks one or more streams.  In a
+   multimedia conference, a Termination can be multimedia and sources or
+   sinks multiple media streams.  The media stream parameters, as well
+   as modem, and bearer parameters are encapsulated within the
+   Termination.
+
+   A Context is an association between a collection of Terminations.
+   There is a special type of Context, the null Context, which contains
+   all Terminations that are not associated to any other Termination.
+   For instance, in a decomposed access gateway, all idle lines are
+   represented by Terminations in the null Context.
+
+   Following is a graphical depiction of these concepts.  The diagram of
+   Figure 1 gives several examples and is not meant to be an
+   all-inclusive illustration.  The asterisk box in each of the Contexts
+   represents the logical association of Terminations implied by the
+   Context.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 13]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         +------------------------------------------------------+
+         |Media Gateway                                         |
+         | +-------------------------------------------------+  |
+         | |Context                          +-------------+ |  |
+         | |                                 | Termination | |  |
+         | |                                 |-------------| |  |
+         | |  +-------------+             +->| SCN Bearer  |<---+->
+         | |  | Termination |   +-----+   |  |   Channel   | |  |
+         | |  |-------------|   |     |---+  +-------------+ |  |
+       <-+--->| RTP Stream  |---|  *  |                      |  |
+         | |  |             |   |     |---+  +-------------+ |  |
+         | |  +-------------+   +-----+   |  | Termination | |  |
+         | |                              |  |-------------| |  |
+         | |                              +->| SCN Bearer  |<---+->
+         | |                                 |   Channel   | |  |
+         | |                                 +-------------+ |  |
+         | +-------------------------------------------------+  |
+         |                                                      |
+         |                                                      |
+         |                    +------------------------------+  |
+         |   (NULL Context)   |Context                       |  |
+         |  +-------------+   |              +-------------+ |  |
+         |  | Termination |   | +-----+      | Termination | |  |
+         |  |-------------|   | |     |      |-------------| |  |
+         |  | SCN Bearer  |   | |  *  |------| SCN Bearer  |<---+->
+         |  |   Channel   |   | |     |      |   Channel   | |  |
+         |  +-------------+   | +-----+      +-------------+ |  |
+         |                    +------------------------------+  |
+         |                                                      |
+         |                                                      |
+         | +-------------------------------------------------+  |
+         | |Context                                          |  |
+         | |  +-------------+                +-------------+ |  |
+         | |  | Termination |   +-----+      | Termination | |  |
+         | |  |-------------|   |     |      |-------------| |  |
+       <-+--->| SCN Bearer  |---|  *  |------| SCN Bearer  |<---+->
+         | |  |   Channel   |   |     |      |   Channel   | |  |
+         | |  +-------------+   +-----+      +-------------+ |  |
+         | +-------------------------------------------------+  |
+         | ___________________________________________________  |
+         +------------------------------------------------------+
+
+            Figure 1: Examples of Megaco/H.248 Connection Model
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 14]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The example in Figure 2 shows an example of one way to accomplish a
+   call-waiting scenario in a decomposed access gateway, illustrating
+   the relocation of a Termination between Contexts.  Terminations T1
+   and T2 belong to Context C1 in a two-way audio call.  A second audio
+   call is waiting for T1 from Termination T3.  T3 is alone in Context
+   C2.  T1 accepts the call from T3, placing T2 on hold.  This action
+   results in T1 moving into Context C2, as shown in Figure 3.
+
+         +------------------------------------------------------+
+         |Media Gateway                                         |
+         | +-------------------------------------------------+  |
+         | |Context C1                                       |  |
+         | |  +-------------+                +-------------+ |  |
+         | |  | Term. T2    |   +-----+      | Term. T1    | |  |
+         | |  |-------------|   |     |      |-------------| |  |
+       <-+--->| RTP Stream  |---|  *  |------| SCN Bearer  |<---+->
+         | |  |             |   |     |      |   Channel   | |  |
+         | |  +-------------+   +-----+      +-------------+ |  |
+         | +-------------------------------------------------+  |
+         |                                                      |
+         | +-------------------------------------------------+  |
+         | |Context C2                                       |  |
+         | |                                 +-------------+ |  |
+         | |                    +-----+      | Term. T3    | |  |
+         | |                    |     |      |-------------| |  |
+         | |                    |  *  |------| SCN Bearer  |<---+->
+         | |                    |     |      |   Channel   | |  |
+         | |                    +-----+      +-------------+ |  |
+         | +-------------------------------------------------+  |
+         +------------------------------------------------------+
+
+     Figure 2: Example Call Waiting Scenario / Alerting Applied to T1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 15]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         +------------------------------------------------------+
+         |Media Gateway                                         |
+         | +-------------------------------------------------+  |
+         | |Context C1                                       |  |
+         | |  +-------------+                                |  |
+         | |  | Term. T2    |   +-----+                      |  |
+         | |  |-------------|   |     |                      |  |
+       <-+--->| RTP Stream  |---|  *  |                      |  |
+         | |  |             |   |     |                      |  |
+         | |  +-------------+   +-----+                      |  |
+         | +-------------------------------------------------+  |
+         |                                                      |
+         | +-------------------------------------------------+  |
+         | |Context C2                                       |  |
+         | |  +-------------+                +-------------+ |  |
+         | |  | Term. T1    |   +-----+      | Term. T3    | |  |
+         | |  |-------------|   |     |      |-------------| |  |
+       <-+--->| SCN Bearer  |---|  *  |------| SCN Bearer  |<---+->
+         | |  |   Channel   |   |     |      |   Channel   | |  |
+         | |  +-------------+   +-----+      +-------------+ |  |
+         | +-------------------------------------------------+  |
+         +------------------------------------------------------+
+
+          Figure 3. Example Call Waiting Scenario / Answer by T1
+
+6.1   Contexts
+
+   A Context is an association between a number of Terminations.  The
+   Context describes the topology (who hears/sees whom) and the media
+   mixing and/or switching parameters if more than two Terminations are
+   involved in the association.
+
+   There is a special Context called the null Context.  It contains
+   Terminations that are not associated to any other Termination.
+   Terminations in the null Context can have their parameters examined
+   or modified, and may have events detected on them.
+
+   In general, an Add command is used to add Terminations to Contexts.
+   If the MGC does not specify an existing Context to which the
+   Termination is to be added, the MG creates a new Context.  A
+   Termination may be removed from a Context with a Subtract command,
+   and a Termination may be moved from one Context to another with a
+   Move command.  A Termination SHALL exist in only one Context at a
+   time.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 16]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The maximum number of Terminations in a Context is a MG property.
+   Media gateways that offer only point-to-point connectivity might
+   allow at most two Terminations per Context.  Media gateways that
+   support multipoint conferences might allow three or more Terminations
+   per Context.
+
+6.1.1 Context attributes and descriptors
+
+   The attributes of Contexts are:
+
+   -  ContextID.
+
+   -  The topology (who hears/sees whom).
+
+      The topology of a Context describes the flow of media between the
+      Terminations within a Context.  In contrast, the mode of a
+      Termination (send/receive/...) describes the flow of the media at
+      the ingress/egress of the media gateway.
+
+   -  The priority is used for a Context in order to provide the MG with
+      information about a certain precedence handling for a Context.
+      The MGC can also use the priority to control autonomously the
+      traffic precedence in the MG in a smooth way in certain
+      situations (e.g., restart), when a lot of Contexts must be handled
+      simultaneously.  Priority 0 is the lowest priority and a priority
+      of 15 is the highest priority.
+
+   -  An indicator for an emergency call is also provided to allow a
+      preference handling in the MG.
+
+6.1.2 Creating, deleting and modifying Contexts
+
+   The protocol can be used to (implicitly) create Contexts and modify
+   the parameter values of existing Contexts.  The protocol has commands
+   to add Terminations to Contexts, subtract them from Contexts, and to
+   move Terminations between Contexts.  Contexts are deleted implicitly
+   when the last remaining Termination is subtracted or moved out.
+
+6.2   Terminations
+
+   A Termination is a logical entity on a MG that sources and/or sinks
+   media and/or control streams.  A Termination is described by a number
+   of characterizing Properties, which are grouped in a set of
+   Descriptors that are included in commands.  Terminations have unique
+   identities (TerminationIDs), assigned by the MG at the time of their
+   creation.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 17]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Terminations representing physical entities have a semi-permanent
+   existence.  For example, a Termination representing a TDM channel
+   might exist for as long as it is provisioned in the gateway.
+   Terminations representing ephemeral information flows, such as RTP
+   flows, would usually exist only for the duration of their use.
+
+   Ephemeral Terminations are created by means of an Add command.  They
+   are destroyed by means of a Subtract command.  In contrast, when a
+   physical Termination is Added to or Subtracted from a Context, it is
+   taken from or to the null Context, respectively.
+
+   Terminations may have signals applied to them (see 7.1.11).
+   Terminations may be programmed to detect Events, the occurrence of
+   which can trigger notification messages to the MGC, or action by the
+   MG.  Statistics may be accumulated on a Termination.  Statistics are
+   reported to the MGC upon request (by means of the AuditValue command,
+   see 7.2.5) and when the Termination is taken out of the call it is
+   in.
+
+   Multimedia gateways may process multiplexed media streams.  For
+   example, Recommendation H.221 describes a frame structure for
+   multiple media streams multiplexed on a number of digital 64 kbit/s
+   channels.  Such a case is handled in the connection model in the
+   following way.  For every bearer channel that carries part of the
+   multiplexed streams, there is a physical or ephemeral "bearer
+   Termination".  The bearer Terminations that source/sink the digital
+   channels are connected to a separate Termination called the
+   "multiplexing Termination".  The multiplexing termination is an
+   ephemeral termination representing a frame-oriented session.  The
+   MultiplexDescriptor for this Termination describes the multiplex used
+   (e.g., H.221 for an H.320 session) and indicates the order in which
+   the contained digital channels are assembled into a frame.
+
+   Multiplexing terminations may be cascades (e.g., H.226 multiplex of
+   digital channels feeding into a H.223 multiplex supporting an H.324
+   session).
+
+   The individual media streams carried in the session are described by
+   StreamDescriptors on the multiplexing Termination.  These media
+   streams can be associated with streams sourced/sunk by Terminations
+   in the Context other than the bearer Terminations supporting the
+   multiplexing Termination.  Each bearer Termination supports only a
+   single data stream.  These data streams do not appear explicitly as
+   streams on the multiplexing Termination and they are hidden from the
+   rest of the context.
+
+   Figures 4, 5, 6, and 6a illustrate typical applications of the
+   multiplexing termination and Multiplex Descriptor.
+
+
+
+Groves, et al.              Standards Track                    [Page 18]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                  +-----------------------------------+
+                  | Context     +-------+             |
+                 +----+         |       |             |
+   Circuit 1 -|--| TC1|---------+ Tmux  |             |
+              |  +----+ (Str 1) |       |  Audio    +-----+
+              |   |             |       +-----*-----+     |-----
+              |  +----+         | H.22x | Stream 1  |     |
+   Circuit 2 -|--| TC2|---------+ multi-|           | TR1 |
+              |  +----+ (Str 1) | plex  |           |(RTP)|
+              |   |             |       |  Video    |     |
+              |  +----+         |       +-----*-----+     |-----
+   Circuit 3 -|--| TC3|---------+       | Stream 2  |     |
+              /  +----+ (Str 1) |       |           +-----+
+             /    |             +-------+             |
+            /     +-----------------\-----------------+
+   Audio, video, and control         \
+   signals are carried in frames    Tmux is an ephemeral with two
+   spanning the circuits.           explicit Stream Descriptors
+                                    and a Multiplex Descriptor.
+
+      Figure 4: Multiplexed Termination Scenario - Circuit to Packet
+              (Asterisks * denote the centre of the context)
+
+                    Context
+                  +--------------------------------------+
+                  |       +-------+        +-------+     |
+                 +----+   |       |        |       |   +----+
+   Circuit 1 ----| TC1|---+ Tmux1 |  Audio | Tmux2 +---| TC4|---
+                 +----+   |       +---*----+       |   +----+
+                  |       |       |  Str 1 |       |     |
+                 +----+   | H.22x |        | H.22x |   +----+
+   Circuit 2 ----| TC2|---+ multi-|        | multi-+---| TC5|---
+                 +----+   | plex  |        | plex  |   +----+
+                  |       |       |  Video |       |     |
+                 +----+   |       +---*----+       |   +----+
+   Circuit 3 ----| TC3|---+       |  Str 2 |       +---| TC6|---
+                 +----+   |       |        |       |   +----+
+                  |       +-------+        +-------+     |
+                  +-----------------\-----/--------------+
+                                     \   /
+             Tmux1 and Tmux2 are ephemerals each with two
+            explicit Stream Descriptors and a Multiplex Descriptor.
+
+      Figure 5: Multiplexed Termination Scenario - Circuit to Circuit
+              (Asterisks * denote the centre of the context)
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 19]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                  +-----------------------------------+
+                  | Context     +-------+             |
+                 +----+         |       |             |
+   Circuit 1 -|--| TC1|---------+ Tmux  |             |
+              |  +----+ (Str 1) |       |  Audio    +-----+
+              |   |             |       +-----*-----+ TR1 |-----
+              |  +----+         | H.22x | Stream 1  |(RTP)|
+   Circuit 2 -|--| TC2|---------+ multi-|           +-----+
+              |  +----+ (Str 1) | plex  |             |
+              |   |             |       |  Video    +-----+
+              |  +----+         |       +-----*-----+ TR2 |-----
+   Circuit 3 -|--| TC3|---------+       | Stream 2  |(RTP)|
+              /  +----+ (Str 1) |       |           +-----+
+             /    |             +-------+             |
+            /     +-----------------\-----------------+
+   Audio, video, and control         \ Tmux is an ephemeral with two
+   signals are carried in frames    explicit Stream Descriptors and
+   spanning the circuits.           and a Multiplex Descriptor.
+
+      Figure 6: Multiplexed Termination Scenario - Single to Multiple
+                               Terminations
+              (Asterisks * denote the centre of the context)
+
+            Context
+          +---------------------------------------------+
+          |       +-------+       +-------+             |
+   Cct 1 +----+   |       |       |       | Audio     +-----+
+     ----| TC1|---+ Tmux1 |       | Tmux2 +-----*-----| TR1 |-----
+         +----+   |       |       |       | Stream 1  |(RTP)|
+          |       |       | Data  |       |           +-----+
+   Cct 2 +----+   | H.226 +-------+ H.223 |             |
+     ----| TC2|---+ multi-|(Str 1)| multi-| Control   +-----+
+         +----+   | plex  |       | plex  +-----*-----+ Tctl|-----
+          |       |       |       |       | Stream 3  +-----+
+   Cct 3 +----+   |       |       |       |             |
+     ----| TC3|---+       |       |       |           +-----+
+         +----+   |       |       |       +-----*-----+ TR2 |-----
+          |       +-------+       |       |  Video    |(RTP)|
+          |                       +-------+ Stream 2  +-----+
+          |                                             |
+          +---------------------------------------------+
+        Tmux1 has a Multiplex Descriptor and a single data stream.
+        Tmux2 has a Multiplex Descriptor with a single bearer and
+        three explicit Stream Descriptors.
+
+    Figure 6a: Multiplexed Termination Scenario - Cascaded Multiplexes
+              (Asterisks * denote the centre of the context)
+     Note: this figure does not appear in Rec.  H.248.1
+
+
+
+Groves, et al.              Standards Track                    [Page 20]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Terminations may be created which represent multiplexed bearers, such
+   as an ATM AAL Type 2 bearer.  When a new multiplexed bearer is to be
+   created, an ephemeral Termination is created in a Context established
+   for this purpose.  When the Termination is subtracted, the
+   multiplexed bearer is destroyed.
+
+6.2.1 Termination dynamics
+
+   The protocol can be used to create new Terminations and to modify
+   property values of existing Terminations.  These modifications
+   include the possibility of adding or removing events and/or signals.
+   The Termination properties, and events and signals are described in
+   the ensuing subclauses.  An MGC can only release/modify Terminations
+   and the resources that the Termination represents which it has
+   previously seized via, e.g., the Add command.
+
+6.2.2 TerminationIDs
+
+   Terminations are referenced by a TerminationID, which is an arbitrary
+   schema chosen by the MG.
+
+   TerminationIDs of physical Terminations are provisioned in the Media
+   Gateway.  The TerminationIDs may be chosen to have structure.  For
+   instance, a TerminationID may consist of trunk group and a trunk
+   within the group.
+
+   A wildcarding mechanism using two types of wildcards can be used with
+   TerminationIDs.  The two wildcards are ALL and CHOOSE.  The former is
+   used to address multiple Terminations at once, while the latter is
+   used to indicate to a media gateway that it must select a Termination
+   satisfying the partially specified TerminationID.  This allows, for
+   instance, that a MGC instructs a MG to choose a circuit within a
+   trunk group.
+
+   When ALL is used in the TerminationID of a command, the effect is
+   identical to repeating the command with each of the matching
+   TerminationIDs.  The use of ALL does not address the ROOT
+   termination.  Since each of these commands may generate a response,
+   the size of the entire response may be large.  If individual
+   responses are not required, a wildcard response may be requested.  In
+   such a case, a single response is generated, which contains the UNION
+   of all of the individual responses which otherwise would have been
+   generated, with duplicate values suppressed.  For instance, given a
+   Termination Ta with properties p1=a, p2=b and Termination Tb with
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 21]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   properties p2=c, p3=d, a UNION response would consist of a wildcarded
+   TerminationId and the sequence of properties p1=a, p2=b,c and p3=d.
+   Wildcard response may be particularly useful in the Audit commands.
+
+   The encoding of the wildcarding mechanism is detailed in Annexes A
+   and B.
+
+6.2.3 Packages
+
+   Different types of gateways may implement Terminations that have
+   widely differing characteristics.  Variations in Terminations are
+   accommodated in the protocol by allowing Terminations to have
+   optional Properties, Events, Signals and Statistics implemented by
+   MGs.
+
+   In order to achieve MG/MGC interoperability, such options are grouped
+   into Packages, and typically a Termination realizes a set of such
+   Packages.  More information on definition of packages can be found in
+   clause 12.  An MGC can audit a Termination to determine which
+   Packages it realizes.
+
+   Properties, Events, Signals and Statistics defined in Packages, as
+   well as parameters to them, are referenced by identifiers (Ids).
+   Identifiers are scoped.  For each package, PropertyIds, EventIds,
+   SignalIds, StatisticsIds and ParameterIds have unique name spaces and
+   the same identifier may be used in each of them.  Two PropertyIds in
+   different packages may also have the same identifier, etc.
+
+   To support a particular package the MG must support all properties,
+   signals, events and statistics defined in a package.  It must also
+   support all Signal and Event parameters.  The MG may support a subset
+   of the values listed in a package for a particular Property or
+   Parameter.
+
+   When packages are extended, the properties, events, signals and
+   statistics defined in the base package can be referred to using
+   either the extended package name or the base package name.  For
+   example, if Package A defines event e1, and Package B extends Package
+   A, then B/e1 is an event for a termination implementing Package B. By
+   definition, the MG MUST also implement the base Package, but it is
+   optional to publish the base package as an allowed interface.  If it
+   does publish  A, then A would be reported on the Package Descriptor
+   in AuditValue as well as B, and event A/e1 would be available on a
+   termination.  If the MG does not publish A, then only B/e1 would be
+   available.  If published through AuditValue, A/e1 and B/e1 are the
+   same event.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 22]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   For improved interoperability and backward compatibility, an MG MAY
+   publish all Packages supported by its Terminations, including base
+   Packages from which extended Packages are derived.  An exception to
+   this is in cases where the base packages are expressly "Designed to
+   be extended only".
+
+6.2.4 Termination properties and descriptors
+
+   Terminations have properties.  The properties have unique
+   PropertyIDs. Most properties have default values, which are
+   explicitly defined in this protocol specification or in a package
+   (see clause 12) or set by provisioning.  If not provisioned
+   otherwise, the properties in all descriptors except TerminationState
+   and LocalControl default to empty/"no value" when a Termination is
+   first created or returned to the null Context.  The default contents
+   of the two exceptions are described in 7.1.5 and 7.1.7.
+
+   The provisioning of a property value in the MG will override any
+   default value, be it supplied in this protocol specification or in a
+   package.  Therefore if it is essential for the MGC to have full
+   control over the property values of a Termination, it should supply
+   explicit values when ADDing the Termination to a Context.
+   Alternatively, for a physical Termination the MGC can determine any
+   provisioned property values by auditing the Termination while it is
+   in the NULL Context.
+
+   There are a number of common properties for Terminations and
+   properties specific to media streams.  The common properties are also
+   called the Termination state properties.  For each media stream,
+   there are local properties and properties of the received and
+   transmitted flows.
+
+   Properties not included in the base protocol are defined in Packages.
+   These properties are referred to by a name consisting of the
+   PackageName and a PropertyId.  Most properties have default values
+   described in the Package description.  Properties may be read-only or
+   read/write.  The possible values of a property may be audited, as can
+   their current values.  For properties that are read/write, the MGC
+   can set their values.  A property may be declared as "Global" which
+   has a single value shared by all Terminations realizing the package.
+   Related properties are grouped into descriptors for convenience.
+
+   When a Termination is added to a Context, the value of its read/write
+   properties can be set by including the appropriate descriptors as
+   parameters to the Add command.  Similarly, a property of a
+   Termination in a Context may have its value changed by the Modify
+   command.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 23]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Properties may also have their values changed when a Termination is
+   moved from one Context to another as a result of a Move command.  In
+   some cases, descriptors are returned as output from a command.
+
+   In general, if a Descriptor is completely omitted from one of the
+   aforementioned Commands, the properties in that Descriptor retain
+   their prior values for the Termination(s) upon which the Command
+   acts.  On the other hand, if some read/write properties are omitted
+   from a Descriptor in a Command (i.e., the Descriptor is only
+   partially specified), those properties will be reset to their default
+   values for the Termination(s) upon which the Command acts, unless the
+   package specifies other behavior.  For more details, see clause 7.1
+   dealing with the individual Descriptors.
+
+   The following table lists all of the possible descriptors and their
+   use.  Not all descriptors are legal as input or output parameters to
+   every command.
+
+   Descriptor name  Description
+
+   Modem            Identifies modem type and properties when
+                    applicable
+
+   Mux              Describes multiplex type for multimedia
+                    Terminations (e.g., H.221, H.223, H.225.0) and
+                    Terminations forming the input mux
+
+   Media            A list of media stream specifications (see 7.1.4)
+
+   TerminationState Properties of a Termination (which can be defined
+                    in Packages) that are not stream specific
+
+   Stream           A list of remote/local/localControl descriptors for
+                    a single stream
+
+   Local            Contains properties that specify the media flows
+                    that the MG receives from the remote entity.
+
+   Remote           Contains properties that specify the media flows
+                    that the MG sends to the remote entity.
+
+   LocalControl     Contains properties (which can be defined in
+                    packages) that are of interest between the MG and
+                    the MGC.
+
+   Events           Describes events to be detected by the MG and what
+                    to do when an event is detected.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 24]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   EventBuffer      Describes events to be detected by the MG when
+                    Event Buffering is active.
+
+   Signals          Describes signals (see 7.1.11) applied  to
+                    Terminations.
+
+   Audit            In Audit commands, identifies which information is
+                    desired.
+
+   Packages         In AuditValue, returns a list of Packages realized
+                    by Termination.
+
+   DigitMap         Defines patterns against which sequences of a
+                    specified set of events are to be matched so they
+                    can be reported as a group rather than singly.
+
+   ServiceChange    In ServiceChange, what, why service change
+                    occurred, etc.
+
+   ObservedEvents   In Notify or AuditValue, report of events observed.
+
+   Statistics       In Subtract and Audit, report of Statistics kept on
+                    a Termination.
+
+   Topology         Specifies flow directions between Terminations in a
+                    Context.
+
+   Error            Contains an error code and optionally error text;
+                    it may occur in command replies and in Notify
+                    requests.
+
+6.2.5 Root Termination
+
+   Occasionally, a command must refer to the entire gateway, rather than
+   a Termination within it.  A special TerminationID, "Root" is reserved
+   for this purpose.  Packages may be defined on Root.  Root thus may
+   have properties, events and statistics (signals are not appropriate
+   for root).  Accordingly, the root TerminationID may appear in:
+
+   -  a Modify command - to change a property or set an event
+
+   -  a Notify command - to report an event
+
+   -  an AuditValue return - to examine the values of properties and
+      statistics implemented on root
+
+   -  an AuditCapability - to determine what properties of root are
+      implemented
+
+
+
+Groves, et al.              Standards Track                    [Page 25]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  a ServiceChange - to declare the gateway in or out of service.
+
+   Any other use of the root TerminationID is an error.  Error code
+   410 - Incorrect identifier shall be returned in these cases.
+
+7  Commands
+
+   The protocol provides commands for manipulating the logical entities
+   of the protocol connection model, Contexts and Terminations.
+   Commands provide control at the finest level of granularity supported
+   by the protocol.  For example, Commands exist to add Terminations to
+   a Context, modify Terminations, subtract Terminations from a Context,
+   and audit properties of Contexts or Terminations.  Commands provide
+   for complete control of the properties of Contexts and Terminations.
+   This includes specifying which events a Termination is to report,
+   which signals/actions are to be applied to a Termination and
+   specifying the topology of a Context (who hears/sees whom).
+
+   Most commands are for the specific use of the Media Gateway
+   Controller as command initiator in controlling Media Gateways as
+   command responders.  The exceptions are the Notify and ServiceChange
+   commands: Notify is sent from Media Gateway to Media Gateway
+   Controller, and ServiceChange may be sent by either entity.  Below is
+   an overview of the commands; they are explained in more detail in
+   7.2.
+
+   1) Add - The Add command adds a Termination to a Context.  The Add
+      command on the first Termination in a Context is used to create a
+      Context.
+
+   2) Modify - The Modify command modifies the properties, events and
+      signals of a Termination.
+
+   3) Subtract - The Subtract command disconnects a Termination from its
+      Context and returns statistics on the Termination's participation
+      in the Context.  The Subtract command on the last Termination in a
+      Context deletes the Context.
+
+   4) Move - The Move command atomically moves a Termination to another
+      Context.
+
+   5) AuditValue - The AuditValue command returns the current state of
+      properties, events, signals and statistics of Terminations.
+
+   6) AuditCapabilities - The AuditCapabilities command returns all the
+      possible values for Termination properties, events and signals
+      allowed by the Media Gateway.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 26]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   7) Notify - The Notify command allows the Media Gateway to inform the
+      Media Gateway Controller of the occurrence of events in the Media
+      Gateway.
+
+   8) ServiceChange - The ServiceChange command allows the Media Gateway
+      to notify the Media Gateway Controller that a Termination or group
+      of Terminations is about to be taken out of service or has just
+      been returned to service.  ServiceChange is also used by the MG to
+      announce its availability to a MGC (registration), and to notify
+      the MGC of impending or completed restart of the MG.  The MGC may
+      announce a handover to the MG by sending it a ServiceChange
+      command.  The MGC may also use ServiceChange to instruct the MG to
+      take a Termination or group of Terminations in or out of service.
+
+   These commands are detailed in 7.2.1 through 7.2.8.
+
+7.1   Descriptors
+
+   The parameters to a command are termed Descriptors.  A descriptor
+   consists of a name and a list of items.  Some items may have values.
+   Many Commands share common descriptors.  This subclause enumerates
+   these descriptors.  Descriptors may be returned as output from a
+   command.  In any such return of descriptor contents, an empty
+   descriptor is represented by its name unaccompanied by any list.
+   Parameters and parameter usage specific to a given Command type are
+   described in the subclause that describes the Command.
+
+7.1.1 Specifying parameters
+
+   Command parameters are structured into a number of descriptors.  In
+   general, the text format of descriptors is
+   DescriptorName=<someID>{parm=value, parm=value, ...}.
+
+   Parameters may be fully specified, overspecified or underspecified:
+
+   1) Fully specified parameters have a single, unambiguous value that
+      the command initiator is instructing the command responder to use
+      for the specified parameter.
+
+   2) Underspecified parameters, using the CHOOSE value, allow the
+      command responder to choose any value it can support.
+
+   3) Overspecified parameters have a list of potential values.  The
+      list order specifies the command initiator's order of preference
+      of selection.  The command responder chooses one value from
+      the offered list and returns that value to the command initiator.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 27]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   If a required descriptor other than the Audit descriptor is
+   unspecified (i.e., entirely absent) from a command, the previous
+   values set in that descriptor for that Termination, if any, are
+   retained.  In commands other than Subtract, a missing Audit
+   descriptor is equivalent to an empty Audit descriptor.  The Behaviour
+   of the MG with respect to unspecified parameters within a descriptor
+   varies with the descriptor concerned, as indicated in succeeding
+   subclauses.  Whenever a parameter is underspecified or overspecified,
+   the descriptor containing the value chosen by the responder is
+   included as output from the command.
+
+   Each command specifies the TerminationId the command operates on.
+   This TerminationId may be "wildcarded".  When the TerminationId of a
+   command is wildcarded, the effect shall be as if the command was
+   repeated with each of the TerminationIds matched.
+
+7.1.2 Modem descriptor
+
+   The Modem descriptor specifies the modem type and parameters, if any,
+   required for use in e.g., H.324 and text conversation.  The
+   descriptor includes the following modem types: V.18, V.22, V.22 bis,
+   V.32, V.32 bis, V.34, V.90, V.91, Synchronous ISDN, and allows for
+   extensions.  By default, no Modem descriptor is present in a
+   Termination.
+
+7.1.3 Multiplex descriptor
+
+   In multimedia calls, a number of media streams are carried on a
+   (possibly different) number of bearers.  The multiplex descriptor
+   associates the media and the bearers.  The descriptor includes the
+   multiplex type:
+
+   -  H.221;
+
+   -  H.223;
+
+   -  H.226;
+
+   -  V.76;
+
+   -  possible extensions,
+
+   and a set of TerminationIDs representing the multiplexed bearers, in
+   order.  For example:
+
+      Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 28]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+7.1.4 Media descriptor
+
+   The Media descriptor specifies the parameters for all the media
+   streams.  These parameters are structured into two descriptors: a
+   TerminationState descriptor, which specifies the properties of a
+   Termination that are not stream dependent, and one or more Stream
+   descriptors each of which describes a single media stream.
+
+   A stream is identified by a StreamID.  The StreamID is used to link
+   the streams in a Context that belong together.  Multiple streams
+   exiting a Termination shall be synchronized with each other.  Within
+   the Stream descriptor, there are up to three subsidiary descriptors:
+   LocalControl, Local, and Remote.  The relationship between these
+   descriptors is thus:
+
+   Media descriptor
+      TerminationState Descriptor
+      Stream descriptor
+         LocalControl descriptor
+         Local descriptor
+         Remote descriptor
+
+   As a convenience, LocalControl, Local, or Remote descriptors may be
+   included in the Media descriptor without an enclosing Stream
+   descriptor.  In this case, the StreamID is assumed to be 1.
+
+7.1.5 TerminationState descriptor
+
+   The TerminationState descriptor contains the ServiceStates property,
+   the EventBufferControl property and properties of a Termination
+   (defined in Packages) that are not stream specific.
+
+   The ServiceStates property describes the overall state of the
+   Termination (not stream specific).  A Termination can be in one of
+   the following states: "test", "out of service", or "in service".  The
+   "test" state indicates that the Termination is being tested.  The
+   state "out of service" indicates that the Termination cannot be used
+   for traffic.  The state "in service" indicates that a Termination can
+   be used or is being used for normal traffic.  "in service" is the
+   default state.
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 29]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Values assigned to Properties may be simple values
+   (integer/string/enumeration) or may be underspecified, where more
+   than one value is supplied and the MG may make a choice:
+
+   -  Alternative Values - multiple values in a list, one of which must
+      be selected
+
+   -  Ranges - minimum and maximum values, any value between min and max
+      must be selected, boundary values included
+
+   -  Greater Than/Less Than - value must be greater/less than specified
+      value
+
+   -  CHOOSE Wildcard - the MG chooses from the allowed values for the
+      property
+
+   The EventBufferControl property specifies whether events are buffered
+   following detection of an event in the Events descriptor, or
+   processed immediately.  See 7.1.9 for details.
+
+7.1.6 Stream descriptor
+
+   A Stream descriptor specifies the parameters of a single
+   bidirectional stream.  These parameters are structured into three
+   descriptors: one that contains Termination properties specific to a
+   stream and one each for local and remote flows.  The Stream
+   Descriptor includes a StreamID which identifies the stream.  Streams
+   are created by specifying a new StreamID on one of the Terminations
+   in a Context.  A stream is deleted by setting empty Local and Remote
+   descriptors for the stream with ReserveGroup and ReserveValue in
+   LocalControl set to "false" on all Terminations in the Context that
+   previously supported that stream.
+
+   StreamIDs are of local significance between MGC and MG and they are
+   assigned by the MGC.  Within a Context, StreamID is a means by which
+   to indicate which media flows are interconnected: streams with the
+   same StreamID are connected.
+
+   If a Termination is moved from one Context to another, the effect on
+   the Context to which the Termination is moved is the same as in the
+   case that a new Termination were added with the same StreamIDs as the
+   moved Termination.
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 30]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+7.1.7 LocalControl descriptor
+
+   The LocalControl descriptor contains the Mode property, the
+   ReserveGroup and ReserveValue properties and properties of a
+   Termination (defined in Packages) that are stream specific, and are
+   of interest between the MG and the MGC.  Values of properties may be
+   underspecified as in 7.1.1.
+
+   The allowed values for the mode property are send-only, receive-only,
+   send/receive, inactive and loop-back. "Send" and "receive" are with
+   respect to the exterior of the Context, so that, for example, a
+   stream set to mode=sendOnly does not pass received media into the
+   Context.  The default value for the mode property is "Inactive".
+   Signals and Events are not affected by mode.
+
+   The boolean-valued Reserve properties, ReserveValue and ReserveGroup,
+   of a Termination indicate what the MG is expected to do when it
+   receives a Local and/or Remote descriptor.
+
+   If the value of a Reserve property is True, the MG SHALL reserve
+   resources for all alternatives specified in the Local and/or Remote
+   descriptors for which it currently has resources available.  It SHALL
+   respond with the alternatives for which it reserves resources.  If it
+   cannot not support any of the alternatives, it SHALL respond with a
+   reply to the MGC that contains empty Local and/or Remote descriptors.
+   If media begins to flow while more than a single alternative is
+   reserved, media packets may be sent/received on any of the
+   alternatives and must be processed, although only a single
+   alternative may be active at any given time.
+
+   If the value of a Reserve property is False, the MG SHALL choose one
+   of the alternatives specified in the Local descriptor (if present)
+   and one of the alternatives specified in the Remote descriptor (if
+   present).  If the MG has not yet reserved resources to support the
+   selected alternative, it SHALL reserve the resources.  If, on the
+   other hand, it already reserved resources for the Termination
+   addressed (because of a prior exchange with ReserveValue and/or
+   ReserveGroup equal to True), it SHALL release any excess resources it
+   reserved previously.  Finally, the MG shall send a reply to the MGC
+   containing the alternatives for the Local and/or Remote descriptor
+   that it selected.  If the MG does not have sufficient resources to
+   support any of the alternatives specified, it SHALL respond with
+   error 510 (insufficient resources).
+
+   The default value of ReserveValue and ReserveGroup is False.  More
+   information on the use of the two Reserve properties is provided in
+   7.1.8.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 31]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   A new setting of the LocalControl Descriptor completely replaces the
+   previous setting of that descriptor in the MG.  Thus, to retain
+   information from the previous setting, the MGC must include that
+   information in the new setting.  If the MGC wishes to delete some
+   information from the existing descriptor, it merely resends the
+   descriptor (in a Modify command) with the unwanted information
+   stripped out.
+
+7.1.8 Local and Remote descriptors
+
+   The MGC uses Local and Remote descriptors to reserve and commit MG
+   resources for media decoding and encoding for the given Stream(s) and
+   Termination to which they apply.  The MG includes these descriptors
+   in its response to indicate what it is actually prepared to support.
+   The MG SHALL include additional properties and their values in its
+   response if these properties are mandatory yet not present in the
+   requests made by the MGC (e.g., by specifying detailed video encoding
+   parameters where the MGC only specified the payload type).
+
+   Local refers to the media received by the MG and Remote refers to the
+   media sent by the MG.
+
+   When text encoding the protocol, the descriptors consist of session
+   descriptions as defined in SDP (RFC 2327).  In session descriptions
+   sent from the MGC to the MG, the following exceptions to the syntax
+   of RFC 2327 are allowed:
+
+   -  the "s=", "t=" and "o=" lines are optional;
+
+   -  the use of CHOOSE is allowed in place of a single parameter value;
+      and
+
+   -  the use of alternatives is allowed in place of a single parameter
+      value.
+
+   A Stream Descriptor specifies a single bi-directional media stream
+   and so a single session description MUST NOT include more than one
+   media description ("m=" line).  A Stream Descriptor may contain
+   additional session descriptions as alternatives.  Each media stream
+   for a termination must appear in distinct Stream Descriptors.  When
+   multiple session descriptions are provided in one descriptor, the
+   "v=" lines are required as delimiters; otherwise they are optional in
+   session descriptions sent to the MG.  Implementations shall accept
+   session descriptions that are fully conformant to RFC 2327.  When
+   binary encoding the protocol the descriptor consists of groups of
+   properties (tag-value pairs) as specified in Annex C.  Each such
+   group may contain the parameters of a session description.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 32]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Below, the semantics of the Local and Remote descriptors are
+   specified in detail.  The specification consists of two parts.  The
+   first part specifies the interpretation of the contents of the
+   descriptor.  The second part specifies the actions the MG must take
+   upon receiving the Local and Remote descriptors.  The actions to be
+   taken by the MG depend on the values of the ReserveValue and
+   ReserveGroup properties of the LocalControl descriptor.
+
+   Either the Local or the Remote descriptor or both may be:
+
+   1) unspecified (i.e., absent);
+
+   2) empty;
+
+   3) underspecified through use of CHOOSE in a property value;
+
+   4) fully specified; or
+
+   5) overspecified through presentation of multiple groups of
+      properties and possibly multiple property values in one or more of
+      these groups.
+
+   Where the descriptors have been passed from the MGC to the MG, they
+   are interpreted according to the rules given in 7.1.1, with the
+   following additional comments for clarification:
+
+   a) An unspecified Local or Remote descriptor is considered to be a
+      missing mandatory parameter.  It requires the MG to use whatever
+      was last specified for that descriptor.  It is possible that there
+      was no previously specified value, in which case the descriptor
+      concerned is ignored in further processing of the command.
+
+   b) An empty Local (Remote) descriptor in a message from the MGC
+      signifies a request to release any resources reserved for the
+      media flow received (sent).
+
+   c) If multiple groups of properties are present in a Local or Remote
+      descriptor or multiple values within a group, the order of
+      preference is descending.
+
+   d) Underspecified or overspecified properties within a group of
+      properties sent by the MGC are requests for the MG to choose one
+      or more values which it can support for each of those properties.
+      In case of an overspecified property, the list of values is in
+      descending order of preference.
+
+   Subject to the above rules, subsequent action depends on the values
+   of the ReserveValue and ReserveGroup properties in LocalControl.
+
+
+
+Groves, et al.              Standards Track                    [Page 33]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   If ReserveGroup is True, the MG reserves the resources required to
+   support any of the requested property group alternatives that it can
+   currently support.  If ReserveValue is True, the MG reserves the
+   resources required to support any of the requested property value
+   alternatives that it can currently support.
+
+   NOTE - If a Local or Remote descriptor contains multiple groups of
+   properties, and ReserveGroup is True, then the MG is requested to
+   reserve resources so that it can decode or encode the media stream
+   according to any of the alternatives.  For instance, if the Local
+   descriptor contains two groups of properties, one specifying
+   packetized G.711 A-law audio and the other G.723.1 audio, the MG
+   reserves resources so that it can decode one audio stream encoded in
+   either G.711 A-law format or G.723.1 format.  The MG does not have to
+   reserve resources to decode two audio streams simultaneously, one
+   encoded in G.711 A-law and one in G.723.1.  The intention for the use
+   of ReserveValue is analogous.
+
+   If ReserveGroup is true or ReserveValue is True, then the following
+   rules apply:
+
+   -  If the MG has insufficient resources to support all alternatives
+      requested by the MGC and the MGC requested resources in both Local
+      and Remote, the MG should reserve resources to support at least
+      one alternative each within Local and Remote.
+
+   -  If the MG has insufficient resources to support at least one
+      alternative within a Local (Remote) descriptor received from the
+      MGC, it shall return an empty Local (Remote) in response.
+
+   -  In its response to the MGC, when the MGC included Local and Remote
+      descriptors, the MG SHALL include Local and Remote descriptors for
+      all groups of properties and property values it reserved resources
+      for.  If the MG is incapable of supporting at least one of the
+      alternatives within the Local (Remote) descriptor received from
+      the MGC, it SHALL return an empty Local (Remote) descriptor.
+
+   -  If the Mode property of the LocalControl descriptor is RecvOnly,
+      SendRecv, or LoopBack, the MG must be prepared to receive media
+      encoded according to any of the alternatives included in its
+      response to the MGC.
+
+   If ReserveGroup is False and ReserveValue is False, then the MG
+   SHOULD apply the following rules to resolve Local and Remote to a
+   single alternative each:
+
+   -  The MG chooses the first alternative in Local for which it is able
+      to support at least one alternative in Remote.
+
+
+
+Groves, et al.              Standards Track                    [Page 34]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  If the MG is unable to support at least one Local and one Remote
+      alternative, it returns Error 510 (Insufficient Resources).
+
+   -  The MG returns its selected alternative in each of Local and
+      Remote.
+
+   A new setting of a Local or Remote descriptor completely replaces the
+   previous setting of that descriptor in the MG.  Thus, to retain
+   information from the previous setting, the MGC must include that
+   information in the new setting.  If the MGC wishes to delete some
+   information from the existing descriptor, it merely resends the
+   descriptor (in a Modify command) with the unwanted information
+   stripped out.
+
+7.1.9 Events descriptor
+
+   The EventsDescriptor parameter contains a RequestIdentifier and a
+   list of events that the Media Gateway is requested to detect and
+   report.  The RequestIdentifier is used to correlate the request with
+   the notifications that it may trigger.  Requested events include, for
+   example, fax tones, continuity test results, and on-hook and off-hook
+   transitions.  The RequestIdentifier is omitted if the
+   EventsDescriptor is empty (i.e., no events are specified).
+
+   Each event in the descriptor contains the Event name, an optional
+   streamID, an optional KeepActive flag, and optional parameters.  The
+   Event name consists of a Package Name (where the event is defined)
+   and an EventID.  The ALL wildcard may be used for the EventID,
+   indicating that all events from the specified package have to be
+   detected.  The default streamID is 0, indicating that the event to be
+   detected is not related to a particular media stream.  Events can
+   have parameters.  This allows a single event description to have some
+   variation in meaning without creating large numbers of individual
+   events.  Further event parameters are defined in the package.
+
+   If a digit map completion event is present or implied in the
+   EventsDescriptor, the EventDM parameter is used to carry either the
+   name or the value of the associated digit map.  See 7.1.14 for
+   further details.
+
+   When an event is processed against the contents of an active Events
+   Descriptor and found to be present in that descriptor ("recognized"),
+   the default action of the MG is to send a Notify command to the MGC.
+   Notification may be deferred if the event is absorbed into the
+   current dial string of an active digit map (see 7.1.14).  Any other
+   action is for further study.  Moreover, event recognition may cause
+   currently active signals to stop, or may cause the current Events
+   and/or Signals descriptor to be replaced, as described at the end of
+
+
+
+Groves, et al.              Standards Track                    [Page 35]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   this subclause.  Unless the Events Descriptor is replaced by another
+   Events Descriptor, it remains active after an event has been
+   recognized.
+
+   If the value of the EventBufferControl property equals LockStep,
+   following detection of such an event, normal handling of events is
+   suspended.  Any event which is subsequently detected and occurs in
+   the EventBuffer descriptor is added to the end of the EventBuffer (a
+   FIFO queue), along with the time that it was detected.  The MG SHALL
+   wait for a new EventsDescriptor to be loaded.  A new EventsDescriptor
+   can be loaded either as the result of receiving a command with a new
+   EventsDescriptor, or by activating an embedded EventsDescriptor.
+
+   If EventBufferControl equals Off, the MG continues processing based
+   on the active EventsDescriptor.
+
+   In the case of an embedded EventsDescriptor being activated, the MG
+   continues event processing based on the newly activated
+   EventsDescriptor.
+
+     NOTE 1 - For purposes of EventBuffer handling, activation of an
+     embedded EventsDescriptor is equivalent to receipt of a new
+     EventsDescriptor.
+
+   When the MG receives a command with a new EventsDescriptor, one or
+   more events may have been buffered in the EventBuffer in the MG.  The
+   value of EventBufferControl then determines how the MG treats such
+   buffered events.
+
+   Case 1
+
+   If EventBufferControl equals LockStep and the MG receives a new
+   EventsDescriptor, it will check the FIFO EventBuffer and take the
+   following actions:
+
+   1) If the EventBuffer is empty, the MG waits for detection of events
+      based on the new EventsDescriptor.
+
+   2) If the EventBuffer is non-empty, the MG processes the FIFO queue
+      starting with the first event:
+
+      a) If the event in the queue is in the events listed in the new
+         EventsDescriptor, the MG acts on the event and removes the
+         event from the EventBuffer.  The time stamp of the Notify shall
+         be the time the event was actually detected.  The MG then waits
+         for a new EventsDescriptor.  While waiting for a new
+         EventsDescriptor, any events detected that appear in the
+
+
+
+
+Groves, et al.              Standards Track                    [Page 36]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         EventsBufferDescriptor will be placed in the EventBuffer.  When
+         a new EventsDescriptor is received, the event processing will
+         repeat from step 1.
+
+      b) If the event is not in the new EventsDescriptor, the MG SHALL
+         discard the event and repeat from step 1.
+
+   Case 2
+
+   If EventBufferControl equals Off and the MG receives a new
+   EventsDescriptor, it processes new events with the new
+   EventsDescriptor.
+
+   If the MG receives a command instructing it to set the value of
+   EventBufferControl to Off, all events in the EventBuffer SHALL be
+   discarded.
+
+   The MG may report several events in a single Transaction as long as
+   this does not unnecessarily delay the reporting of individual events.
+
+   For procedures regarding transmitting the Notify command, refer to
+   the appropriate annex or Recommendation of the H.248 sub-series for
+   specific transport considerations.
+
+   The default value of EventBufferControl is Off.
+
+     NOTE 2 - Since the EventBufferControl property is in the
+     TerminationStateDescriptor, the MG might receive a command that
+     changes the EventBufferControl property and does not include an
+     EventsDescriptor.
+
+   Normally, recognition of an event shall cause any active signals to
+   stop.  When KeepActive is specified in the event, the MG shall not
+   interrupt any signals active on the Termination on which the event is
+   detected.
+
+   An event can include an Embedded Signals descriptor and/or an
+   Embedded Events descriptor which, if present, replaces the current
+   Signals/Events descriptor when the event is recognized.  It is
+   possible, for example, to specify that the dial-tone Signal be
+   generated when an off-hook Event is recognized, or that the dial-tone
+   Signal be stopped when a digit is recognized.  A media gateway
+   controller shall not send EventsDescriptors with an event both marked
+   KeepActive and containing an embedded SignalsDescriptor.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 37]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Only one level of embedding is permitted.  An embedded
+   EventsDescriptor SHALL NOT contain another embedded EventsDescriptor;
+   an embedded EventsDescriptor MAY contain an embedded
+   SignalsDescriptor.
+
+   An EventsDescriptor received by a media gateway replaces any previous
+   Events descriptor.  Event notification in process shall complete, and
+   events detected after the command containing the new EventsDescriptor
+   executes, shall be processed according to the new EventsDescriptor.
+
+   An empty Events Descriptor disables all event recognition and
+   reporting.  An empty EventBuffer Descriptor clears the EventBuffer
+   and disables all event accumulation in LockStep mode: the only events
+   reported will be those occurring while an Events Descriptor is
+   active.  If an empty Events Descriptor is activated while the
+   Termination is operating in LockStep mode, the events buffer is
+   immediately cleared.
+
+7.1.10   EventBuffer descriptor
+
+   The EventBuffer descriptor contains a list of events, with their
+   parameters if any, that the MG is requested to detect and buffer when
+   EventBufferControl equals LockStep (see 7.1.9).
+
+7.1.11   Signals descriptor
+
+   Signals are MG generated media such as tones and announcements as
+   well as bearer-related signals such as hookswitch.  More complex
+   signals may include a sequence of such simple signals interspersed
+   with and conditioned upon the receipt and analysis of media or
+   bearer-related signals.  Examples include echoing of received data as
+   in Continuity Test package.  Signals may also request preparation of
+   media content for future signals.
+
+   A SignalsDescriptor is a parameter that contains the set of signals
+   that the Media Gateway is asked to apply to a Termination.  A
+   SignalsDescriptor contains a number of signals and/or sequential
+   signal lists.  A SignalsDescriptor may contain zero signals and
+   sequential signal lists.  Support of sequential signal lists is
+   optional.
+
+   Signals are defined in packages.  Signals shall be named with a
+   Package name (in which the signal is defined) and a SignalID.  No
+   wildcard shall be used in the SignalID.  Signals that occur in a
+   SignalsDescriptor have an optional StreamID parameter (default is 0,
+   to indicate that the signal is not related to a particular media
+   stream), an optional signal type (see below), an optional duration
+   and possibly parameters defined in the package that defines the
+
+
+
+Groves, et al.              Standards Track                    [Page 38]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   signal.  This allows a single signal to have some variation in
+   meaning, obviating the need to create large numbers of individual
+   signals.
+
+   Finally, the optional parameter "notifyCompletion" allows a MGC to
+   indicate that it wishes to be notified when the signal finishes
+   playout.  The possible cases are that the signal timed out (or
+   otherwise completed on its own), that it was interrupted by an event,
+   that it was halted when a Signals descriptor was replaced, or that it
+   stopped or never started for other reasons.  If the notifyCompletion
+   parameter is not included in a Signals descriptor, notification is
+   generated only if the signal stopped or was never started for other
+   reasons.  For reporting to occur, the signal completion event (see
+   E.1.2) must be enabled in the currently active Events descriptor.
+
+   The duration is an integer value that is expressed in hundredths of a
+   second.
+
+   There are three types of signals:
+
+   -  on/off - the signal lasts until it is turned off;
+
+   -  timeout - the signal lasts until it is turned off or a specific
+      period of time elapses;
+
+   -  brief - the signal will stop on its own unless a new Signals
+      descriptor is applied that causes it to stop; no timeout value is
+      needed.
+
+   If a signal of default type other than TO has its type overridden to
+   type TO in the Signals descriptor, the duration parameter must be
+   present.
+
+   If the signal type is specified in a SignalsDescriptor, it overrides
+   the default signal type (see 12.1.4).  If duration is specified for
+   an on/off signal, it SHALL be ignored.
+
+   A sequential signal list consists of a signal list identifier and a
+   sequence of signals to be played sequentially.  Only the trailing
+   element of the sequence of signals in a sequential signal list may be
+   an on/off signal.  The duration of a sequential signal list is the
+   sum of the durations of the signals it contains.
+
+   Multiple signals and sequential signal lists in the same
+   SignalsDescriptor shall be played simultaneously.
+
+   Signals are defined as proceeding from the Termination towards the
+   exterior of the Context unless otherwise specified in a package.
+
+
+
+Groves, et al.              Standards Track                    [Page 39]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   When the same Signal is applied to multiple Terminations within one
+   Transaction, the MG should consider using the same resource to
+   generate these Signals.
+
+   Production of a Signal on a Termination is stopped by application of
+   a new SignalsDescriptor, or detection of an Event on the Termination
+   (see 7.1.9).
+
+   A new SignalsDescriptor replaces any existing SignalsDescriptor.  Any
+   signals applied to the Termination not in the replacement descriptor
+   shall be stopped, and new signals are applied, except as follows.
+   Signals present in the replacement descriptor and containing the
+   KeepActive flag shall be continued if they are currently playing and
+   have not already completed.  If a replacement signal descriptor
+   contains a signal that is not currently playing and contains the
+   KeepActive flag, that signal SHALL be ignored.  If the replacement
+   descriptor contains a sequential signal list with the same identifier
+   as the existing descriptor, then
+
+   -  the signal type and sequence of signals in the sequential signal
+      list in the replacement descriptor shall be ignored; and
+
+   -  the playing of the signals in the sequential signal list in the
+      existing descriptor shall not be interrupted.
+
+7.1.12   Audit descriptor
+
+   The Audit descriptor specifies what information is to be audited.
+   The Audit descriptor specifies the list of descriptors to be
+   returned.  Audit may be used in any command to force the return of
+   any descriptor containing the current values of its properties,
+   events, signals and statistics even if that descriptor was not
+   present in the command, or had no underspecified parameters.
+   Possible items in the Audit descriptor are:
+
+      Modem
+      Mux
+      Events
+      Media
+      Signals
+      ObservedEvents
+      DigitMap
+      Statistics
+      Packages
+      EventBuffer
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 40]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Audit may be empty, in which case, no descriptors are returned.  This
+   is useful in Subtract, to inhibit return of statistics, especially
+   when using wildcard.
+
+7.1.13   ServiceChange descriptor
+
+   The ServiceChangeDescriptor contains the following parameters:
+
+      .  ServiceChangeMethod
+      .  ServiceChangeReason
+      .  ServiceChangeAddress
+      .  ServiceChangeDelay
+      .  ServiceChangeProfile
+      .  ServiceChangeVersion
+      .  ServiceChangeMGCId
+      .  TimeStamp
+      .  Extension
+
+   See 7.2.8.
+
+7.1.14   DigitMap descriptor
+
+7.1.14.1 DigitMap definition, creation, modification and deletion
+
+   A DigitMap is a dialing plan resident in the Media Gateway used for
+   detecting and reporting digit events received on a Termination.  The
+   DigitMap descriptor contains a DigitMap name and the DigitMap to be
+   assigned.  A digit map may be preloaded into the MG by management
+   action and referenced by name in an EventsDescriptor, may be defined
+   dynamically and subsequently referenced by name, or the actual
+   digitmap itself may be specified in the EventsDescriptor.  It is
+   permissible for a digit map completion event within an Events
+   descriptor to refer by name to a DigitMap which is defined by a
+   DigitMap descriptor within the same command, regardless of the
+   transmitted order of the respective descriptors.
+
+   DigitMaps defined in a DigitMapDescriptor can occur in any of the
+   standard Termination manipulation Commands of the protocol.  A
+   DigitMap, once defined, can be used on all Terminations specified by
+   the (possibly wildcarded) TerminationID in such a command.  DigitMaps
+   defined on the root Termination are global and can be used on every
+   Termination in the MG, provided that a DigitMap with the same name
+   has not been defined on the given Termination.  When a DigitMap is
+   defined dynamically in a DigitMap descriptor:
+
+   -  A new DigitMap is created by specifying a name that is not yet
+      defined.  The value shall be present.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 41]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  A DigitMap value is updated by supplying a new value for a name
+      that is already defined.  Terminations presently using the
+      digitmap shall continue to use the old definition; subsequent
+      EventsDescriptors specifying the name, including any
+      EventsDescriptor in the command containing the DigitMap
+      descriptor, shall use the new one.
+
+   -  A DigitMap is deleted by supplying an empty value for a name that
+      is already defined.  Terminations presently using the digitmap
+      shall continue to use the old definition.
+
+7.1.14.2 DigitMap Timers
+
+   The collection of digits according to a DigitMap may be protected by
+   three timers, viz. a start timer (T), short timer (S), and long timer
+   (L).
+
+   1) The start timer (T) is used prior to any digits having been
+      dialed.  If the start timer is overridden with the value set to
+      zero (T=0), then the start timer shall be disabled.  This implies
+      that the MG will wait indefinitely for digits.
+
+   2) If the Media Gateway can determine that at least one more digit is
+      needed for a digit string to match any of the allowed patterns in
+      the digit map, then the interdigit timer value should be set to a
+      long (L) duration (e.g., 16 seconds).
+
+   3) If the digit string has matched one of the patterns in a digit
+      map, but it is possible that more digits could be received which
+      would cause a match with a different pattern, then instead of
+      reporting the match immediately, the MG must apply the short timer
+      (S) and wait for more digits.
+
+   The timers are configurable parameters to a DigitMap.  Default values
+   of these timers should be provisioned on the MG, but can be
+   overridden by values specified within the DigitMap.
+
+7.1.14.3 DigitMap Syntax
+
+   The formal syntax of the digit map is described by the DigitMap rule
+   in the formal syntax description of the protocol (see Annex A and
+   Annex B).  A DigitMap, according to this syntax, is defined either by
+   a string or by a list of strings.  Each string in the list is an
+   alternative event sequence, specified either as a sequence of digit
+   map symbols or as a regular expression of digit map symbols.  These
+   digit map symbols, the digits "0" through "9" and letters "A" through
+   a maximum value depending on the signalling system concerned, but
+   never exceeding "K", correspond to specified events within a package
+
+
+
+Groves, et al.              Standards Track                    [Page 42]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   which has been designated in the Events descriptor on the Termination
+   to which the digit map is being applied.  (The mapping between events
+   and digit map symbols is defined in the documentation for packages
+   associated with channel-associated signalling systems such as DTMF,
+   MF, or R2.  Digits "0" through "9" MUST be mapped to the
+   corresponding digit events within the signalling system concerned.
+   Letters should be allocated in logical fashion, facilitating the use
+   of range notation for alternative events.)
+
+   The letter "x" is used as a wildcard, designating any event
+   corresponding to symbols in the range "0"-"9".  The string may also
+   contain explicit ranges and, more generally, explicit sets of
+   symbols, designating alternative events any one of which satisfies
+   that position of the digit map.  Finally, the dot symbol "." stands
+   for zero or more repetitions of the event selector (event, range of
+   events, set of alternative events, or wildcard) that precedes it.  As
+   a consequence of the third timing rule above, inter-event timing
+   while matching a terminal dot symbol uses the short timer by default.
+
+   In addition to these event symbols, the string may contain "S" and
+   "L" inter-event timing specifiers and the "Z" duration modifier.  "S"
+   and "L" respectively indicate that the MG should use the short (S)
+   timer or the long (L) timer for subsequent events, overriding the
+   timing rules described above.  If an explicit timing specifier is in
+   effect in one alternative event sequence, but none is given in any
+   other candidate alternative, the timer value set by the explicit
+   timing specifier must be used.  If all sequences with explicit timing
+   controls are dropped from the candidate set, timing reverts to the
+   default rules given above.  Finally, if conflicting timing specifiers
+   are in effect in different alternative sequences, the long timer
+   shall be used.
+
+   A "Z" designates a long duration event: placed in front of the
+   symbol(s) designating the event(s) which satisfy a given digit
+   position, it indicates that that position is satisfied only if the
+   duration of the event exceeds the long-duration threshold.  The value
+   of this threshold is assumed to be provisioned in the MG.
+
+7.1.14.4 DigitMap Completion Event
+
+   A digit map is active while the Events descriptor which invoked it is
+   active and it has not completed.  A digit map completes when:
+
+   -  a timer has expired; or
+
+   -  an alternative event sequence has been matched and no other
+      alternative event sequence in the digit map could be matched
+      through detection of an additional event (unambiguous match); or
+
+
+
+Groves, et al.              Standards Track                    [Page 43]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  an event has been detected such that a match to a complete
+      alternative event sequence of the digit map will be impossible no
+      matter what additional events are received.
+
+   Upon completion, a digit map completion event as defined in the
+   package providing the events being mapped into the digit map shall be
+   generated.  At that point the digit map is deactivated.  Subsequent
+   events in the package are processed as per the currently active event
+   processing mechanisms.
+
+7.1.14.5 DigitMap Procedures
+
+   Pending completion, successive events shall be processed according to
+   the following rules:
+
+   1) The "current dial string", an internal variable, is initially
+      empty.  The set of candidate alternative event sequences includes
+      all of the alternatives specified in the digit map.
+
+   2) At each step, a timer is set to wait for the next event, based
+      either on the default timing rules given above or on explicit
+      timing specified in one or more alternative event sequences.  If
+      the timer expires and a member of the candidate set of
+      alternatives is fully satisfied, a timeout completion with full
+      match is reported.  If the timer expires and part or none of any
+      candidate alternative is satisfied, a timeout completion with
+      partial match is reported.
+
+   3) If an event is detected before the timer expires, it is mapped to
+      a digit string symbol and provisionally added to the end of the
+      current dial string.  The duration of the event (long or not long)
+      is noted if and only if this is relevant in the current symbol
+      position (because at least one of the candidate alternative event
+      sequences includes the "Z" modifier at this position in the
+      sequence).
+
+   4) The current dial string is compared to the candidate alternative
+      event sequences.  If and only if a sequence expecting a
+      long-duration event at this position is matched (i.e., the event
+      had long duration and met the specification for this position),
+      then any alternative event sequences not specifying a long
+      duration event at this position are discarded, and the current
+      dial string is modified by inserting a "Z" in front of the symbol
+      representing the latest event.   Any sequence expecting a long-
+      duration event at this position but not matching the observed
+      event is discarded from the candidate set.  If alternative event
+      sequences not specifying a long duration event in the given
+
+
+
+
+Groves, et al.              Standards Track                    [Page 44]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      position remain in the candidate set after application of the
+      above rules, the observed event duration is treated as irrelevant
+      in assessing matches to them.
+
+   5) If exactly one candidate remains and it has been fully matched, a
+      completion event is generated indicating an unambiguous match.  If
+      no candidates remain, the latest event is removed from the current
+      dial string and a completion event is generated indicating full
+      match if one of the candidates from the previous step was fully
+      satisfied before the latest event was detected, or partial match
+      otherwise.  The event removed from the current dial string will
+      then be reported as per the currently active event processing
+      mechanisms.
+
+   6) If no completion event is reported out of step 5, processing
+      returns to step 2.
+
+7.1.14.6 DigitMap Activation
+
+   A digit map is activated whenever a new Event descriptor is applied
+   to the Termination or embedded Event descriptor is activated, and
+   that Event descriptor contains a digit map completion event.  The
+   digit map completion event contains an eventDM field in the requested
+   actions field.  Each new activation of a digit map begins at step 1
+   of the above procedure, with a clear current dial string.  Any
+   previous contents of the current dial string from an earlier
+   activation are lost.
+
+   A digit map completion event that does not contain an eventDM field
+   in its requested actions field is considered an error.  Upon receipt
+   of such an event in an EventsDescriptor, a MG shall respond with an
+   error response, including Error 457 - Missing parameter in signal or
+   event.
+
+7.1.14.7 Interaction Of DigitMap and Event Processing
+
+   While the digit map is activated, detection is enabled for all events
+   defined in the package containing the specified digit map completion
+   event.  Normal event behaviour (e.g., stopping of signals unless the
+   digit completion event has the KeepActive flag enabled) continues to
+   apply for each such event detected, except that:
+
+   -  the events in the package containing the specified digit map
+      completion event other than the completion event itself are not
+      individually notified and have no side-effects unless separately
+      enabled; and
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 45]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  an event that triggers a partial match completion event is not
+      recognized and therefore has no side effects until reprocessed
+      following the recognition of the digit map completion event.
+
+7.1.14.8 Wildcards
+
+   Note that if a package contains a digit map completion event, then an
+   event specification consisting of the package name with a wildcarded
+   ItemID (Property Name) will activate a digit map; to that end, the
+   event specification must include an eventDM field according to
+   section 7.1.14.6.  If the package also contains the digit events
+   themselves, this form of event specification will cause the
+   individual events to be reported to the MGC as they are detected.
+
+7.1.14.9 Example
+
+   As an example, consider the following dial plan:
+
+   0                      Local operator
+
+   00                     Long-distance operator
+
+   xxxx                   Local extension number (starts with 1-7)
+
+   8xxxxxxx               Local number
+
+   #xxxxxxx               Off-site extension
+
+   *xx                    Star services
+
+   91xxxxxxxxxx           Long-distance number
+
+   9011 + up to 15 digits International number
+
+
+
+   If the DTMF detection package described in E.6 is used to collect the
+   dialed digits, then the dialing plan shown above results in the
+   following digit map:
+
+    (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)
+
+7.1.15   Statistics descriptor
+
+   The Statistics Descriptor provides information describing the status
+   and usage of a Termination during its existence within a specific
+   Context.  There is a set of standard statistics kept for each
+   Termination where appropriate (number of octets sent and received for
+
+
+
+Groves, et al.              Standards Track                    [Page 46]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   example).  The particular statistical properties that are reported
+   for a given Termination are determined by the Packages realized by
+   the Termination.  By default, statistics are reported when the
+   Termination is Subtracted from the Context.  This behaviour can be
+   overridden by including an empty AuditDescriptor in the Subtract
+   command.  Statistics may also be returned from the AuditValue
+   command, or any Add/Move/Modify command using the Audit descriptor.
+
+   Statistics are cumulative; reporting Statistics does not reset them.
+   Statistics are reset when a Termination is Subtracted from a Context.
+
+7.1.16   Packages descriptor
+
+   Used only with the AuditValue command, the PackageDescriptor returns
+   a list of Packages realized by the Termination.
+
+7.1.17   ObservedEvents descriptor
+
+   ObservedEvents is supplied with the Notify command to inform the MGC
+   of which event(s) were detected.  Used with the AuditValue command,
+   the ObservedEventsDescriptor returns events in the event buffer which
+   have not been Notified.  ObservedEvents contains the
+   RequestIdentifier of the EventsDescriptor that triggered the
+   notification, the event(s) detected, optionally the detection time(s)
+   and any parameters of the observed event.  Detection times are
+   reported with a precision of hundredths of a second.
+
+7.1.18   Topology descriptor
+
+   A Topology descriptor is used to specify flow directions between
+   Terminations in a Context.  Contrary to the descriptors in previous
+   subclauses, the Topology descriptor applies to a Context instead of a
+   Termination.  The default topology of a Context is that each
+   Termination's transmission is received by all other Terminations.
+   The Topology descriptor is optional to implement.  An MG that does
+   not support Topology descriptors, but receives a command containing
+   one, returns Error 444 Unsupported or unknown descriptor, and
+   optionally includes a string containing the name of the unsupported
+   Descriptor ("Topology") in the error text in the error descriptor.
+
+   The Topology descriptor occurs before the commands in an action.  It
+   is possible to have an action containing only a Topology descriptor,
+   provided that the Context to which the action applies already exists.
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 47]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   A Topology descriptor consists of a sequence of triples of the form
+   (T1, T2, association).  T1 and T2 specify Terminations within the
+   Context, possibly using the ALL or CHOOSE wildcard.  The association
+   specifies how media flows between these two Terminations as follows.
+
+   -  (T1, T2, isolate) means that the Terminations matching T2 do not
+      receive media from the Terminations matching T1, nor vice versa.
+
+   -  (T1, T2, oneway) means that the Terminations that match T2 receive
+      media from the Terminations matching T1, but not vice versa.  In
+      this case use of the ALL wildcard such that there are Terminations
+      that match both T1 and T2 is not allowed.
+
+   -  (T1, T2, bothway) means that the Terminations matching T2 receive
+      media from the Terminations matching T1, and vice versa.  In this
+      case it is allowed to use wildcards such that there are
+      Terminations that match both T1 and T2.  However, if there is a
+      Termination that matches both, no loopback is introduced.
+
+   CHOOSE wildcards may be used in T1 and T2 as well, under the
+   following restrictions:
+
+   -  the action (see clause 8) of which the topology descriptor is part
+      contains an Add command in which a CHOOSE wildcard is used;
+
+   -  if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL
+      NOT be specified.
+
+   The CHOOSE wildcard in a Topology descriptor matches the
+   TerminationID that the MG assigns in the first Add command that uses
+   a CHOOSE wildcard in the same action.  An existing Termination that
+   matches T1 or T2 in the Context to which a Termination is added, is
+   connected to the newly added Termination as specified by the Topology
+   descriptor.
+
+   If a termination is not mentioned within a Topology Descriptor, any
+   topology associated with it remains unchanged.  If, however, a new
+   termination is added into a context its association with the other
+   terminations within the context defaults to bothway, unless a
+   Topology Descriptor is given to change this (e.g., if T3 is added to
+   a context with T1 and T2 with topology (T3, T1, oneway) it will be
+   connected bothway to T2).
+
+   Figure 7 and the table following it show some examples of the effect
+   of including topology descriptors in actions.  In these examples it
+   is assumed that the topology descriptors are applied in sequence.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 48]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+     +------------------+  +------------------+  +------------------+
+     |      +----+      |  |      +----+      |  |      +----+      |
+     |      | T2 |      |  |      | T2 |      |  |      | T2 |      |
+     |      +----+      |  |      +----+      |  |      +----+      |
+     |       ^  ^       |  |          ^       |  |          ^       |
+     |       |  |       |  |          |       |  |          |       |
+     |    +--+  +--+    |  |          +---+   |  |          +--+    |
+     |    |        |    |  |              |   |  |             |    |
+     |    v        v    |  |              v   |  |             |    |
+     | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
+     | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |
+     | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
+     +------------------+  +------------------+  +------------------+
+     1. No Topology Desc.   2. T1, T2, Isolate    3. T3, T2, Oneway
+
+     +------------------+  +------------------+  +------------------+
+     |      +----+      |  |      +----+      |  |      +----+      |
+     |      | T2 |      |  |      | T2 |      |  |      | T2 |      |
+     |      +----+      |  |      +----+      |  |      +----+      |
+     |          |       |  |          ^       |  |       ^  ^       |
+     |          |       |  |          |       |  |       |  |       |
+     |          +--+    |  |          +---+   |  |    +--+  +--+    |
+     |             |    |  |              |   |  |    |        |    |
+     |             v    |  |              v   |  |    v        v    |
+     | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
+     | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |
+     | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
+     +------------------+  +------------------+  +------------------+
+     4. T2, T3 oneway      5. T2, T3 bothway     6. T1, T2 bothway
+
+     Note: the direction of the arrow indicates the direction of flow.
+
+                       Figure 7: Example topologies
+
+   Topology Description
+
+   1 No topology descriptors    When no topology descriptors are
+                                included, all Terminations have a
+                                bothway connection to all other
+                                Terminations.
+
+   2 T1, T2 Isolate             Removes the connection between T1 and
+                                T2.  T3 has a bothway connection with
+                                both T1 and T2.  T1 and T2 have bothway
+                                connection to T3.
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 49]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   3 T3, T2 oneway              A oneway connection from T3 to T2 (i.e.,
+                                T2 receives media flow from T3).  A
+                                bothway connection between T1 and T3.
+
+   4 T2, T3 oneway              A oneway connection between T2 to T3.
+                                T1 and T3 remain bothway connected.
+
+   5 T2, T3 bothway             T2 is bothway connected to T3.  This
+                                results in the same as 2.
+
+   6 T1, T2 bothway (T2, T3     All Terminations have a bothway
+     bothway and T1, T3         connection to all other Terminations.
+     bothway may be implied or
+     explicit).
+
+   A oneway connection must be implemented in such a way that the other
+   Terminations in the Context are not aware of the change in topology.
+
+7.1.19   Error Descriptor
+
+   If a responder encounters an error when processing a transaction
+   request, it must include an error descriptor in its response.  A
+   Notify request may contain an error descriptor as well.
+
+   An error descriptor consists of an IANA-registered error code,
+   optionally accompanied by an error text.  H.248.8 contains a list of
+   valid error codes and error descriptions.
+
+   An error descriptor shall be specified at the "deepest level" that is
+   semantically appropriate for the error being described and that is
+   possible given any parsing problems with the original request.  An
+   error descriptor may refer to a syntactical construct other than
+   where it appears.  For example, Error descriptor 422 - Syntax Error
+   in Action, could appear within a command even though it refers to the
+   larger construct - the action - and not the particular command within
+   which it appears.
+
+7.2   Command Application Programming Interface
+
+   Following is an Application Programming Interface (API) describing
+   the Commands of the protocol.  This API is shown to illustrate the
+   Commands and their parameters and is not intended to specify
+   implementation (e.g., via use of blocking function calls).  It
+   describes the input parameters in parentheses after the command name
+   and the return values in front of the Command.  This is only for
+   descriptive purposes; the actual Command syntax and encoding are
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 50]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   specified in later subclauses.  The order of parameters to commands
+   is not fixed.  Descriptors may appear as parameters to commands in
+   any order.  The descriptors SHALL be processed in the order in which
+   they appear.
+
+   Any reply to a command may contain an error descriptor; the API does
+   not specifically show this.
+
+   All parameters enclosed by square brackets ([. . .]) are considered
+   optional.
+
+7.2.1 Add
+
+   The Add Command adds a Termination to a Context.
+
+     TerminationID
+     [,MediaDescriptor]
+     [,ModemDescriptor]
+     [,MuxDescriptor]
+     [,EventsDescriptor]
+     [,SignalsDescriptor]
+     [,DigitMapDescriptor]
+     [,ObservedEventsDescriptor]
+     [,EventBufferDescriptor]
+     [,StatisticsDescriptor]
+     [,PackagesDescriptor]
+       Add( TerminationID
+        [, MediaDescriptor]
+        [, ModemDescriptor]
+        [, MuxDescriptor]
+        [, EventsDescriptor]
+        [, EventBufferDescriptor]
+        [, SignalsDescriptor]
+        [, DigitMapDescriptor]
+        [, AuditDescriptor]
+        )
+
+   The TerminationID specifies the Termination to be added to the
+   Context.  The Termination is either created, or taken from the null
+   Context.  If a CHOOSE wildcard is used in the TerminationID, the
+   selected TerminationID will be returned.  Wildcards may be used in an
+   Add, but such usage would be unusual.  If the wildcard matches more
+   than one TerminationID, all possible matches are attempted, with
+   results reported for each one.  The order of attempts when multiple
+   TerminationIDs match is not specified.
+
+   The optional MediaDescriptor describes all media streams.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 51]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The optional ModemDescriptor and MuxDescriptor specify a modem and
+   multiplexer if applicable.  For convenience, if a Multiplex
+   descriptor is present in an Add command and lists any Terminations
+   that are not currently in the Context, such Terminations are added to
+   the Context as if individual Add commands listing the Terminations
+   were invoked. If an error occurs on such an implied Add, error 471 -
+   Implied Add for Multiplex failure shall be returned and further
+   processing of the command shall cease.
+
+   The EventsDescriptor parameter is optional.  If present, it provides
+   the list of events that should be detected on the Termination.
+
+   The EventBufferDescriptor parameter is optional.  If present, it
+   provides the list of events that the MG is requested to detect and
+   buffer when EventBufferControl equals LockStep.
+
+   The SignalsDescriptor parameter is optional.  If present, it provides
+   the list of signals that should be applied to the Termination.
+
+   The DigitMapDescriptor parameter is optional.  If present, it defines
+   a DigitMap definition that may be used in an EventsDescriptor.
+
+   The AuditDescriptor is optional.  If present, the command will return
+   descriptors as specified in the AuditDescriptor.
+
+   All descriptors that can be modified could be returned by MG if a
+   parameter was underspecified or overspecified.  ObservedEvents,
+   Statistics, and Packages, and the EventBuffer descriptors are
+   returned only if requested in the AuditDescriptor.
+
+   Add SHALL NOT be used on a Termination with a serviceState of
+   "OutofService".
+
+7.2.2 Modify
+
+   The Modify Command modifies the properties of a Termination.
+
+     TerminationID
+     [,MediaDescriptor]
+     [,ModemDescriptor]
+     [,MuxDescriptor]
+     [,EventsDescriptor]
+     [,SignalsDescriptor]
+     [,DigitMapDescriptor]
+     [,ObservedEventsDescriptor]
+     [,EventBufferDescriptor]
+     [,StatisticsDescriptor]
+     [,PackagesDescriptor]
+
+
+
+Groves, et al.              Standards Track                    [Page 52]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      Modify( TerminationID
+         [, MediaDescriptor]
+         [, ModemDescriptor]
+         [, MuxDescriptor]
+         [, EventsDescriptor]
+         [, EventBufferDescriptor]
+         [, SignalsDescriptor]
+         [, DigitMapDescriptor]
+         [, AuditDescriptor]
+         )
+
+   The TerminationID may be specific if a single Termination in the
+   Context is to be modified.  Use of wildcards in the TerminationID may
+   be appropriate for some operations.  If the wildcard matches more
+   than one TerminationID, all possible matches are attempted, with
+   results reported for each one.  The order of attempts when multiple
+   TerminationIDs match is not specified.  The CHOOSE option is an
+   error, as the Modify command may only be used on existing
+   Terminations.
+
+   For convenience, if a Multiplex Descriptor is present in a Modify
+   command, then:
+
+   -  if the new Multiplex Descriptor lists any Terminations that are
+      not currently in the Context, such Terminations are added to the
+      context as if individual commands listing the Terminations were
+      invoked.
+
+   -  if any Terminations listed previously in the Multiplex Descriptor
+      are no longer present in the new Multiplex Descriptor, they are
+      subtracted from the context as if individual Subtract commands
+      listing the Terminations were invoked.
+
+   The remaining parameters to Modify are the same as those to Add.
+   Possible return values are the same as those to Add.
+
+7.2.3 Subtract
+
+   The Subtract Command disconnects a Termination from its Context and
+   returns statistics on the Termination's participation in the Context.
+
+     TerminationID
+     [,MediaDescriptor]
+     [,ModemDescriptor]
+     [,MuxDescriptor]
+     [,EventsDescriptor]
+     [,SignalsDescriptor]
+     [,DigitMapDescriptor]
+
+
+
+Groves, et al.              Standards Track                    [Page 53]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+     [,ObservedEventsDescriptor]
+     [,EventBufferDescriptor]
+     [,StatisticsDescriptor]
+     [,PackagesDescriptor]
+      Subtract(TerminationID
+         [, AuditDescriptor]
+         )
+
+   TerminationID in the input parameters represents the Termination that
+   is being subtracted.  The TerminationID may be specific or may be a
+   wildcard value indicating that all (or a set of related) Terminations
+   in the Context of the Subtract Command are to be subtracted.  If the
+   wildcard matches more than one TerminationID, all possible matches
+   are attempted, with results reported for each one.  The order of
+   attempts when multiple TerminationIDs match is not specified.
+
+   The use of CHOOSE in the TerminationID is an error, as the Subtract
+   command may only be used on existing Terminations.
+
+   ALL may be used as the ContextID as well as the TerminationId in a
+   Subtract, which would have the effect of deleting all Contexts,
+   deleting all ephemeral Terminations, and returning all physical
+   Terminations to Null Context.  Subtract of a termination from the
+   Null Context is not allowed.
+
+   For convenience, if a multiplexing Termination is the object of a
+   Subtract command, then any bearer Terminations listed in its
+   Multiplex Descriptor are subtracted from the context as if individual
+   Subtract commands listing the Terminations were invoked.
+
+   By default, the Statistics parameter is returned to report
+   information collected on the Termination or Terminations specified in
+   the Command.  The information reported applies to the Termination's
+   or Terminations' existence in the Context from which it or they are
+   being subtracted.
+
+   The AuditDescriptor is optional.  If present, the command will return
+   only those descriptors as specified in the AuditDescriptor, which may
+   be empty.  If omitted, the Statistics descriptor is returned, by
+   default.  Possible return values are the same as those to Add.
+
+   When a provisioned Termination is Subtracted from a Context, its
+   property values shall revert to:
+
+   -  the default value, if specified for the property and not
+      overridden by provisioning;
+
+   -  otherwise, the provisioned value.
+
+
+
+Groves, et al.              Standards Track                    [Page 54]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+7.2.4 Move
+
+   The Move Command moves a Termination to another Context from its
+   current Context in one atomic operation.  The Move command is the
+   only command that refers to a Termination in a Context different from
+   that to which the command is applied.  The Move command shall not be
+   used to move Terminations to or from the null Context.
+
+     TerminationID
+     [,MediaDescriptor]
+     [,ModemDescriptor]
+     [,MuxDescriptor]
+     [,EventsDescriptor]
+     [,SignalsDescriptor]
+     [,DigitMapDescriptor]
+     [,ObservedEventsDescriptor]
+     [,EventBufferDescriptor]
+     [,StatisticsDescriptor]
+     [,PackagesDescriptor]
+      Move( TerminationID
+         [, MediaDescriptor]
+         [, ModemDescriptor]
+         [, MuxDescriptor]
+         [, EventsDescriptor]
+         [, EventBufferDescriptor]
+         [, SignalsDescriptor]
+         [, DigitMapDescriptor]
+         [, AuditDescriptor]
+         )
+
+   The TerminationID specifies the Termination to be moved.  It may be
+   wildcarded, but CHOOSE shall not be used in the TerminationID.  If
+   the wildcard matches more than one TerminationID, all possible
+   matches are attempted, with results reported for each one.  The order
+   of attempts when multiple TerminationIDs match is not specified.  The
+   Context to which the Termination is moved is indicated by the target
+   ContextId in the Action.  If the last remaining Termination is moved
+   out of a Context, the Context is deleted.
+
+   The Move command does not affect the properties of the Termination on
+   which it operates, except those properties explicitly modified by
+   descriptors included in the Move command.  The AuditDescriptor with
+   the Statistics option, for example, would return statistics on the
+   Termination just prior to the Move.  Possible descriptors returned
+   from Move are the same as for Add.
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 55]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   For convenience, if a multiplexing Termination is the object of a
+   Move command, then any bearer Terminations listed in its Multiplex
+   Descriptor are also moved as if individual Move commands listing the
+   Terminations were invoked.
+
+   Move SHALL NOT be used on a Termination with a serviceState of
+   "OutofService".
+
+7.2.5 AuditValue
+
+   The AuditValue Command returns the current values of properties,
+   events, signals and statistics associated with Terminations.
+
+   TerminationID
+   [,MediaDescriptor]
+   [,ModemDescriptor]
+   [,MuxDescriptor]
+   [,EventsDescriptor]
+   [,SignalsDescriptor]
+   [,DigitMapDescriptor]
+   [,ObservedEventsDescriptor]
+   [,EventBufferDescriptor]
+   [,StatisticsDescriptor]
+   [,PackagesDescriptor]
+     AuditValue(TerminationID,
+      AuditDescriptor
+      )
+
+   TerminationID may be specific or wildcarded.  If the wildcard matches
+   more than one TerminationID, all possible matches are attempted, with
+   results reported for each one.  The order of attempts when multiple
+   TerminationIDs match is not specified.  If a wildcarded response is
+   requested, only one command return is generated, with the contents
+   containing the union of the values of all Terminations matching the
+   wildcard.  This convention may reduce the volume of data required to
+   audit a group of Terminations.  Use of CHOOSE is an error.
+
+   The appropriate descriptors, with the current values for the
+   Termination, are returned from AuditValue.  Values appearing in
+   multiple instances of a descriptor are defined to be alternate values
+   supported, with each parameter in a descriptor considered
+   independent.
+
+   ObservedEvents returns a list of events in the EventBuffer.  If the
+   ObservedEventsDescriptor is audited while a DigitMap is active, the
+   returned ObservedEvents descriptor also includes a digit map
+   completion event that shows the current dial string but does not show
+   a Termination method.
+
+
+
+Groves, et al.              Standards Track                    [Page 56]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   EventBuffer returns the set of events and associated parameter values
+   currently enabled in the EventBufferDescriptor.  PackagesDescriptor
+   returns a list of packages realized by the Termination.
+   DigitMapDescriptor returns the name or value of the current DigitMap
+   for the Termination.  DigitMap requested in an AuditValue command
+   with TerminationID ALL returns all DigitMaps in the gateway.
+   Statistics returns the current values of all statistics being kept on
+   the Termination.   Specifying an empty Audit descriptor results in
+   only the TerminationID being returned.  This may be useful to get a
+   list of TerminationIDs when used with wildcard.  Annexes A and B
+   provide a special syntax for presenting such a list in condensed
+   form, such that the AuditValue command tag does not have to be
+   repeated for each TerminationID.
+
+   AuditValue results depend on the Context, viz. specific, null, or
+   wildcarded.  (Note that ContextID ALL does not include the null
+   Context.)  The TerminationID may be specific, or wildcarded.
+
+   The following are examples of what is returned in case the context
+   and/or the termination is wildcarded and a wildcarded response has
+   been specified.
+
+   Assume that the gateway has 4 terminations: t1/1, t1/2, t2/1 and
+   t2/2.  Assume that terminations t1/* have implemented packages aaa
+   and bbb and that terminations t2/* have implemented packages ccc and
+   ddd.  Assume that Context 1 has t1/1 and t2/1 in it and that Context
+   2 has t1/2 and t2/2 in it.
+
+   The command:
+
+     Context=1{AuditValue=t1/1{Audit{Packages}}}
+
+   Returns:
+
+     Context=1{AuditValue=t1/1{Packages{aaa,bbb}}}
+
+   The command:
+
+     Context=*{AuditValue=t2/*{Audit{Packages}}}
+
+   Returns:
+
+     Context=1{AuditValue=t2/1{Packages{ccc,ddd}}},
+     Context=2{AuditValue=t2/2{Packages{ccc,ddd}}}
+
+   The command:
+
+     Context=*{W-AuditValue=t1/*{Audit{Packages}}}
+
+
+
+Groves, et al.              Standards Track                    [Page 57]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Returns:
+
+     Context=*{W-AuditValue=t1/*{Packages{aaa,bbb}}}
+
+   Note: A wildcard response may also be used for other commands such as
+   Subtract.
+
+   The following illustrates other information that can be obtained with
+   the AuditValue Command:
+
+   ContextID TerminationID Information Obtained
+
+   Specific  wildcard      Audit of matching Terminations in a Context
+
+   Specific  specific      Audit of a single Termination in a Context
+
+   Null      Root          Audit of Media Gateway state and events
+
+   Null      wildcard      Audit of all matching Terminations in the
+                            null Context
+
+   Null      specific      Audit of a single Termination outside of any
+                            Context
+
+   All       wildcard      Audit of all matching Terminations and the
+                            Context to which they are associated
+
+   All       Root          List of all ContextIds (the ContextID list
+                            should be returned by using multiple action
+                            replies, each containing a ContextID from
+                            the list)
+
+   All       Specific      (Non-null) ContextID in which the
+                            Termination currently exists
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 58]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+7.2.6 AuditCapabilities
+
+   The AuditCapabilities Command returns the possible values of
+   properties, events, signals and statistics associated with
+   Terminations.
+
+     TerminationID
+     [,MediaDescriptor]
+     [,ModemDescriptor]
+     [,MuxDescriptor]
+     [,EventsDescriptor]
+     [,SignalsDescriptor]
+     [,ObservedEventsDescriptor]
+     [,EventBufferDescriptor]
+     [,StatisticsDescriptor]
+      AuditCapabilities(TerminationID,
+         AuditDescriptor
+         )
+
+   The appropriate descriptors, with the possible values for the
+   Termination are returned from AuditCapabilities.  Descriptors may be
+   repeated where there are multiple possible values.  If a wildcarded
+   response is requested, only one command return is generated, with the
+   contents containing the union of the values of all Terminations
+   matching the wildcard.  This convention may reduce the volume of data
+   required to audit a group of Terminations.
+
+   Interpretation of what capabilities are requested for various values
+   of ContextID and TerminationID is the same as in AuditValue.
+
+   The EventsDescriptor returns the list of possible events on the
+   Termination together with the list of all possible values for the
+   EventsDescriptor Parameters.  EventBufferDescriptor returns the same
+   information as EventsDescriptor.  The SignalsDescriptor returns the
+   list of possible signals that could be applied to the Termination
+   together with the list of all possible values for the Signals
+   Parameters.  StatisticsDescriptor returns the names of the statistics
+   being kept on the termination.  ObservedEventsDescriptor returns the
+   names of active events on the Termination.  DigitMap and Packages are
+   not legal in AuditCapability.
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 59]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The following illustrates other information that can be obtained with
+   the AuditCapabilties Command:
+
+   ContextID TerminationID Information Obtained
+
+   Specific  wildcard      Audit of matching Terminations in a Context
+
+   Specific  specific      Audit of a single Termination in a Context
+
+   Null      Root          Audit of MG state and events
+
+   Null      wildcard      Audit of all matching Terminations in the
+                            Null Context
+
+   Null      specific      Audit of a single Termination outside of any
+                            Context
+
+   All       wildcard      Audit of all matching Terminations and the
+                            Context to which they are associated
+
+   All       Root          Same as for AuditValue
+
+   All       Specific      Same as for AuditValue
+
+7.2.7 Notify
+
+   The Notify Command allows the Media Gateway to notify the Media
+   Gateway Controller of events occurring within the Media Gateway.
+
+     TerminationID
+      Notify(TerminationID,
+         ObservedEventsDescriptor,
+         [ErrorDescriptor]
+         )
+
+   The TerminationID parameter specifies the Termination issuing the
+   Notify Command.  The TerminationID shall be a fully qualified name.
+
+   The ObservedEventsDescriptor contains the RequestID and a list of
+   events that the Media Gateway detected in the order that they were
+   detected.  Each event in the list is accompanied by parameters
+   associated with the event and optionally an indication of the time
+   that the event was detected.  Procedures for sending Notify commands
+   with RequestID equal to 0 are for further study.
+
+   Notify Commands with RequestID not equal to 0 shall occur only as the
+   result of detection of an event specified by an Events descriptor
+   which is active on the Termination concerned.
+
+
+
+Groves, et al.              Standards Track                    [Page 60]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The RequestID returns the RequestID parameter of the EventsDescriptor
+   that triggered the Notify Command.  It is used to correlate the
+   notification with the request that triggered it.  The events in the
+   list must have been requested via the triggering EventsDescriptor or
+   embedded events descriptor unless the RequestID is 0 (which is for
+   further study).
+
+   The ErrorDescriptor may be sent in the Notify Command as a result of
+   Error 518 - Event buffer full.
+
+7.2.8 ServiceChange
+
+   The ServiceChange Command allows the Media Gateway to notify the
+   Media Gateway Controller that a Termination or group of Terminations
+   is about to be taken out of service or has just been returned to
+   service.  The Media Gateway Controller may indicate that
+   Termination(s) shall be taken out of or returned to service.   The
+   Media Gateway may notify the MGC that the capability of a Termination
+   has changed.  It also allows a MGC to hand over control of a MG to
+   another MGC.
+
+   TerminationID,
+
+     [ServiceChangeDescriptor]
+      ServiceChange ( TerminationID,
+         ServiceChangeDescriptor
+         )
+
+   The TerminationID parameter specifies the Termination(s) that are
+   taken out of or returned to service.  Wildcarding of Termination
+   names is permitted, with the exception that the CHOOSE mechanism
+   shall not be used.  Use of the "Root" TerminationID indicates a
+   ServiceChange affecting the entire Media Gateway.
+
+   The ServiceChangeDescriptor contains the following parameters as
+   required:
+
+   -  ServiceChangeMethod
+   -  ServiceChangeReason
+   -  ServiceChangeDelay
+   -  ServiceChangeAddress
+   -  ServiceChangeProfile
+   -  ServiceChangeVersion
+   -  ServiceChangeMgcId
+   -  TimeStamp
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 61]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The ServiceChangeMethod parameter specifies the type of ServiceChange
+   that will or has occurred:
+
+   1) Graceful - indicates that the specified Terminations will be taken
+      out of service after the specified ServiceChangeDelay; established
+      connections are not yet affected, but the Media Gateway Controller
+      should refrain from establishing new connections and should
+      attempt to gracefully tear down existing connections on the
+      Termination(s) affected by the serviceChange command.  The MG
+      should set Termination serviceState at the expiry of
+      ServiceChangeDelay or the removal of the Termination from an
+      active Context (whichever is first), to "out of service".
+
+   2) Forced - indicates that the specified Terminations were taken
+      abruptly out of service and any established connections associated
+      with them may be lost.  For non-Root terminations, the MGC is
+      responsible for cleaning up the Context (if any) with which the
+      failed Termination is associated.  At a minimum the Termination
+      shall be subtracted from the Context.  The Termination
+      serviceState should be "out of service".  For the root
+      termination, the MGC can assume that all connections are lost on
+      the MG and thus can consider that all the terminations have been
+      subtracted.
+
+   3) Restart - indicates that service will be restored on the specified
+      Terminations after expiration of the ServiceChangeDelay.  The
+      serviceState should be set to "inService" upon expiry of
+      ServiceChangeDelay.
+
+   4) Disconnected - always applied with the Root TerminationID,
+      indicates that the MG lost communication with the MGC, but it was
+      subsequently restored to the same MGC (possibly after trying other
+      MGCs on a pre-provisioned list).  Since MG state may have changed,
+      the MGC may wish to use the Audit command to resynchronize its
+      state with the MG's.
+
+   5) Handoff - sent from the MGC to the MG, this reason indicates that
+      the MGC is going out of service and a new MGC association must be
+      established.  Sent from the MG to the MGC, this indicates that the
+      MG is attempting to establish a new association in accordance with
+      a Handoff received from the MGC with which it was previously
+      associated.
+
+   6) Failover - sent from MG to MGC to indicate the primary MG is out
+      of service and a secondary MG is taking over.  This serviceChange
+      method is also sent from the MG to the MGC when the MG detects
+      that MGC has failed.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 62]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   7) Another value whose meaning is mutually understood between the MG
+      and the MGC.
+
+   The ServiceChangeReason parameter specifies the reason why the
+   ServiceChange has or will occur.  It consists of an alphanumeric
+   token (IANA registered) and, optionally, an explanatory string.
+
+   The optional ServiceChangeAddress parameter specifies the address
+   (e.g., IP port number for IP networks) to be used for subsequent
+   communications.  It can be specified in the input parameter
+   descriptor or the returned result descriptor.  ServiceChangeAddress
+   and ServiceChangeMgcId parameters must not both be present in the
+   ServiceChangeDescriptor or the ServiceChangeResultDescriptor.  The
+   ServiceChangeAddress provides an address to be used within the
+   Context of the association currently being negotiated, while the
+   ServiceChangeMgcId provides an alternate address where the MG should
+   seek to establish another association.  Note that the use of
+   ServiceChangeAddress is not encouraged.  MGCs and MGs must be able to
+   cope with the ServiceChangeAddress being either a full address or
+   just a port number in the case of TCP transports.
+
+   The optional ServiceChangeDelay parameter is expressed in seconds.
+   If the delay is absent or set to zero, the delay value should be
+   considered to be null.  In the case of a "graceful"
+   ServiceChangeMethod, a null delay indicates that the Media Gateway
+   Controller should wait for the natural removal of existing
+   connections and should not establish new connections.  For "graceful"
+   only, a null delay means the MG must not set serviceState "out of
+   service" until the Termination is in the null Context.
+
+   The optional ServiceChangeProfile parameter specifies the Profile (if
+   any) of the protocol supported.  The ServiceChangeProfile includes
+   the version of the profile supported.
+
+   The optional ServiceChangeVersion parameter contains the protocol
+   version and is used if protocol version negotiation occurs (see
+   11.3).
+
+   The optional TimeStamp parameter specifies the actual time as kept by
+   the sender.  As such, it is not necessarily absolute time according
+   to, for example, a local time zone - it merely establishes an
+   arbitrary starting time against which all future timestamps
+   transmitted by a sender during this association shall be compared.
+   It can be used by the responder to determine how its notion of time
+   differs from that of its correspondent.  TimeStamp is sent with a
+   precision of hundredths of a second.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 63]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The optional Extension parameter may contain any value whose meaning
+   is mutually understood by the MG and MGC.
+
+   A ServiceChange Command specifying the "Root" for the TerminationID
+   and ServiceChangeMethod equal to Restart is a registration command by
+   which a Media Gateway announces its existence to the Media Gateway
+   Controller.  The Media Gateway may also announce a registration
+   command by specifying the "Root" for the TerminationID and
+   ServiceChangeMethod equal to Failover when the MG detects MGC
+   failures.  The Media Gateway is expected to be provisioned with the
+   name of one primary and optionally some number of alternate Media
+   Gateway Controllers.  Acknowledgement of the ServiceChange Command
+   completes the registration process, except when the MGC has returned
+   an alternative ServiceChangeMgcId as described in the following
+   paragraph.  The MG may specify the transport ServiceChangeAddress to
+   be used by the MGC for sending messages in the ServiceChangeAddress
+   parameter in the input ServiceChangeDescriptor.  The MG may specify
+   an address in the ServiceChangeAddress parameter of the ServiceChange
+   request, and the MGC may also do so in the ServiceChange reply.  In
+   either case, the recipient must use the supplied address as the
+   destination for all subsequent transaction requests within the
+   association.  At the same time, as indicated in clause 9, transaction
+   replies and pending indications must be sent to the address from
+   which the corresponding requests originated.  This must be done even
+   if it implies extra messaging because commands and responses cannot
+   be packed together.  The TimeStamp parameter shall be sent with a
+   registration command and its response.
+
+   The Media Gateway Controller may return a ServiceChangeMgcId
+   parameter that describes the Media Gateway Controller that should
+   preferably be contacted for further service by the Media Gateway.  In
+   this case the Media Gateway shall reissue the ServiceChange command
+   to the new Media Gateway Controller.  The MGC specified in a
+   ServiceChangeMgcId, if provided, shall be contacted before any
+   further alternate MGCs.  On a HandOff message from MGC to MG, the
+   ServiceChangeMgcId is the new MGC that will take over from the
+   current MGC.
+
+   The return from ServiceChange is empty except when the Root
+   terminationID is used.  In that case it includes the following
+   parameters as required:
+
+   -  ServiceChangeAddress, if the responding MGC wishes to specify a
+      new destination for messages from the MG for the remainder of the
+      association;
+
+   -  ServiceChangeMgcId, if the responding MGC does not wish to sustain
+      an association with the MG;
+
+
+
+Groves, et al.              Standards Track                    [Page 64]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   -  ServiceChangeProfile, if the responder wishes to negotiate the
+      profile to be used for the association;
+
+   -  ServiceChangeVersion, if the responder wishes to negotiate the
+      version of the protocol to be used for the association.
+
+   The following ServiceChangeReasons are defined.  This list may be
+   extended by an IANA registration as outlined in 13.3.
+
+      900 Service Restored
+      901 Cold Boot
+      902 Warm Boot
+      903 MGC Directed Change
+      904 Termination malfunctioning
+      905 Termination taken out of service
+      906 Loss of lower layer connectivity (e.g., downstream sync)
+      907 Transmission Failure
+      908 MG Impending Failure
+      909 MGC Impending Failure
+      910 Media Capability Failure
+      911 Modem Capability Failure
+      912 Mux Capability Failure
+      913 Signal Capability Failure
+      914 Event Capability Failure
+      915 State Loss
+
+7.2.9 Manipulating and Auditing Context Attributes
+
+   The commands of the protocol as discussed in the preceding subclauses
+   apply to Terminations.  This subclause specifies how Contexts are
+   manipulated and audited.
+
+   Commands are grouped into actions (see clause 8).  An action applies
+   to one Context.  In addition to commands, an action may contain
+   Context manipulation and auditing instructions.
+
+   An action request sent to a MG may include a request to audit
+   attributes of a Context.  An action may also include a request to
+   change the attributes of a Context.
+
+   The Context properties that may be included in an action reply are
+   used to return information to a MGC.  This can be information
+   requested by an audit of Context attributes or details of the effect
+   of manipulation of a Context.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 65]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   If a MG receives an action which contains both a request to audit
+   context attributes and a request to manipulate those attributes, the
+   response SHALL include the values of the attributes after processing
+   the manipulation request.
+
+7.2.10   Generic Command Syntax
+
+   The protocol can be encoded in a binary format or in a text format.
+   MGCs should support both encoding formats.  MGs may support both
+   formats.
+
+   The protocol syntax for the binary format of the protocol is defined
+   in Annex A.  Annex C specifies the encoding of the Local and Remote
+   descriptors for use with the binary format.
+
+   A complete ABNF of the text encoding of the protocol per RFC 2234 is
+   given in Annex B.  SDP is used as the encoding of the Local and
+   Remote descriptors for use with the text encoding as modified in
+   7.1.8.
+
+7.3   Command Error Codes
+
+   Errors consist of an IANA registered error code and an explanatory
+   string.  Sending the explanatory string is optional.  Implementations
+   are encouraged to append diagnostic information to the end of the
+   string.
+
+   When a MG reports an error to a MGC, it does so in an error
+   descriptor.  An error descriptor consists of an error code and
+   optionally the associated explanatory string.
+
+   H.248.8 contains the error codes supported by Recommendations in the
+   H.248 sub-series.
+
+8  Transactions
+
+   Commands between the Media Gateway Controller and the Media Gateway
+   are grouped into Transactions, each of which is identified by a
+   TransactionID.  Transactions consist of one or more Actions.  An
+   Action consists of a non-empty series of Commands, Context property
+   modifications, or Context property audits that are limited to
+   operating within a single Context.  Consequently, each Action
+   typically specifies a ContextID.  However, there are two
+   circumstances where a specific ContextID is not provided with an
+   Action.  One is the case of modification of a Termination outside of
+   a Context.  The other is where the controller requests the gateway to
+   create a new Context.  Figure 8 is a graphic representation of the
+   Transaction, Action and Command relationships.
+
+
+
+Groves, et al.              Standards Track                    [Page 66]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      +----------------------------------------------------------+
+      | Transaction x                                            |
+      |  +----------------------------------------------------+  |
+      |  | Action 1                                           |  |
+      |  | +---------+  +---------+  +---------+  +---------+ |  |
+      |  | | Command |  | Command |  | Command |  | Command | |  |
+      |  | |    1    |  |    2    |  |    3    |  |    4    | |  |
+      |  | +---------+  +---------+  +---------+  +---------+ |  |
+      |  +----------------------------------------------------+  |
+      |                                                          |
+      |  +----------------------------------------------------+  |
+      |  | Action 2                                           |  |
+      |  | +---------+                                        |  |
+      |  | | Command |                                        |  |
+      |  | |    1    |                                        |  |
+      |  | +---------+                                        |  |
+      |  +----------------------------------------------------+  |
+      |                                                          |
+      |  +----------------------------------------------------+  |
+      |  | Action 3                                           |  |
+      |  | +---------+  +---------+  +---------+              |  |
+      |  | | Command |  | Command |  | Command |              |  |
+      |  | |    1    |  |    2    |  |    3    |              |  |
+      |  | +---------+  +---------+  +---------+              |  |
+      |  +----------------------------------------------------+  |
+      +----------------------------------------------------------+
+
+               Figure 8: Transactions, Actions and Commands
+
+   Transactions are presented as TransactionRequests.  Corresponding
+   responses to a TransactionRequest are received in a single reply,
+   possibly preceded by a number of TransactionPending messages (see
+   8.2.3).
+
+   Transactions guarantee ordered Command processing.  That is, Commands
+   within a Transaction are executed sequentially.  Ordering of
+   Transactions is NOT guaranteed - transactions may be executed in any
+   order, or simultaneously.
+
+   At the first failing Command in a Transaction, processing of the
+   remaining Commands in that Transaction stops.  If a command contains
+   a wildcarded TerminationID, the command is attempted with each of the
+   actual TerminationIDs matching the wildcard.  A response within the
+   TransactionReply is included for each matching TerminationID, even if
+   one or more instances generated an error.  If any TerminationID
+   matching a wildcard results in an error when executed, any commands
+   following the wildcarded command are not attempted.
+
+
+
+
+Groves, et al.              Standards Track                    [Page 67]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Commands may be marked as "Optional" which can override this
+   behaviour - if a command marked as Optional results in an error,
+   subsequent commands in the Transaction will be executed.  If a
+   command fails, the MG shall as far as possible restore the state that
+   existed prior to the attempted execution of the command before
+   continuing with command processing.
+
+   A TransactionReply includes the results for all of the Commands in
+   the corresponding TransactionRequest.  The TransactionReply includes
+   the return values for the Commands that were executed successfully,
+   and the Command and error descriptor for any Command that failed.
+
+   TransactionPending is used to periodically notify the receiver that a
+   Transaction has not completed yet, but is actively being processed.
+
+   Applications SHOULD implement an application level timer per
+   transaction.  Expiration of the timer should cause a retransmission
+   of the request.  Receipt of a Reply should cancel the timer.  Receipt
+   of Pending should restart the timer.
+
+8.1   Common parameters
+
+8.1.1 Transaction Identifiers
+
+   Transactions are identified by a TransactionID, which is assigned by
+   sender and is unique within the scope of the sender.  A response
+   containing an error descriptor to indicate that the TransactionID is
+   missing in a request shall use TransactionID 0 in the corresponding
+   TransactionReply.
+
+8.1.2 Context Identifiers
+
+   Contexts are identified by a ContextID, which is assigned by the
+   Media Gateway and is unique within the scope of the Media Gateway.
+   The Media Gateway Controller shall use the ContextID supplied by the
+   Media Gateway in all subsequent Transactions relating to that
+   Context.  The protocol makes reference to a distinguished value that
+   may be used by the Media Gateway Controller when referring to a
+   Termination that is currently not associated with a Context, namely
+   the null ContextID.
+
+   The CHOOSE wildcard is used to request that the Media Gateway create
+   a new Context.
+
+   The MGC may use the ALL wildcard to address all Contexts on the MG.
+   The null Context is not included when the ALL wildcard is used.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 68]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The MGC shall not use partially specified ContextIDs containing the
+   CHOOSE or ALL wildcards.
+
+8.2   Transaction Application Programming Interface
+
+   Following is an Application Programming Interface (API) describing
+   the Transactions of the protocol.  This API is shown to illustrate
+   the Transactions and their parameters and is not intended to specify
+   implementation (e.g., via use of blocking function calls).  It will
+   describe the input parameters and return values expected to be used
+   by the various Transactions of the protocol from a very high level.
+   Transaction syntax and encodings are specified in later subclauses.
+
+8.2.1 TransactionRequest
+
+   The TransactionRequest is invoked by the sender.  There is one
+   Transaction per request invocation.  A request contains one or more
+   Actions, each of which specifies its target Context and one or more
+   Commands per Context.
+
+     TransactionRequest(TransactionId {
+         ContextID {Command ... Command},
+            . . .
+         ContextID {Command ... Command } })
+
+   The TransactionID parameter must specify a value for later
+   correlation with the TransactionReply or TransactionPending response
+   from the receiver.
+
+   The ContextID parameter must specify a value to pertain to all
+   Commands that follow up to either the next specification of a
+   ContextID parameter or the end of the TransactionRequest, whichever
+   comes first.
+
+   The Command parameter represents one of the Commands mentioned in 7.2
+   (Command Application Programming Interface).
+
+8.2.2 TransactionReply
+
+   The TransactionReply is invoked by the receiver.  There is one reply
+   invocation per transaction.  A reply contains one or more Actions,
+   each of which must specify its target Context and one or more
+   Responses per Context.  The TransactionReply is invoked by the
+   responder when it has processed the TransactionRequest.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 69]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   A TransactionRequest has been processed:
+
+   -  when all actions in that TransactionRequest have been processed;
+      or
+
+   -  when an error is encountered in processing that
+      TransactionRequest, except when the error is in an optional
+      command.
+
+   A command has been processed when all descriptors in that command
+   have been processed.
+
+   A SignalsDescriptor is considered to have been processed when it has
+   been established that the descriptor is syntactically valid, the
+   requested signals are supported and they have been queued to be
+   applied.
+
+   An EventsDescriptor or EventBufferDescriptor is considered to have
+   been processed when it has been established that the descriptor is
+   syntactically valid, the requested events can be observed, any
+   embedded signals can be generated, any embedded events can be
+   detected, and the MG has been brought into a state in which the
+   events will be detected.
+
+     TransactionReply(TransactionID {
+         ContextID { Response ... Response },
+            . . .
+         ContextID { Response ... Response } })
+
+   The TransactionID parameter must be the same as that of the
+   corresponding TransactionRequest.
+
+   The ContextID parameter must specify a value to pertain to all
+   Responses for the action.  The ContextID may be specific, all or
+   null.
+
+   Each of the Response parameters represents a return value as
+   mentioned in 7.2, or an error descriptor if the command execution
+   encountered an error.  Commands after the point of failure are not
+   processed and, therefore, Responses are not issued for them.
+
+   An exception to this occurs if a command has been marked as optional
+   in the Transaction request.  If the optional command generates an
+   error, the transaction still continues to execute, so the Reply
+   would, in this case, have Responses after an Error.
+
+   Section 7.1.19 Error Descriptor specifies the generation of error
+   descriptors.  The text below discusses several individual cases.
+
+
+
+Groves, et al.              Standards Track                    [Page 70]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   If the receiver encounters an error in processing a ContextID, the
+   requested Action response will consist of the Context ID and a single
+   error descriptor, 422 - Syntax Error in Action.
+
+   If the receiver encounters an error such that it cannot determine a
+   legal Action, it will return a TransactionReply consisting of the
+   TransactionID and a single error descriptor, 422 - Syntax Error in
+   Action.  If the end of an action cannot be reliably determined but
+   one or more commands can be parsed, it will process them and then
+   send 422 - Syntax Error in Action as the last action for the
+   transaction.  If the receiver encounters an error such that is cannot
+   determine a legal Transaction, it will return a TransactionReply with
+   a null TransactionID and a single error descriptor (403 - Syntax
+   Error in TransactionRequest).
+
+   If the end of a transaction cannot be reliably determined and one or
+   more Actions can be parsed, it will process them and then return 403
+   - Syntax Error in Transaction as the last action reply for the
+   transaction.  If no Actions can be parsed, it will return 403 -
+   Syntax Error in TransactionRequest as the only reply.
+
+   If the terminationID cannot be reliably determined, it will send 442
+   - Syntax Error in Command as the action reply.
+
+   If the end of a command cannot be reliably determined, it will return
+   442 - Syntax Error in Command as the reply to the last action it can
+   parse.
+
+8.2.3 TransactionPending
+
+   The receiver invokes the TransactionPending.  A TransactionPending
+   indicates that the Transaction is actively being processed, but has
+   not been completed.  It is used to prevent the sender from assuming
+   the TransactionRequest was lost where the Transaction will take some
+   time to complete.
+
+     TransactionPending(TransactionID { } )
+
+   The TransactionID parameter must be the same as that of the
+   corresponding TransactionRequest.  A property of root
+   (normalMGExecutionTime) is settable by the MGC to indicate the
+   interval within which the MGC expects a response to any transaction
+   from the MG.  Another property (normalMGCExecutionTime) is settable
+   by the MGC to indicate the interval within which the MG should expect
+   a response to any transaction from the MGC.  Senders may receive more
+   than one TransactionPending for a command.  If a duplicate request is
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 71]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   received when pending, the responder may send a duplicate pending
+   immediately, or continue waiting for its timer to trigger another
+   TransactionPending.
+
+8.3   Messages
+
+   Multiple Transactions can be concatenated into a Message.  Messages
+   have a header, which includes the identity of the sender.  The
+   Message Identifier (MID) of a message is set to a provisioned name
+   (e.g., domain address/domain name/device name) of the entity
+   transmitting the message.  Domain name is a suggested default.  An
+   H.248.1 entity (MG/MGC) must consistently use the same MID in all
+   messages it originates for the duration of control association with
+   the peer (MGC/MG).
+
+   Every Message contains a Version Number identifying the version of
+   the protocol the message conforms to.  Versions consist of one or two
+   digits, beginning with version 1 for the present version of the
+   protocol.
+
+   The transactions in a message are treated independently.  There is no
+   order implied; there is no application or protocol acknowledgement of
+   a message.  A message is essentially a transport mechanism.  For
+   example, message X containing transaction requests A, B, and C may be
+   responded to with message Y containing replies to A and C and message
+   Z containing the reply to B.  Likewise, message L containing request
+   D and message M containing request E may be responded to with message
+   N containing replies to both D and E.
+
+9  Transport
+
+   The transport mechanism for the protocol should allow the reliable
+   transport of transactions between a MGC and MG.  The transport shall
+   remain independent of what particular commands are being sent and
+   shall be applicable to all application states.  There are several
+   transports defined for the protocol, which are defined in Annexes to
+   this RFC and other Recommendations of the H.248
+   sub-series.  Additional Transports may be defined as additional
+
+   Recommendations of the H.248 sub-series.  For transport of the
+   protocol over IP, MGCs shall implement both TCP and UDP/ALF, a MG
+   shall implement TCP or UDP/ALF or both.
+
+   The MG is provisioned with a name or address (such as DNS name or IP
+   address) of a primary and zero or more secondary MGCs (see 7.2.8)
+   that is the address the MG uses to send messages to the MGC.  If TCP
+   or UDP is used as the protocol transport and the port to which the
+   initial ServiceChange request is to be sent is not otherwise known,
+
+
+
+Groves, et al.              Standards Track                    [Page 72]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   that request should be sent to the default port number for the
+   protocol.  This port number is 2944 for text-encoded operation or
+   2945 for binary-encoded operation, for either UDP or TCP.  The MGC
+   receives the message containing the ServiceChange request from the MG
+   and can determine the MG's address from it.  As described in 7.2.8,
+   either the MG or the MGC may supply an address in the
+   ServiceChangeAddress parameter to which subsequent transaction
+   requests must be addressed, but responses (including the response to
+   the initial ServiceChange request) must always be sent back to the
+   address which was the source of the corresponding request.  For
+   example, in IP networks, this is the source address in the IP header
+   and the source port number in the TCP/UDP/SCTP header.
+
+9.1   Ordering of Commands
+
+   This RFC does not mandate that the underlying transport protocol
+   guarantees the sequencing of transactions sent to an entity.  This
+   property tends to maximize the timeliness of actions, but it has a
+   few drawbacks.  For example:
+
+   -  Notify commands may be delayed and arrive at the MGC after the
+      transmission of a new command changing the EventsDescriptor.
+
+   -  If a new command is transmitted before a previous one is
+      acknowledged, there is no guarantee that prior command will be
+      executed before the new one.
+
+   Media Gateway Controllers that want to guarantee consistent operation
+   of the Media Gateway may use the following rules.  These rules are
+   with respect to commands that are in different transactions.
+   Commands that are in the same transaction are executed in order (see
+   clause 8).
+
+   1) When a Media Gateway handles several Terminations, commands
+      pertaining to the different Terminations may be sent in parallel,
+      for example following a model where each Termination (or group of
+      Terminations) is controlled by its own process or its own thread.
+
+   2) On a Termination, there should normally be at most one outstanding
+      command (Add or Modify or Move), unless the outstanding commands
+      are in the same transaction.  However, a Subtract command may be
+      issued at any time.  In consequence, a Media Gateway may sometimes
+      receive a Modify command that applies to a previously subtracted
+      Termination.  Such commands should be ignored, and an error code
+      should be returned.
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 73]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   3) For transports that do not guarantee in-sequence delivery of
+      messages (i.e., UDP), there should normally be on a given
+      Termination at most one outstanding Notify command at any time.
+
+   4) In some cases, an implicitly or explicitly wildcarded Subtract
+      command that applies to a group of Terminations may step in front
+      of a pending Add command.  The Media Gateway Controller should
+      individually delete all Terminations for which an Add command was
+      pending at the time of the global Subtract command.  Also, new Add
+      commands for Terminations named by the wildcarding (or implied in
+      a Multiplex descriptor) should not be sent until the wildcarded
+      Subtract command is acknowledged.
+
+   5) AuditValue and AuditCapability are not subject to any sequencing.
+
+   6) ServiceChange shall always be the first command sent by a MG as
+      defined by the restart procedure.  Any other command or response
+      must be delivered after this ServiceChange command.
+
+   These rules do not affect the command responder, which should always
+   respond to commands.
+
+9.2   Protection against Restart Avalanche
+
+   In the event that a large number of Media Gateways are powered on
+   simultaneously and they were to all initiate a ServiceChange
+   transaction, the Media Gateway Controller would very likely be
+   swamped, leading to message losses and network congestion during the
+   critical period of service restoration.  In order to prevent such
+   avalanches, the following behaviour is suggested:
+
+   1) When a Media Gateway is powered on, it should initiate a restart
+      timer to a random value, uniformly distributed between 0 and a
+      maximum waiting delay (MWD).  Care should be taken to avoid
+      synchronicity of the random number generation between multiple
+      Media Gateways that would use the same algorithm.
+
+   2) The Media Gateway should then wait for either the end of this
+      timer or the detection of a local user activity, such as for
+      example an off-hook transition on a residential Media Gateway.
+
+   3) When the timer elapses, or when an activity is detected, the Media
+      Gateway should initiate the restart procedure.
+
+   The restart procedure simply requires the MG to guarantee that the
+   first message that the Media Gateway Controller sees from this MG is
+   a ServiceChange message informing the Media Gateway Controller about
+   the restart.
+
+
+
+Groves, et al.              Standards Track                    [Page 74]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+     NOTE - The value of MWD is a configuration parameter that depends
+     on the type of the Media Gateway.  The following reasoning may be
+     used to determine the value of this delay on residential gateways.
+
+   Media Gateway Controllers are typically dimensioned to handle the
+   peak hour traffic load, during which, in average, 10% of the lines
+   will be busy, placing calls whose average duration is typically 3
+   minutes.  The processing of a call typically involves 5 to 6 Media
+   Gateway Controller transactions between each Media Gateway and the
+   Media Gateway Controller.  This simple calculation shows that the
+   Media Gateway Controller is expected to handle 5 to 6 transactions
+   for each Termination, every 30 minutes on average, or, to put it
+   otherwise, about one transaction per Termination every 5 to 6 minutes
+   on average.  This suggests that a reasonable value of MWD for a
+   residential gateway would be 10 to 12 minutes.  In the absence of
+   explicit configuration, residential gateways should adopt a value of
+   600 seconds for MWD.
+
+   The same reasoning suggests that the value of MWD should be much
+   shorter for trunking gateways or for business gateways, because they
+   handle a large number of Terminations, and also because the usage
+   rate of these Terminations is much higher than 10% during the peak
+   busy hour, a typical value being 60%.  These Terminations, during the
+   peak hour, are this expected to contribute about one transaction per
+   minute to the Media Gateway Controller load.  A reasonable algorithm
+   is to make the value of MWD per "trunk" Termination six times shorter
+   than the MWD per residential gateway, and also inversely proportional
+   to the number of Terminations that are being restarted.  For example
+   MWD should be set to 2.5 seconds for a gateway that handles a T1
+   line, or to 60 milliseconds for a gateway that handles a T3 line.
+
+10 Security Considerations
+
+   This clause covers security when using the protocol in an IP
+   environment.
+
+10.1  Protection of Protocol Connections
+
+   A security mechanism is clearly needed to prevent unauthorized
+   entities from using the protocol defined in this RFC for setting up
+   unauthorized calls or interfering with authorized calls.  The
+   security mechanism for the protocol when transported over IP networks
+   is IPsec [RFC 2401 to RFC 2411].
+
+   The AH header [RFC 2402] affords data origin authentication,
+   connectionless integrity and optional anti-replay protection of
+   messages passed between the MG and the MGC.  The ESP header [RFC
+   2406] provides confidentiality of messages, if desired.  For
+
+
+
+Groves, et al.              Standards Track                    [Page 75]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   instance, the ESP encryption service should be requested if the
+   session descriptions are used to carry session keys, as defined in
+   SDP.
+
+   Implementations of the protocol defined in this RFC employing the ESP
+   header SHALL comply with section 5 of [RFC 2406], which defines a
+   minimum set of algorithms for integrity checking and encryption.
+   Similarly, implementations employing the AH header SHALL comply with
+   section 5 of [RFC 2402], which defines a minimum set of algorithms
+   for integrity checking using manual keys.
+
+   Implementations SHOULD use IKE [RFC 2409] to permit more robust
+   keying options.  Implementations employing IKE SHOULD support
+   authentication with RSA signatures and RSA public key encryption.
+
+10.2  Interim AH scheme
+
+   Implementation of IPsec requires that the AH or ESP header be
+   inserted immediately after the IP header.  This cannot be easily done
+   at the application level.  Therefore, this presents a deployment
+   problem for the protocol defined in this RFC where the underlying
+   network implementation does not support IPsec.
+
+   As an interim solution, an optional AH header is defined within the
+   H.248.1 protocol header.  The header fields are exactly those of the
+   SPI, SEQUENCE NUMBER and DATA fields as defined in [RFC 2402].  The
+   semantics of the header fields are the same as the "transport mode"
+   of [RFC 2402], except for the calculation of the Integrity Check
+   Value (ICV).  In IPsec, the ICV is calculated over the entire IP
+   packet including the IP header.  This prevents spoofing of the IP
+   addresses.  To retain the same functionality, the ICV calculation
+   should be performed across all the transactions (concatenated) in the
+   message prepended by a synthesized IP header consisting of a 32-bit
+   source IP address, a 32-bit destination address and a 16-bit UDP
+   destination port encoded as 20 hex digits.  When the interim AH
+   mechanism is employed when TCP is the transport Layer, the UDP Port
+   above becomes the TCP port, and all other operations are the same.
+
+   Implementations of the H.248.1 protocol SHALL implement IPsec where
+   the underlying operating system and the transport network supports
+   IPsec.  Implementations of the protocol using IPv4 SHALL implement
+   the interim AH scheme.  However, this interim scheme SHALL NOT be
+   used when the underlying network layer supports IPsec.  IPv6
+   implementations are assumed to support IPsec and SHALL NOT use the
+   interim AH scheme.
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 76]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   All implementations of the interim AH mechanism SHALL comply with
+   section 5 of RFC 2402 which defines a minimum set of algorithms for
+   integrity checking using manual keys.
+
+   The interim AH interim scheme does not provide protection against
+   eavesdropping, thus forbidding third parties from monitoring the
+   connections set up by a given Termination.  Also, it does not provide
+   protection against replay attacks.  These procedures do not
+   necessarily protect against denial of service attacks by misbehaving
+   MGs or misbehaving MGCs.  However, they will provide an
+   identification of these misbehaving entities, which should then be
+   deprived of their authorization through maintenance procedures.
+
+10.3  Protection of Media Connections
+
+   The protocol allows the MGC to provide MGs with "session keys" that
+   can be used to encrypt the audio messages, protecting against
+   eavesdropping.
+
+   A specific problem of packet networks is "uncontrolled barge-in".
+   This attack can be performed by directing media packets to the IP
+   address and UDP port used by a connection.  If no protection is
+   implemented, the packets must be decompressed and the signals must be
+   played on the "line side".
+
+   A basic protection against this attack is to only accept packets from
+   known sources, checking for example that the IP source address and
+   UDP source port match the values announced in the Remote descriptor.
+   This has two inconveniences: it slows down connection establishment
+   and it can be fooled by source spoofing:
+
+   -  To enable the address-based protection, the MGC must obtain the
+      remote session description of the egress MG and pass it to the
+      ingress MG.  This requires at least one network round trip, and
+      leaves us with a dilemma: either allow the call to proceed without
+      waiting for the round trip to complete, and risk for example,
+      "clipping" a remote announcement, or wait for the full round trip
+      and settle for slower call-set up procedures.
+
+   -  Source spoofing is only effective if the attacker can obtain valid
+      pairs of source destination addresses and ports, for example by
+      listening to a fraction of the traffic.  To fight source spoofing,
+      one could try to control all access points to the network.  But
+      this is in practice very hard to achieve.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 77]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   An alternative to checking the source address is to encrypt and
+   authenticate the packets, using a secret key that is conveyed during
+   the call set-up procedure.  This will not slow down the call set-up,
+   and provides strong protection against address spoofing.
+
+11 MG-MGC Control Interface
+
+   The control association between MG and MGC is initiated at MG cold
+   start, and announced by a ServiceChange message, but can be changed
+   by subsequent events, such as failures or manual service events.
+   While the protocol does not have an explicit mechanism to support
+   multiple MGCs controlling a physical MG, it has been designed to
+   support the multiple logical MG (within a single physical MG) that
+   can be associated with different MGCs.
+
+11.1  Multiple Virtual MGs
+
+   A physical Media Gateway may be partitioned into one or more Virtual
+   MGs.  A virtual MG consists of a set of statically partitioned
+   physical Terminations and/or sets of ephemeral Terminations.  A
+   physical Termination is controlled by one MGC.  The model does not
+   require that other resources be statically allocated, just
+   Terminations.  The mechanism for allocating Terminations to virtual
+   MGs is a management method outside the scope of the protocol.  Each
+   of the virtual MGs appears to the MGC as a complete MG client.
+
+   A physical MG may have only one network interface, which must be
+   shared across virtual MGs.  In such a case, the packet/cell side
+   Termination is shared.  It should be noted however, that in use, such
+   interfaces require an ephemeral instance of the Termination to be
+   created per flow, and thus sharing the Termination is
+   straightforward.  This mechanism does lead to a complication, namely
+   that the MG must always know which of its controlling MGCs should be
+   notified if an event occurs on the interface.
+
+   In normal operation, the Virtual MG will be instructed by the MGC to
+   create network flows (if it is the originating side), or to expect
+   flow requests (if it is the terminating side), and no confusion will
+   arise.  However, if an unexpected event occurs, the Virtual MG must
+   know what to do with respect to the physical resources it is
+   controlling.
+
+   If recovering from the event requires manipulation of a physical
+   interface's state, only one MGC should do so.  These issues are
+   resolved by allowing any of the MGCs to create EventsDescriptors to
+   be notified of such events, but only one MGC can have read/write
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 78]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   access to the physical interface properties; all other MGCs have
+   read-only access.  The management mechanism is used to designate
+   which MGC has read/write capability, and is designated the Master
+   MGC.
+
+   Each virtual MG has its own Root Termination.  In most cases the
+   values for the properties of the Root Termination are independently
+   settable by each MGC.  Where there can only be one value, the
+   parameter is read-only to all but the Master MGC.
+
+   ServiceChange may only be applied to a Termination or set of
+   Terminations partitioned to the Virtual MG or created (in the case of
+   ephemeral Terminations) by that Virtual MG.
+
+11.2  Cold start
+
+   A MG is pre-provisioned by a management mechanism outside the scope
+   of this protocol with a primary and (optionally) an ordered list of
+   secondary MGCs.  Upon a cold start of the MG, it will issue a
+   ServiceChange command with a "Restart" method, on the Root
+   Termination to its primary MGC.  If the MGC accepts the MG, it sends
+   a Transaction Reply not including a ServiceChangeMgcId parameter.  If
+   the MGC does not accept the MG's registration, it sends a Transaction
+   Reply, providing the address of an alternate MGC to be contacted by
+   including a ServiceChangeMgcId parameter.
+
+   If the MG receives a Transaction Reply that includes a
+   ServiceChangeMgcId parameter, it sends a ServiceChange to the MGC
+   specified in the ServiceChangeMgcId.  It continues this process until
+   it gets a controlling MGC to accept its registration, or it fails to
+   get a reply.  Upon failure to obtain a reply, either from the primary
+   MGC, or a designated successor, the MG tries its pre-provisioned
+   secondary MGCs, in order.  If the MG is unable to establish a control
+   relationship with any MGC, it shall wait a random amount of time as
+   described in 9.2 and then start contacting its primary, and if
+   necessary, its secondary MGCs again.
+
+   It is possible that the reply to a ServiceChange with Restart will be
+   lost, and a command will be received by the MG prior to the receipt
+   of the ServiceChange response.  The MG shall issue Error 505 -
+   Command Received before a ServiceChange Reply has been received.
+
+11.3  Negotiation of protocol version
+
+   The first ServiceChange command from a MG shall contain the version
+   number of the protocol supported by the MG in the
+   ServiceChangeVersion parameter.  Upon receiving such a message, if
+   the MGC supports only a lower version, then the MGC shall send a
+
+
+
+Groves, et al.              Standards Track                    [Page 79]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   ServiceChangeReply with the lower version and thereafter all the
+   messages between MG and MGC shall conform to the lower version of the
+   protocol.  If the MG is unable to comply and it has established a
+   transport connection to the MGC, it should close that connection.  In
+   any event, it should reject all subsequent requests from the MGC with
+   error 406 - Version Not Supported.
+
+   If the MGC supports a higher version than the MG but is able to
+   support the lower version proposed by the MG, it shall send a
+   ServiceChangeReply with the lower version and thereafter all the
+   messages between MG and MGC shall conform to the lower version of the
+   protocol.  If the MGC is unable to comply, it shall reject the
+   association, with error 406 - Version Not Supported.
+
+   Protocol version negotiation may also occur at "handoff" and
+   "failover" ServiceChanges.
+
+   When extending the protocol with new versions, the following rules
+   should be followed:
+
+   1) Existing protocol elements, i.e., procedures, parameters,
+      descriptor, property, values, should not be changed unless a
+      protocol error needs to be corrected or it becomes necessary to
+      change the operation of the service that is being supported by the
+      protocol.
+
+   2) The semantics of a command, a parameter, a descriptor, a property,
+      or a value should not be changed.
+
+   3) Established rules for formatting and encoding messages and
+      parameters should not be modified.
+
+   4) When information elements are found to be obsolete they can be
+      marked as not used.  However, the identifier for that information
+      element will be marked as reserved.  In that way it can not be
+      used in future versions.
+
+11.4  Failure of a MG
+
+   If a MG fails, but is capable of sending a message to the MGC, it
+   sends a ServiceChange with an appropriate method (graceful or forced)
+   and specifies the Root TerminationID.  When it returns to service, it
+   sends a ServiceChange with a "Restart" method.
+
+   Allowing the MGC to send duplicate messages to both MGs accommodates
+   pairs of MGs that are capable of redundant failover of one of the
+   MGs.  Only the Working MG shall accept or reject transactions.  Upon
+   failover, the primary MG sends a ServiceChange command with a
+
+
+
+Groves, et al.              Standards Track                    [Page 80]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   "Failover" method and a "MG Impending Failure" reason.  The MGC then
+   uses the secondary MG as the active MG.  When the error condition is
+   repaired, the Working MG can send a "ServiceChange" with a "Restart"
+   method.
+
+     Note: Redundant failover MGs require a reliable transport, because
+     the protocol provides no means for a secondary MG running ALF to
+     acknowledge messages sent from the MGC.
+
+11.5  Failure of an MGC
+
+   If the MG detects a failure of its controlling MGC, it attempts to
+   contact the next MGC on its pre-provisioned list.  It starts its
+   attempts at the beginning (primary MGC), unless that was the MGC that
+   failed, in which case it starts at its first secondary MGC.  It sends
+   a ServiceChange message with a "Failover" method and a "MGC Impending
+   Failure" reason.  If the MG is unable to establish a control
+   relationship with any MGC, it shall wait a random amount of time as
+   described in section 9.2 and then start again contacting its primary,
+   and (if necessary) its secondary MGCs.  When contacting its
+   previously controlling MGC, the MG sends the ServiceChange message
+   with "Disconnected" method.
+
+   In partial failure, or for manual maintenance reasons, an MGC may
+   wish to direct its controlled MGs to use a different MGC.  To do so,
+   it sends a ServiceChange method to the MG with a "HandOff" method,
+   and its designated replacement in ServiceChangeMgcId.  If "HandOff"
+   is supported, the MG shall send a ServiceChange message with a
+   "Handoff" method and a "MGC directed change" reason to the designated
+   MGC.  If it fails to get a reply from the designated MGC, the MG
+   shall behave as if its MGC failed, and start contacting secondary
+   MGCs as specified in the previous paragraph.  If the MG is unable to
+   establish a control relationship with any MGC, it shall wait a random
+   amount of time as described in 9.2 and then start contacting its
+   primary, and if necessary, its secondary MGCs again.
+
+   No recommendation is made on how the MGCs involved in the Handoff
+   maintain state information; this is considered to be out of scope of
+   this RFC.  The MGC and MG may take the following steps when Handoff
+   occurs.  When the MGC initiates a HandOff, the handover should be
+   transparent to Operations on the Media Gateway.  Transactions can be
+   executed in any order, and could be in progress when the
+   ServiceChange is executed.  Accordingly, commands in progress
+   continue and replies to all commands from the original MGC must be
+   sent to the transport address from which they were sent.  If the
+   service relationship with the sending MGC has ended, the replies
+   should be discarded.  The MG may receive outstanding transaction
+   replies from the new MGC.  No new messages shall be sent to the new
+
+
+
+Groves, et al.              Standards Track                    [Page 81]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   MGC until the control association is established.  Repeated
+   transaction requests shall be directed to the new MGC.  The MG shall
+   maintain state on all Terminations and Contexts.
+
+   It is possible that the MGC could be implemented in such a way that a
+   failed MGC is replaced by a working MGC where the identity of the new
+   MGC is the same as the failed one.  In such a case,
+   ServiceChangeMgcId would be specified with the previous value and the
+   MG shall behave as if the value was changed, and send a ServiceChange
+   message, as above.
+
+   Pairs of MGCs that are capable of redundant failover can notify the
+   controlled MGs of the failover by the above mechanism.
+
+12 Package definition
+
+   The primary mechanism for extension is by means of Packages.
+   Packages define additional Properties, Events, Signals and Statistics
+   that may occur on Terminations.
+
+   Packages defined by IETF will appear in separate RFCs.
+
+   Packages defined by ITU-T may appear in the relevant Recommendations
+   (e.g., as Recommendations of the H.248 sub-series).
+
+   1) A public document or a standard forum document, which can be
+      referenced as the document that describes the package following
+      the guideline above, should be specified.
+
+   2) The document shall specify the version of the Package that it
+      describes.
+
+   3) The document should be available on a public web server and should
+      have a stable URL.  The site should provide a mechanism to provide
+      comments and appropriate responses should be returned.
+
+12.1  Guidelines for defining packages
+
+   Packages define Properties, Events, Signals, and Statistics.
+
+   Packages may also define new error codes according to the guidelines
+   given in 13.2.  This is a matter of documentary convenience: the
+   package documentation is submitted to IANA in support of the error
+   code registration.  If a package is modified, it is unnecessary to
+   provide IANA with a new document reference in support of the error
+   code unless the description of the error code itself is modified.
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 82]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Names of all such defined constructs shall consist of the PackageID
+   (which uniquely identifies the package) and the ID of the item (which
+   uniquely identifies the item in that package).  In the text encoding
+   the two shall be separated by a forward slash ("/") character.
+   Example: togen/playtone is the text encoding to refer to the play
+   tone signal in the tone generation package.
+
+   A Package will contain the following sections:
+
+12.1.1   Package
+
+   Overall description of the package, specifying:
+
+      Package Name: only descriptive
+
+      PackageID: is an identifier
+
+      Description:
+
+      Version:
+
+         A new version of a package can only add additional Properties,
+         Events, Signals, Statistics and new possible values for an
+         existing parameter described in the original package.  No
+         deletions or modifications shall be allowed.  A version is an
+         integer in the range from 1 to 99.
+
+      Designed to be extended only (Optional):
+
+         This indicates that the package has been expressly designed to
+         be extended by others, not to be directly referenced.  For
+         example, the package may not have any function on its own or be
+         nonsensical on its own.  The MG SHOULD NOT publish this
+         PackageID when reporting packages.
+
+      Extends (Optional): existing package Descriptor
+
+         A package may extend an existing package.  The version of the
+         original package must be specified.  When a package extends
+         another package it shall only add additional Properties,
+         Events, Signals, Statistics and new possible values for an
+         existing parameter described in the original package.  An
+         extended package shall not redefine or overload an identifier
+         defined in the original package and packages it may have
+         extended (multiple levels of extension).  Hence, if package B
+         version 1 extends package A version 1, version 2 of B will not
+         be able to extend the A version 2 if A version 2 defines a name
+         already in B version 1.
+
+
+
+Groves, et al.              Standards Track                    [Page 83]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+12.1.2   Properties
+
+   Properties defined by the package, specifying:
+
+      Property Name: only descriptive
+
+      PropertyID: is an identifier
+
+      Description:
+
+      Type: One of:
+
+         Boolean
+
+         String: UTF-8 string
+
+         Octet String: A number of octets.  See Annex A and Annex B.3
+         for encoding
+
+         Integer: 4 byte signed integer
+
+         Double: 8 byte signed integer
+
+         Character: unicode UTF-8 encoding of a single letter.  Could be
+         more than one octet.
+
+         Enumeration: one of a list of possible unique values (see 12.3)
+
+         Sub-list: a list of several values from a list.  The type of
+         sub-list SHALL also be specified.  The type shall be chosen
+         from the types specified in this section (with the exception of
+         sub-list).  For example, Type: sub-list of enumeration.  The
+         encoding of sub-lists is specified in Annexes A and B.3.
+
+      Possible values:
+
+         A package MUST specify either a specific set of values or a
+         description of how values are determined.  A package MUST also
+         specify a default value or the default behaviour when the value
+         is omitted from its descriptor.  For example, a package may
+         specify that procedures related to the property are suspended
+         when its value is omitted.  A default value (but not
+   procedures)
+         may be specified as provisionable.
+
+      Defined in:
+
+         Which H.248.1 descriptor the property is defined in.
+
+
+
+Groves, et al.              Standards Track                    [Page 84]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         LocalControl is for stream dependent properties.
+         TerminationState is for stream independent properties.  These
+         are expected to be the most common cases, but it is possible
+         for properties to be defined in other descriptors.
+
+      Characteristics: Read/Write or both, and (optionally), global:
+
+         Indicates whether a property is read-only, or read-write, and
+         if it is global.  If Global is omitted, the property is not
+         global.  If a property is declared as global, the value of the
+         property is shared by all Terminations realizing the package.
+
+12.1.3   Events
+
+   Events defined by the package, specifying:
+
+      Event name: only descriptive
+
+      EventID: is an identifier
+
+      Description:
+
+      EventsDescriptor Parameters:
+
+         Parameters used by the MGC to configure the event, and found in
+         the EventsDescriptor.  See 12.2.
+
+      ObservedEventsDescriptor Parameters:
+
+         Parameters returned to the MGC in Notify requests and in
+         replies to command requests from the MGC that audit
+         ObservedEventsDescriptor, and found in the
+         ObservedEventsDescriptor.  See 12.2.
+
+12.1.4   Signals
+
+   Signals defined by the package, specifying:
+
+      Signal Name: only descriptive
+
+      SignalID: is an identifier.  SignalID is used in a
+      SignalsDescriptor
+
+      Description
+
+      SignalType: one of:
+
+         OO (On/Off)
+
+
+
+Groves, et al.              Standards Track                    [Page 85]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         TO (TimeOut)
+
+         BR (Brief)
+
+      NOTE - SignalType may be defined such that it is dependent on the
+      value of one or more parameters.  The package MUST specify a
+      default signal type.  If the default type is TO, the package MUST
+      specify a default duration which may be provisioned.  A default
+      duration is meaningless for BR.
+
+      Duration: in hundredths of seconds
+
+      Additional Parameters: see 12.2
+
+12.1.5   Statistics
+
+   Statistics defined by the package, specifying:
+
+      Statistic name: only descriptive
+
+      StatisticID: is an identifier
+
+      StatisticID is used in a StatisticsDescriptor
+
+      Description:
+
+      Units: unit of measure, e.g., milliseconds, packets
+
+12.1.6   Procedures
+
+   Additional guidance on the use of the package.
+
+12.2  Guidelines to defining Parameters to Events and Signals
+
+   Parameter Name: only descriptive
+
+   ParameterID: is an identifier.  The textual ParameterID of parameters
+   to Events and Signals shall not start with "EPA" and "SPA",
+   respectively.  The textual ParameterID shall also not be "ST",
+   "Stream", "SY", "SignalType", "DR", "Duration", "NC",
+   "NotifyCompletion", "KA", "Keepactive", "EB", "Embed", "DM" or
+   "DigitMap".
+
+   Type: One of:
+
+      Boolean
+
+      String: UTF-8 octet string
+
+
+
+Groves, et al.              Standards Track                    [Page 86]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      Octet String: A number of octets.  See Annex A and Annex B.3 for
+      encoding
+
+      Integer: 4-octet signed integer
+
+      Double: 8-octet signed integer
+
+      Character: unicode UTF-8 encoding of a single letter.  Could be
+      more than one octet.
+
+      Enumeration: one of a list of possible unique values (see 12.3)
+
+      Sub-list: a list of several values from a list (not supported for
+      statistics).  The type of sub-list SHALL also be specified.  The
+      type shall be chosen from the types specified in this section
+      (with the exception of sub-list).  For example, Type: sub-list of
+      enumeration.  The encoding of sub-lists is specified in Annexes A
+      and B.3.
+
+   Possible values:
+
+      A package MUST specify either a specific set of values or a
+      description of how values are determined.  A package MUST also
+      specify a default value or the default behavior when the value is
+      omitted from its descriptor.  For example, a package may specify
+      that procedures related to the parameter are suspended when it
+      value is omitted.  A default value (but not procedures) may be
+      specified as provisionable.
+
+   Description:
+
+12.3  Lists
+
+   Possible values for parameters include enumerations.  Enumerations
+   may be defined in a list.  It is recommended that the list be IANA
+   registered so that packages that extend the list can be defined
+   without concern for conflicting names.
+
+12.4  Identifiers
+
+   Identifiers in text encoding shall be strings of up to 64 characters,
+   containing no spaces, starting with an alphabetic character and
+   consisting of alphanumeric characters and/or digits, and possibly
+   including the special character underscore ("_").
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 87]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Identifiers in binary encoding are 2 octets long.
+
+   Both text and binary values shall be specified for each identifier,
+   including identifiers used as values in enumerated types.
+
+12.5  Package registration
+
+   A package can be registered with IANA for interoperability reasons.
+   See clause 13 for IANA Considerations.
+
+13 IANA Considerations
+
+13.1  Packages
+
+   The following considerations SHALL be met to register a package with
+   IANA:
+
+   1) A unique string name, unique serial number and version number is
+      registered for each package.  The string name is used with text
+      encoding.  The serial number shall be used with binary encoding.
+      Serial Numbers 0x8000 to 0xFFFF are reserved for private use.
+      Serial number 0 is reserved.
+
+   2) A contact name, email and postal addresses for that contact shall
+      be specified.  The contact information shall be updated by the
+      defining organization as necessary.
+
+   3) A reference to a document that describes the package, which should
+      be public:
+
+      The document shall specify the version of the Package that it
+      describes.
+
+      If the document is public, it should be located on a public web
+      server and should have a stable URL.  The site should provide a
+      mechanism to provide comments and appropriate responses should be
+      returned.
+
+   4) Packages registered by other than recognized standards bodies
+      shall have a minimum package name length of 8 characters.
+
+   5) All other package names are first come-first served if all other
+      conditions are met.
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 88]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+13.2  Error codes
+
+   The following considerations SHALL be met to register an error code
+   with IANA:
+
+   1) An error number and a one-line (80-character maximum) string is
+      registered for each error.
+
+   2) A complete description of the conditions under which the error is
+      detected shall be included in a publicly available document.  The
+      description shall be sufficiently clear to differentiate the error
+      from all other existing error codes.
+
+   3) The document should be available on a public web server and should
+      have a stable URL.
+
+   4) Error numbers registered by recognized standards bodies shall have
+      3- or 4-character error numbers.
+
+   5) Error numbers registered by all other organizations or individuals
+      shall have 4-character error numbers.
+
+   6) An error number shall not be redefined nor modified except by the
+      organization or individual that originally defined it, or their
+      successors or assigns.
+
+13.3  ServiceChange reasons
+
+   The following considerations SHALL be met to register service change
+   reason with IANA:
+
+   1) A one-phrase, 80-character maximum, unique reason code is
+      registered for each reason.
+
+   2) A complete description of the conditions under which the reason is
+      used is detected shall be included in a publicly available
+      document.  The description shall be sufficiently clear to
+      differentiate the reason from all other existing reasons.
+
+   3) The document should be available on a public web server and should
+      have a stable URL.
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 89]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+ANNEX A - Binary encoding of the protocol
+
+   This annex specifies the syntax of messages using the notation
+   defined in Recommendation X.680; Information technology - Abstract
+   Syntax Notation One (ASN.1): Specification of basic notation.
+   Messages shall be encoded for transmission by applying the basic
+   encoding rules specified in Recommendation X.690, Information
+   Technology - ASN.1 Encoding Rules: Specification of Basic Encoding
+   Rules (BER), Canonical Encoding Rules (CER) and Distinguished
+   Encoding Rules.
+
+A.1   Coding of wildcards
+
+   The use of wildcards ALL and CHOOSE is allowed in the protocol.  This
+   allows a MGC to partially specify Termination IDs and to let the MG
+   choose from the values that conform to the partial specification.
+   Termination IDs may encode a hierarchy of names.  This hierarchy is
+   provisioned.  For instance, a TerminationID may consist of a trunk
+   group, a trunk within the group and a circuit.  Wildcarding must be
+   possible at all levels.  The following paragraphs explain how this is
+   achieved.
+
+   The ASN.1 description uses octet strings of up to 8 octets in length
+   for Termination IDs.  This means that Termination IDs consist of at
+   most 64 bits.  A fully specified Termination ID may be preceded by a
+   sequence of wildcarding fields.  A wildcarding field is one octet in
+   length.  Bit 7 (the most significant bit) of this octet specifies
+   what type of wildcarding is invoked: if the bit value equals 1, then
+   the ALL wildcard is used; if the bit value if 0, then the CHOOSE
+   wildcard is used.  Bit 6 of the wildcarding field specifies whether
+   the wildcarding pertains to one level in the hierarchical naming
+   scheme (bit value 0) or to the level of the hierarchy specified in
+   the wildcarding field plus all lower levels (bit value 1).  Bits 0
+   through 5 of the wildcarding field specify the bit position in the
+   Termination ID at which the wildcarding starts.
+
+   We illustrate this scheme with some examples.  In these examples, the
+   most significant bit in a string of bits appears on the left hand
+   side.
+
+   Assume that Termination IDs are three octets long and that each octet
+   represents a level in a hierarchical naming scheme.  A valid
+   Termination ID is:
+
+      00000001 00011110 01010101.
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 90]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Addressing ALL names with prefix 00000001 00011110 is done as
+   follows:
+
+      wildcarding field: 10000111
+
+      Termination ID: 00000001 00011110 xxxxxxxx.
+
+   The values of the bits labeled "x" is irrelevant and shall be ignored
+   by the receiver.
+
+   Indicating to the receiver that it must choose a name with 00011110
+   as the second octet is done as follows:
+
+      wildcarding fields: 00010111 followed by 00000111
+
+      Termination ID: xxxxxxxx 00011110 xxxxxxxx.
+
+   The first wildcard field indicates a CHOOSE wildcard for the level in
+   the naming hierarchy starting at bit 23, the highest level in our
+   assumed naming scheme.  The second wildcard field indicates a CHOOSE
+   wildcard for the level in the naming hierarchy starting at bit 7, the
+   lowest level in our assumed naming scheme.
+
+   Finally, a CHOOSE-wildcarded name with the highest level of the name
+   equal to 00000001 is specified as follows:
+
+      wildcard field: 01001111
+
+      Termination ID: 0000001 xxxxxxxx xxxxxxxx .
+
+   Bit value 1 at bit position 6 of the first octet of the wildcard
+   field indicates that the wildcarding pertains to the specified level
+   in the naming hierarchy and all lower levels.
+
+   Context IDs may also be wildcarded.  In the case of Context IDs,
+   however, specifying partial names is not allowed.  Context ID 0x0
+   SHALL be used to indicate the NULL Context, Context ID 0xFFFFFFFE
+   SHALL be used to indicate a CHOOSE wildcard, and Context ID
+   0xFFFFFFFF SHALL be used to indicate an ALL wildcard.
+
+   TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
+   Termination.
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                    [Page 91]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+A.2   ASN.1 syntax specification
+
+   This subclause contains the ASN.1 specification of the H.248.1
+   protocol syntax.
+
+     NOTE 1 - In case a transport mechanism is used that employs
+     application level framing, the definition of Transaction below
+     changes.  Refer to the annex or to the Recommendation of the H.248
+     sub-series defining the transport mechanism for the definition that
+     applies in that case.
+
+     NOTE 2 - The ASN.1 specification below contains a clause defining
+     TerminationIDList as a sequence of TerminationIDs.  The length of
+     this sequence SHALL be one, except possibly when used in
+     contextAuditResult.
+
+     NOTE 3 - This syntax specification does not enforce all
+     restrictions on element inclusions and values.  Some additional
+     restrictions are stated in comments and other restrictions appear
+     in the text of this RFC.  These additional restrictions
+     are part of the protocol even though not enforced by this
+     specification.
+
+     NOTE 4 - The ASN.1 module in this Annex uses octet string types to
+     encode values for property parameter, signal parameter and event
+     parameter values and statistics.  The actual types of these values
+     vary and are specified in Annex C or the relevant package
+     definition.
+
+   A value is first BER-encoded based on its type using the table below.
+   The result of this BER-encoding is then encoded as an ASN.1 octet
+   string, "double wrapping" the value.  The format specified in Annex C
+   or the package relates to BER encoding according to the following
+   table:
+
+   Type Specified in Package   ASN.1 BER Type
+
+   String                      IA5String or UTF8String (Note 4)
+
+   Integer (4 Octet)           INTEGER
+
+   Double (8 octet signed int) INTEGER (Note 3)
+
+   Character (UTF-8, Note 1)   IA5String
+
+   Enumeration                 ENUMERATED
+
+   Boolean                     BOOLEAN
+
+
+
+Groves, et al.              Standards Track                    [Page 92]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Unsigned Integer (Note 2)   INTEGER  (Note 3)
+
+   Octet (String)              OCTET STRING
+
+     Note 1: Can be more than one byte
+
+     Note 2: Unsigned integer is referenced in Annex C
+
+     Note 3: The BER encoding of INTEGER does not imply the use of 4
+     bytes.
+
+     Note 4: String should be encoded as IA5String when the contents
+     are all ASCII characters, but as UTF8String if it contains any
+     Non-ASCII characters.
+
+   See ITU-T Rec.  X.690, 8.7, for the definition of the encoding of an
+   octet string value.
+
+   MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=
+   BEGIN
+
+   MegacoMessage ::= SEQUENCE
+   {
+      authHeader     AuthenticationHeader OPTIONAL,
+      mess           Message
+   }
+
+   AuthenticationHeader ::= SEQUENCE
+   {
+      secParmIndex   SecurityParmIndex,
+      seqNum         SequenceNum,
+      ad             AuthData
+   }
+
+   SecurityParmIndex ::= OCTET STRING(SIZE(4))
+
+   SequenceNum       ::= OCTET STRING(SIZE(4))
+
+   AuthData          ::= OCTET STRING (SIZE (12..32))
+
+   Message ::= SEQUENCE
+   {
+      version           INTEGER(0..99),
+      -- The version of the protocol defined here is equal to 1.
+      mId               MId,  -- Name/address of message originator
+      messageBody       CHOICE
+      {
+         messageError      ErrorDescriptor,
+
+
+
+Groves, et al.              Standards Track                    [Page 93]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         transactions      SEQUENCE OF Transaction
+      },
+      ...
+   }
+
+   MId ::= CHOICE
+   {
+      ip4Address           IP4Address,
+      ip6Address           IP6Address,
+      domainName           DomainName,
+      deviceName           PathName,
+      mtpAddress           OCTET STRING(SIZE(2..4)),
+      -- Addressing structure of mtpAddress:
+      --     25 - 15           0
+      --        |  PC        | NI |
+      --      24 - 14 bits    2 bits
+      -- Note: 14 bits are defined for international use.
+      -- Two national options exist where the point code is 16 or 24
+      -- bits.
+      -- To octet align the mtpAddress, the MSBs shall be encoded as 0s.
+             ...
+   }
+
+   DomainName ::= SEQUENCE
+   {
+      name        IA5String,
+      -- The name starts with an alphanumeric digit followed by a
+      -- sequence of alphanumeric digits, hyphens and dots.  No two
+      -- dots shall occur consecutively.
+      portNumber     INTEGER(0..65535) OPTIONAL
+   }
+
+   IP4Address ::= SEQUENCE
+   {
+      address        OCTET STRING (SIZE(4)),
+      portNumber     INTEGER(0..65535) OPTIONAL
+   }
+
+   IP6Address ::= SEQUENCE
+   {
+      address        OCTET STRING (SIZE(16)),
+      portNumber     INTEGER(0..65535) OPTIONAL
+   }
+
+   PathName ::= IA5String(SIZE (1..64))
+   -- See A.3
+
+   Transaction ::= CHOICE
+
+
+
+Groves, et al.              Standards Track                    [Page 94]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   {
+      transactionRequest   TransactionRequest,
+      transactionPending   TransactionPending,
+      transactionReply     TransactionReply,
+      transactionResponseAck  TransactionResponseAck,
+          -- use of response acks is dependent on underlying transport
+      ...
+   }
+
+   TransactionId ::= INTEGER(0..4294967295)  -- 32-bit unsigned integer
+
+   TransactionRequest ::= SEQUENCE
+   {
+      transactionId        TransactionId,
+      actions              SEQUENCE OF ActionRequest,
+      ...
+   }
+
+   TransactionPending ::= SEQUENCE
+   {
+      transactionId        TransactionId,
+      ...
+   }
+
+   TransactionReply ::= SEQUENCE
+   {
+      transactionId        TransactionId,
+      immAckRequired       NULL OPTIONAL,
+      transactionResult    CHOICE
+      {
+           transactionError   ErrorDescriptor,
+           actionReplies      SEQUENCE OF ActionReply
+      },
+      ...
+   }
+
+   TransactionResponseAck ::= SEQUENCE OF TransactionAck
+   TransactionAck ::= SEQUENCE
+   {
+      firstAck       TransactionId,
+      lastAck        TransactionId OPTIONAL
+   }
+
+   ErrorDescriptor ::= SEQUENCE
+   {
+      errorCode      ErrorCode,
+      errorText      ErrorText OPTIONAL
+   }
+
+
+
+Groves, et al.              Standards Track                    [Page 95]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   ErrorCode ::= INTEGER(0..65535)
+   -- See clause 13 for IANA Considerations with respect to error codes
+
+   ErrorText ::= IA5String
+
+   ContextID ::= INTEGER(0..4294967295)
+
+   -- Context   NULL Value: 0
+   -- Context CHOOSE Value: 4294967294 (0xFFFFFFFE)
+   -- Context    ALL Value: 4294967295 (0xFFFFFFFF)
+
+
+   ActionRequest ::= SEQUENCE
+   {
+      contextId         ContextID,
+      contextRequest       ContextRequest OPTIONAL,
+      contextAttrAuditReq  ContextAttrAuditRequest OPTIONAL,
+      commandRequests   SEQUENCE OF CommandRequest
+   }
+
+   ActionReply ::= SEQUENCE
+   {
+      contextId         ContextID,
+      errorDescriptor   ErrorDescriptor OPTIONAL,
+      contextReply      ContextRequest OPTIONAL,
+      commandReply      SEQUENCE OF CommandReply
+   }
+
+   ContextRequest ::= SEQUENCE
+   {
+      priority       INTEGER(0..15) OPTIONAL,
+      emergency      BOOLEAN OPTIONAL,
+      topologyReq    SEQUENCE OF TopologyRequest OPTIONAL,
+      ...
+   }
+
+   ContextAttrAuditRequest ::= SEQUENCE
+   {
+      topology    NULL OPTIONAL,
+      emergency   NULL OPTIONAL,
+      priority    NULL OPTIONAL,
+      ...
+   }
+
+   CommandRequest ::= SEQUENCE
+   {
+      command           Command,
+
+
+
+Groves, et al.              Standards Track                    [Page 96]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      optional          NULL OPTIONAL,
+      wildcardReturn    NULL OPTIONAL,
+      ...
+   }
+
+   Command ::= CHOICE
+   {
+      addReq               AmmRequest,
+      moveReq              AmmRequest,
+      modReq               AmmRequest,
+      -- Add, Move, Modify requests have the same parameters
+      subtractReq          SubtractRequest,
+      auditCapRequest      AuditRequest,
+      auditValueRequest    AuditRequest,
+      notifyReq            NotifyRequest,
+      serviceChangeReq     ServiceChangeRequest,
+      ...
+   }
+
+   CommandReply ::= CHOICE
+   {
+      addReply                AmmsReply,
+      moveReply               AmmsReply,
+      modReply                AmmsReply,
+      subtractReply           AmmsReply,
+      -- Add, Move, Modify, Subtract replies have the same parameters
+      auditCapReply           AuditReply,
+      auditValueReply         AuditReply,
+      notifyReply             NotifyReply,
+      serviceChangeReply      ServiceChangeReply,
+      ...
+   }
+
+   TopologyRequest ::= SEQUENCE
+   {
+      terminationFrom         TerminationID,
+      terminationTo           TerminationID,
+      topologyDirection       ENUMERATED
+      {
+         bothway(0),
+         isolate(1),
+         oneway(2)
+      },
+      ...
+   }
+
+   AmmRequest ::= SEQUENCE
+   {
+
+
+
+Groves, et al.              Standards Track                    [Page 97]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      terminationID        TerminationIDList,
+      descriptors          SEQUENCE OF AmmDescriptor,
+      -- At most one descriptor of each type (see AmmDescriptor)
+      -- allowed in the sequence.
+      ...
+   }
+
+   AmmDescriptor ::= CHOICE
+   {
+      mediaDescriptor         MediaDescriptor,
+      modemDescriptor         ModemDescriptor,
+      muxDescriptor           MuxDescriptor,
+      eventsDescriptor        EventsDescriptor,
+      eventBufferDescriptor   EventBufferDescriptor,
+      signalsDescriptor       SignalsDescriptor,
+      digitMapDescriptor      DigitMapDescriptor,
+      auditDescriptor         AuditDescriptor,
+      ...
+   }
+
+   AmmsReply ::= SEQUENCE
+   {
+      terminationID        TerminationIDList,
+      terminationAudit     TerminationAudit OPTIONAL,
+      ...
+   }
+
+   SubtractRequest ::= SEQUENCE
+   {
+      terminationID        TerminationIDList,
+      auditDescriptor      AuditDescriptor OPTIONAL,
+      ...
+   }
+
+   AuditRequest ::= SEQUENCE
+   {
+      terminationID        TerminationID,
+      auditDescriptor      AuditDescriptor,
+      ...
+   }
+
+   AuditReply ::= CHOICE
+   {
+      contextAuditResult   TerminationIDList,
+      error                ErrorDescriptor,
+      auditResult          AuditResult,
+      ...
+   }
+
+
+
+Groves, et al.              Standards Track                    [Page 98]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   AuditResult ::= SEQUENCE
+   {
+
+      terminationID           TerminationID,
+      terminationAuditResult  TerminationAudit
+   }
+
+   TerminationAudit ::= SEQUENCE OF AuditReturnParameter
+
+   AuditReturnParameter ::= CHOICE
+   {
+      errorDescriptor         ErrorDescriptor,
+      mediaDescriptor         MediaDescriptor,
+      modemDescriptor         ModemDescriptor,
+      muxDescriptor           MuxDescriptor,
+      eventsDescriptor        EventsDescriptor,
+      eventBufferDescriptor   EventBufferDescriptor,
+      signalsDescriptor       SignalsDescriptor,
+      digitMapDescriptor      DigitMapDescriptor,
+      observedEventsDescriptor   ObservedEventsDescriptor,
+      statisticsDescriptor    StatisticsDescriptor,
+      packagesDescriptor      PackagesDescriptor,
+      emptyDescriptors        AuditDescriptor,
+      ...
+   }
+
+   AuditDescriptor ::= SEQUENCE
+   {
+      auditToken  BIT STRING
+         {
+            muxToken(0), modemToken(1), mediaToken(2),
+            eventsToken(3), signalsToken(4),
+            digitMapToken(5), statsToken(6),
+            observedEventsToken(7),
+            packagesToken(8), eventBufferToken(9)
+         } OPTIONAL,
+      ...
+   }
+
+   NotifyRequest ::= SEQUENCE
+   {
+      terminationID              TerminationIDList,
+      observedEventsDescriptor   ObservedEventsDescriptor,
+      errorDescriptor            ErrorDescriptor OPTIONAL,
+      ...
+   }
+
+
+
+
+Groves, et al.              Standards Track                    [Page 99]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   NotifyReply ::= SEQUENCE
+   {
+      terminationID           TerminationIDList,
+      errorDescriptor         ErrorDescriptor OPTIONAL,
+      ...
+   }
+
+   ObservedEventsDescriptor ::= SEQUENCE
+   {
+      requestId               RequestID,
+      observedEventLst        SEQUENCE OF ObservedEvent
+   }
+
+   ObservedEvent ::= SEQUENCE
+   {
+      eventName            EventName,
+      streamID             StreamID OPTIONAL,
+      eventParList         SEQUENCE OF EventParameter,
+      timeNotation         TimeNotation OPTIONAL,
+      ...
+   }
+
+   EventName ::= PkgdName
+
+   EventParameter ::= SEQUENCE
+   {
+      eventParameterName      Name,
+      value                   Value,
+   -- For use of extraInfo see the comment related to PropertyParm
+      extraInfo CHOICE
+      {
+         relation Relation,
+         range    BOOLEAN,
+         sublist  BOOLEAN
+      } OPTIONAL,
+      ...
+   }
+
+   ServiceChangeRequest ::= SEQUENCE
+   {
+      terminationID           TerminationIDList,
+      serviceChangeParms      ServiceChangeParm,
+      ...
+   }
+
+   ServiceChangeReply ::= SEQUENCE
+   {
+      terminationID           TerminationIDList,
+
+
+
+Groves, et al.              Standards Track                   [Page 100]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      serviceChangeResult     ServiceChangeResult,
+      ...
+   }
+
+   -- For ServiceChangeResult, no parameters are mandatory.  Hence the
+   -- distinction between ServiceChangeParm and ServiceChangeResParm.
+
+   ServiceChangeResult ::= CHOICE
+   {
+      errorDescriptor            ErrorDescriptor,
+      serviceChangeResParms      ServiceChangeResParm
+   }
+
+   WildcardField ::= OCTET STRING(SIZE(1))
+
+   TerminationID ::= SEQUENCE
+   {
+      wildcard SEQUENCE OF WildcardField,
+      id    OCTET STRING(SIZE(1..8)),
+      ...
+   }
+   -- See A.1 for explanation of wildcarding mechanism.
+   -- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination.
+
+   TerminationIDList ::= SEQUENCE OF TerminationID
+
+   MediaDescriptor ::= SEQUENCE
+   {
+
+      termStateDescr TerminationStateDescriptor OPTIONAL,
+      streams     CHOICE
+      {
+         oneStream      StreamParms,
+         multiStream    SEQUENCE OF StreamDescriptor
+      } OPTIONAL,
+      ...
+   }
+
+   StreamDescriptor ::= SEQUENCE
+   {
+      streamID          StreamID,
+      streamParms       StreamParms
+   }
+
+   StreamParms ::= SEQUENCE
+   {
+      localControlDescriptor     LocalControlDescriptor OPTIONAL,
+      localDescriptor            LocalRemoteDescriptor OPTIONAL,
+
+
+
+Groves, et al.              Standards Track                   [Page 101]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      remoteDescriptor           LocalRemoteDescriptor OPTIONAL,
+      ...
+   }
+
+   LocalControlDescriptor ::= SEQUENCE
+   {
+
+      streamMode        StreamMode OPTIONAL,
+      reserveValue      BOOLEAN OPTIONAL,
+      reserveGroup      BOOLEAN OPTIONAL,
+      propertyParms     SEQUENCE OF PropertyParm,
+      ...
+   }
+
+   StreamMode ::= ENUMERATED
+   {
+      sendOnly(0),
+      recvOnly(1),
+      sendRecv(2),
+      inactive(3),
+      loopBack(4),
+         ...
+   }
+
+   -- In PropertyParm, value is a SEQUENCE OF octet string.  When sent
+   -- by an MGC the interpretation is as follows:
+   -- empty sequence means CHOOSE
+   -- one element sequence specifies value
+   -- If the sublist field is not selected, a longer sequence means
+   -- "choose one of the values" (i.e., value1 OR value2 OR ...)
+   -- If the sublist field is selected,
+   -- a sequence with more than one element encodes the value of a
+   -- list-valued property (i.e., value1 AND value2 AND ...).
+   -- The relation field may only be selected if the value sequence
+   -- has length 1.  It indicates that the MG has to choose a value
+   -- for the property.  E.g., x > 3 (using the greaterThan
+   -- value for relation) instructs the MG to choose any value larger
+   -- than 3 for property x.
+   -- The range field may only be selected if the value sequence
+   -- has length 2.  It indicates that the MG has to choose a value
+   -- in the range between the first octet in the value sequence and
+   -- the trailing octet in the value sequence, including the
+   -- boundary values.
+   -- When sent by the MG, only responses to an AuditCapability request
+   -- may contain multiple values, a range, or a relation field.
+
+   PropertyParm ::= SEQUENCE
+   {
+
+
+
+Groves, et al.              Standards Track                   [Page 102]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      name        PkgdName,
+      value       SEQUENCE OF OCTET STRING,
+      extraInfo   CHOICE
+      {
+         relation    Relation,
+         range       BOOLEAN,
+         sublist     BOOLEAN
+      } OPTIONAL,
+      ...
+   }
+
+   Name ::= OCTET STRING(SIZE(2))
+
+   PkgdName ::= OCTET STRING(SIZE(4))
+   -- represents Package Name (2 octets) plus Property, Event,
+   -- Signal Names or Statistics ID. (2 octets)
+   -- To wildcard a package use 0xFFFF for first two octets, choose
+   -- is not allowed.  To reference native property tag specified in
+   -- Annex C, use 0x0000 as first two octets.
+   -- To wildcard a Property, Event, Signal, or Statistics ID, use
+   -- 0xFFFF for last two octets, choose is not allowed.
+   -- Wildcarding of Package Name is permitted only if Property,
+   -- Event, Signal, or Statistics ID are
+   -- also wildcarded.
+
+   Relation ::= ENUMERATED
+   {
+      greaterThan(0),
+      smallerThan(1),
+      unequalTo(2),
+      ...
+   }
+
+   LocalRemoteDescriptor ::= SEQUENCE
+   {
+      propGrps SEQUENCE OF PropertyGroup,
+      ...
+   }
+
+   PropertyGroup ::= SEQUENCE OF PropertyParm
+
+   TerminationStateDescriptor ::= SEQUENCE
+   {
+      propertyParms        SEQUENCE OF PropertyParm,
+      eventBufferControl   EventBufferControl OPTIONAL,
+      serviceState         ServiceState OPTIONAL,
+      ...
+   }
+
+
+
+Groves, et al.              Standards Track                   [Page 103]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   EventBufferControl ::= ENUMERATED
+   {
+      off(0),
+      lockStep(1),
+      ...
+   }
+
+   ServiceState ::= ENUMERATED
+
+   {
+      test(0),
+      outOfSvc(1),
+      inSvc(2),
+         ...
+   }
+
+   MuxDescriptor   ::= SEQUENCE
+   {
+      muxType           MuxType,
+      termList          SEQUENCE OF TerminationID,
+      nonStandardData   NonStandardData OPTIONAL,
+      ...
+   }
+
+   MuxType ::= ENUMERATED
+   {
+      h221(0),
+      h223(1),
+      h226(2),
+      v76(3),
+      ...
+   }
+
+   StreamID ::= INTEGER(0..65535)   -- 16-bit unsigned integer
+
+   EventsDescriptor ::= SEQUENCE
+   {
+      requestID      RequestID OPTIONAL,
+                  -- RequestID must be present if eventList
+                  -- is non empty
+      eventList      SEQUENCE OF RequestedEvent,
+      ...
+   }
+
+   RequestedEvent ::= SEQUENCE
+   {
+      pkgdName       PkgdName,
+
+
+
+Groves, et al.              Standards Track                   [Page 104]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      streamID       StreamID OPTIONAL,
+      eventAction    RequestedActions OPTIONAL,
+      evParList      SEQUENCE OF EventParameter,
+      ...
+   }
+
+   RequestedActions ::= SEQUENCE
+   {
+      keepActive        BOOLEAN OPTIONAL,
+      eventDM           EventDM OPTIONAL,
+      secondEvent          SecondEventsDescriptor OPTIONAL,
+      signalsDescriptor    SignalsDescriptor OPTIONAL,
+      ...
+   }
+
+   EventDM ::= CHOICE
+   {  digitMapName   DigitMapName,
+      digitMapValue  DigitMapValue
+   }
+
+   SecondEventsDescriptor ::= SEQUENCE
+   {
+      requestID         RequestID OPTIONAL,
+      eventList         SEQUENCE OF SecondRequestedEvent,
+      ...
+   }
+
+   SecondRequestedEvent ::= SEQUENCE
+   {
+      pkgdName          PkgdName,
+      streamID          StreamID OPTIONAL,
+      eventAction       SecondRequestedActions OPTIONAL,
+      evParList         SEQUENCE OF EventParameter,
+      ...
+   }
+
+   SecondRequestedActions ::= SEQUENCE
+   {
+      keepActive           BOOLEAN OPTIONAL,
+      eventDM              EventDM OPTIONAL,
+      signalsDescriptor    SignalsDescriptor OPTIONAL,
+      ...
+   }
+
+   EventBufferDescriptor ::= SEQUENCE OF EventSpec
+
+   EventSpec ::= SEQUENCE
+   {
+
+
+
+Groves, et al.              Standards Track                   [Page 105]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      eventName      EventName,
+      streamID       StreamID OPTIONAL,
+      eventParList   SEQUENCE OF EventParameter,
+      ...
+   }
+
+   SignalsDescriptor ::= SEQUENCE OF SignalRequest
+
+   SignalRequest ::=CHOICE
+   {
+      signal         Signal,
+      seqSigList     SeqSigList,
+      ...
+   }
+
+   SeqSigList ::= SEQUENCE
+   {
+      id                INTEGER(0..65535),
+      signalList        SEQUENCE OF Signal
+   }
+
+   Signal ::= SEQUENCE
+   {
+      signalName        SignalName,
+      streamID          StreamID OPTIONAL,
+      sigType           SignalType OPTIONAL,
+      duration          INTEGER (0..65535) OPTIONAL,
+      notifyCompletion  NotifyCompletion OPTIONAL,
+      keepActive        BOOLEAN OPTIONAL,
+      sigParList        SEQUENCE OF SigParameter,
+      ...
+   }
+
+   SignalType ::= ENUMERATED
+   {
+      brief(0),
+      onOff(1),
+      timeOut(2),
+      ...
+   }
+
+   SignalName ::= PkgdName
+
+   NotifyCompletion ::= BIT STRING
+   {
+      onTimeOut(0), onInterruptByEvent(1),
+      onInterruptByNewSignalDescr(2), otherReason(3)
+   }
+
+
+
+Groves, et al.              Standards Track                   [Page 106]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   SigParameter ::= SEQUENCE
+   {
+      sigParameterName     Name,
+      value                Value,
+      -- For use of extraInfo see the comment related to PropertyParm
+      extraInfo CHOICE
+      {
+         relation Relation,
+         range    BOOLEAN,
+         sublist  BOOLEAN
+
+      } OPTIONAL,
+      ...
+   }
+
+   -- For an AuditCapReply with all events, the RequestID SHALL be ALL.
+   -- ALL is represented by 0xffffffff.
+
+   RequestID ::= INTEGER(0..4294967295)   -- 32-bit unsigned integer
+
+   ModemDescriptor ::= SEQUENCE
+   {
+      mtl               SEQUENCE OF ModemType,
+      mpl               SEQUENCE OF PropertyParm,
+      nonStandardData   NonStandardData OPTIONAL
+   }
+
+   ModemType ::= ENUMERATED
+   {
+      v18(0),
+      v22(1),
+      v22bis(2),
+      v32(3),
+      v32bis(4),
+      v34(5),
+      v90(6),
+      v91(7),
+      synchISDN(8),
+      ...
+   }
+
+   DigitMapDescriptor ::= SEQUENCE
+   {
+      digitMapName   DigitMapName   OPTIONAL,
+      digitMapValue  DigitMapValue  OPTIONAL
+   }
+
+
+
+
+Groves, et al.              Standards Track                   [Page 107]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   DigitMapName ::= Name
+
+   DigitMapValue ::= SEQUENCE
+   {
+      startTimer     INTEGER(0..99) OPTIONAL,
+      shortTimer     INTEGER(0..99) OPTIONAL,
+      longTimer      INTEGER(0..99) OPTIONAL,
+      digitMapBody      IA5String,
+   -- Units are seconds for start, short and long timers, and
+   -- hundreds of milliseconds for duration timer.  Thus start,
+   -- short, and long range from 1 to 99 seconds and duration
+   -- from 100 ms to 9.9 s
+      -- See A.3 for explanation of digit map syntax
+      ...
+   }
+
+   ServiceChangeParm ::= SEQUENCE
+   {
+      serviceChangeMethod     ServiceChangeMethod,
+      serviceChangeAddress    ServiceChangeAddress OPTIONAL,
+      serviceChangeVersion    INTEGER(0..99) OPTIONAL,
+      serviceChangeProfile    ServiceChangeProfile OPTIONAL,
+      serviceChangeReason     Value,
+   -- A serviceChangeReason consists of a numeric reason code
+   -- and an optional text description.
+   -- The serviceChangeReason SHALL be a string consisting of
+   -- a decimal reason code, optionally followed by a single
+   -- space character and a textual description string.
+   -- This string is first BER-encoded as an IA5String.
+   -- The result of this BER-encoding is then encoded as
+   -- an ASN.1 OCTET STRING type, "double wrapping" the
+   -- value as was done for package elements.
+      serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
+                                        -- 32-bit unsigned integer
+      serviceChangeMgcId      MId OPTIONAL,
+      timeStamp               TimeNotation OPTIONAL,
+      nonStandardData         NonStandardData OPTIONAL,
+      ...
+   }
+
+   ServiceChangeAddress ::= CHOICE
+   {
+      portNumber        INTEGER(0..65535),    -- TCP/UDP port number
+      ip4Address        IP4Address,
+      ip6Address        IP6Address,
+      domainName        DomainName,
+      deviceName        PathName,
+      mtpAddress        OCTET STRING(SIZE(2..4)),
+
+
+
+Groves, et al.              Standards Track                   [Page 108]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      ...
+   }
+
+   ServiceChangeResParm ::= SEQUENCE
+   {
+      serviceChangeMgcId      MId OPTIONAL,
+      serviceChangeAddress    ServiceChangeAddress OPTIONAL,
+      serviceChangeVersion    INTEGER(0..99) OPTIONAL,
+      serviceChangeProfile    ServiceChangeProfile OPTIONAL,
+      timestamp               TimeNotation OPTIONAL,
+      ...
+   }
+
+   ServiceChangeMethod ::= ENUMERATED
+
+   {
+      failover(0),
+      forced(1),
+      graceful(2),
+      restart(3),
+      disconnected(4),
+      handOff(5),
+      ...
+   }
+
+   ServiceChangeProfile ::= SEQUENCE
+   {
+      profileName    IA5String(SIZE (1..67))
+      -- 64 characters for name, 1 for "/", 2 for version to match ABNF
+   }
+
+   PackagesDescriptor ::= SEQUENCE OF PackagesItem
+
+   PackagesItem ::= SEQUENCE
+   {
+      packageName       Name,
+      packageVersion    INTEGER(0..99),
+      ...
+   }
+
+   StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter
+
+   StatisticsParameter ::= SEQUENCE
+   {
+      statName       PkgdName,
+      statValue      Value OPTIONAL
+   }
+
+
+
+
+Groves, et al.              Standards Track                   [Page 109]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   NonStandardData ::= SEQUENCE
+   {
+      nonStandardIdentifier   NonStandardIdentifier,
+      data                    OCTET STRING
+   }
+
+   NonStandardIdentifier ::= CHOICE
+   {
+      object            OBJECT IDENTIFIER,
+      h221NonStandard   H221NonStandard,
+      experimental      IA5String(SIZE(8)),
+          -- first two characters should be "X-" or "X+"
+      ...
+   }
+
+   H221NonStandard ::= SEQUENCE
+   {  t35CountryCode1   INTEGER(0..255),
+      t35CountryCode2   INTEGER(0..255),      -- country, as per T.35
+      t35Extension      INTEGER(0..255),      -- assigned nationally
+      manufacturerCode     INTEGER(0..65535), -- assigned nationally
+      ...
+   }
+
+   TimeNotation ::= SEQUENCE
+   {
+      date     IA5String(SIZE(8)),  -- yyyymmdd format
+      time     IA5String(SIZE(8))   -- hhmmssss format
+      -- per ISO 8601:1988
+   }
+
+   Value ::= SEQUENCE OF OCTET STRING
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 110]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+A.3   Digit maps and path names
+
+   From a syntactic viewpoint, digit maps are strings with syntactic
+   restrictions imposed upon them.  The syntax of valid digit maps is
+   specified in ABNF [RFC 2234].  The syntax for digit maps presented in
+   this subclause is for illustrative purposes only.  The definition of
+   digitMap in Annex B takes precedence in the case of differences
+   between the two.
+
+     digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")"
+               LWSP)
+
+     digitStringList = digitString *( LWSP "|" LWSP digitString )
+     digitString = 1*(digitStringElement)
+     digitStringElement = digitPosition [DOT]
+     digitPosition = digitMapLetter / digitMapRange
+     digitMapRange = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
+     digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter)
+     digitMapLetter = DIGIT           ;digits 0-9
+             / %x41-4B / %x61-6B    ;a-k and A-K
+             / "L"/ "S"       ;Inter-event timers
+                                 ;(long, short)
+             / "Z"            ;Long duration event
+     DOT = %x2E ; "."
+     LWSP = *(WSP / COMMENT / EOL)
+     WSP = SP / HTAB
+     COMMENT = ";" *(SafeChar / RestChar / WSP) EOL
+     EOL = (CR [LF]) / LF
+     SP = %x20
+     HTAB = %x09
+     CR = %x0D
+     LF = %x0A
+     SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" /
+         "'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "\" /
+         "(" / ")" / "%" / "."
+     RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
+         "<" / ">" / "=" / %x22
+     DIGIT = %x30-39       ; digits 0 through 9
+     ALPHA = %x41-5A / %x61-7A; A-Z, a-z
+
+   A path name is also a string with syntactic restrictions imposed upon
+   it.  The ABNF production defining it is copied from Annex B.
+
+     ; Total length of pathNAME must not exceed 64 chars.
+     pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
+                            ["@" pathDomainName ]
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 111]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+     ; ABNF allows two or more consecutive "." although it is
+     ; meaningless in a path domain name.
+     pathDomainName       = (ALPHA / DIGIT / "*" )
+                            *63(ALPHA / DIGIT / "-"
+     NAME = ALPHA *63(ALPHA / DIGIT / "_" )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 112]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+ANNEX B - Text encoding of the protocol
+
+B.1   Coding of wildcards
+
+   In a text encoding of the protocol, while TerminationIDs are
+   arbitrary, by judicious choice of names, the wildcard character, "*"
+   may be made more useful.  When the wildcard character is encountered,
+   it will "match" all TerminationIDs having the same previous and
+   following characters (if appropriate).  For example, if there were
+   TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
+   R13/3/* would match all of them.  There are some circumstances where
+   ALL Terminations must be referred to.  The TerminationID "*"
+   suffices, and is referred to as ALL.  The CHOOSE TerminationID "$"
+   may be used to signal to the MG that it has to create an ephemeral
+   Termination or select an idle physical Termination.
+
+B.2   ABNF specification
+
+   The protocol syntax is presented in ABNF according to RFC 2234.
+
+      Note 1 - This syntax specification does not enforce all
+      restrictions on element inclusions and values.  Some additional
+      restrictions are stated in comments and other restrictions appear
+      in the text of this RFC.  These additional restrictions are part
+      of the protocol even though not enforced by this specification.
+
+      Note 2 - The syntax is context-dependent.  For example, "Add" can
+      be the AddToken or a NAME depending on the context in which it
+      occurs.
+
+   Everything in the ABNF and text encoding is case insensitive.  This
+   includes TerminationIDs, digitmap Ids etc.  SDP is case sensitive as
+   per RFC 2327.
+
+   ; NOTE -- The ABNF in this section uses the VALUE construct (or lists
+   ; of VALUE constructs) to encode various package element values
+   ; (properties, signal parameters, etc.).  The types of these values
+   ; vary and are specified the relevant package definition.  Several
+   ; such types are described in section 12.2.
+   ;
+   ; The ABNF specification for VALUE allows a quotedString form or a
+   ; collection of SafeChars.  The encoding of package element values
+   ; into ABNF VALUES is specified below.  If a type's encoding allows
+   ; characters other than SafeChars, the quotedString form MUST be used
+   ; for all values of that type, even for specific values that consist
+   ; only of SafeChars.
+   ;
+
+
+
+
+Groves, et al.              Standards Track                   [Page 113]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   ; String:  A string MUST use the quotedString form of VALUE and can
+   ; contain anything allowable in the quotedString form.
+   ;
+   ; Integer, Double, and Unsigned Integer:  Decimal values can be
+   ; encoded using characters 0-9.  Hexadecimal values must be prefixed
+   ; with '0x' and can use characters 0-9,a-f,A-F.  An octal format is
+   ; not supported.  Negative integers start with '-' and MUST be
+   ; Decimal.  The SafeChar form of VALUE MUST be used.
+   ;
+   ; Character:  A UTF-8 encoding of a single letter surrounded by
+   ; double quotes.
+   ;
+   ; Enumeration:  An enumeration MUST use the SafeChar form of VALUE
+   ; and can contain anything allowable in the SafeChar form.
+   ;
+   ; Boolean:  Boolean values are encoded as "on" and "off" and are
+   ; case insensitive.  The SafeChar form of VALUE MUST be used.
+   ;
+   ; Future types:  Any defined types MUST fit within
+   ; the ABNF specification of VALUE.  Specifically, if a type's
+   ; encoding allows characters other than SafeChars, the quotedString
+   ; form MUST be used for all values of that type, even for specific
+   ; values that consist only of SafeChars.
+   ;
+   ; Note that there is no way to use the double quote character within
+   ; a value.
+   ;
+   ; Note that SDP disallows whitespace at the beginning of a line,
+   ; Megaco ABNF allows whitespace before the beginning of the SDP in
+   ; the Local/Remote descriptor.  Parsers should accept whitespace
+   ; between the LBRKT following the Local/Remote token and the
+   ; beginning of the SDP.
+
+   megacoMessage        = LWSP [authenticationHeader SEP ] message
+
+   authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
+                          SequenceNum COLON AuthData
+
+   SecurityParmIndex    = "0x" 8(HEXDIG)
+   SequenceNum          = "0x" 8(HEXDIG)
+   AuthData             = "0x" 24*64(HEXDIG)
+
+   message            = MegacopToken SLASH Version SEP mId SEP
+   messageBody
+   ; The version of the protocol defined here is equal to 1.
+
+   messageBody          = ( errorDescriptor / transactionList )
+
+
+
+
+Groves, et al.              Standards Track                   [Page 114]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   transactionList      = 1*( transactionRequest / transactionReply /
+                          transactionPending / transactionResponseAck )
+   ;Use of response acks is dependent on underlying transport
+
+
+   transactionPending   = PendingToken EQUAL TransactionID LBRKT
+   RBRKT
+
+   transactionResponseAck = ResponseAckToken LBRKT transactionAck
+                  *(COMMA transactionAck) RBRKT
+   transactionAck = transactionID / (transactionID "-" transactionID)
+
+   transactionRequest   = TransToken EQUAL TransactionID LBRKT
+                          actionRequest *(COMMA actionRequest) RBRKT
+
+   actionRequest        = CtxToken EQUAL ContextID LBRKT ((
+                          contextRequest [COMMA  commandRequestList])
+                          / commandRequestList) RBRKT
+
+   contextRequest    = ((contextProperties [COMMA contextAudit])
+               / contextAudit)
+
+   contextProperties    = contextProperty *(COMMA contextProperty)
+
+   ; at-most-once
+   contextProperty    = (topologyDescriptor / priority / EmergencyToken)
+
+   contextAudit   = ContextAuditToken LBRKT contextAuditProperties
+                         *(COMMA contextAuditProperties) RBRKT
+
+   ; at-most-once
+   contextAuditProperties = ( TopologyToken / EmergencyToken /
+                              PriorityToken )
+
+   ; "O-" indicates an optional command
+   ; "W-" indicates a wildcarded response to a command
+   commandRequestList = ["O-"] ["W-"] commandRequest
+                        *(COMMA ["O-"] ["W-"]commandRequest)
+
+   commandRequest      = ( ammRequest / subtractRequest / auditRequest /
+                           notifyRequest / serviceChangeRequest)
+
+   transactionReply     = ReplyToken EQUAL TransactionID LBRKT
+                     [ ImmAckRequiredToken COMMA]
+                   ( errorDescriptor / actionReplyList ) RBRKT
+
+   actionReplyList      = actionReply *(COMMA actionReply )
+
+
+
+
+Groves, et al.              Standards Track                   [Page 115]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   actionReply          = CtxToken EQUAL ContextID LBRKT
+                     ( errorDescriptor / commandReply ) /
+            (commandReply COMMA errorDescriptor) ) RBRKT
+
+   commandReply      = (( contextProperties [COMMA commandReplyList] ) /
+                           commandReplyList )
+
+
+   commandReplyList     = commandReplys *(COMMA commandReplys )
+
+   commandReplys        = (serviceChangeReply / auditReply / ammsReply /
+                           notifyReply )
+
+   ;Add Move and Modify have the same request parameters
+   ammRequest           = (AddToken / MoveToken / ModifyToken ) EQUAL
+                          TerminationID [LBRKT ammParameter *(COMMA
+                          ammParameter) RBRKT]
+
+   ;at-most-once
+   ammParameter         = (mediaDescriptor / modemDescriptor /
+                           muxDescriptor / eventsDescriptor /
+                           signalsDescriptor / digitMapDescriptor /
+                           eventBufferDescriptor / auditDescriptor)
+
+   ammsReply            = (AddToken / MoveToken / ModifyToken /
+                           SubtractToken ) EQUAL TerminationID [ LBRKT
+                           terminationAudit RBRKT ]
+
+   subtractRequest      =  SubtractToken EQUAL TerminationID
+                           [ LBRKT auditDescriptor RBRKT]
+
+   auditRequest         =  (AuditValueToken / AuditCapToken ) EQUAL
+                           TerminationID LBRKT auditDescriptor RBRKT
+
+   auditReply           = (AuditValueToken / AuditCapToken )
+                          ( contextTerminationAudit  / auditOther)
+
+   auditOther           = EQUAL TerminationID [LBRKT
+                          terminationAudit RBRKT]
+
+   terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)
+
+   contextTerminationAudit = EQUAL CtxToken ( terminationIDList /
+                          LBRKT errorDescriptor RBRKT )
+
+   auditReturnParameter = (mediaDescriptor / modemDescriptor /
+                           muxDescriptor / eventsDescriptor /
+                           signalsDescriptor / digitMapDescriptor /
+
+
+
+Groves, et al.              Standards Track                   [Page 116]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                      observedEventsDescriptor / eventBufferDescriptor /
+                           statisticsDescriptor / packagesDescriptor /
+                            errorDescriptor / auditItem)
+
+   auditDescriptor      = AuditToken LBRKT [ auditItem
+                          *(COMMA auditItem) ] RBRKT
+
+   notifyRequest        = NotifyToken EQUAL TerminationID
+                          LBRKT ( observedEventsDescriptor
+                                [ COMMA errorDescriptor ] ) RBRKT
+
+   notifyReply          = NotifyToken EQUAL TerminationID
+                          [ LBRKT errorDescriptor RBRKT ]
+
+   serviceChangeRequest = ServiceChangeToken EQUAL TerminationID
+                          LBRKT serviceChangeDescriptor RBRKT
+
+   serviceChangeReply   = ServiceChangeToken EQUAL TerminationID
+                          [LBRKT (errorDescriptor /
+                          serviceChangeReplyDescriptor) RBRKT]
+
+   errorDescriptor   = ErrorToken EQUAL ErrorCode
+                       LBRKT [quotedString] RBRKT
+
+   ErrorCode            = 1*4(DIGIT) ; could be extended
+
+   TransactionID        = UINT32
+
+   mId                  = (( domainAddress / domainName )
+                          [":" portNumber]) / mtpAddress / deviceName
+
+   ; ABNF allows two or more consecutive "." although it is meaningless
+   ; in a domain name.
+   domainName           = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" /
+                          ".") ">"
+   deviceName           = pathNAME
+
+   ;The values 0x0, 0xFFFFFFFE and 0xFFFFFFFF are reserved.
+   ContextID            = (UINT32 / "*" / "-" / "$")
+
+   domainAddress        = "[" (IPv4address / IPv6address) "]"
+   ;RFC2373 contains the definition of IP6Addresses.
+   IPv6address          = hexpart [ ":" IPv4address ]
+   IPv4address          = V4hex DOT V4hex DOT V4hex DOT V4hex
+   V4hex                = 1*3(DIGIT) ; "0".."255"
+   ; this production, while occurring in RFC2373, is not referenced
+   ; IPv6prefix           = hexpart SLASH 1*2DIGIT
+   hexpart           = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
+
+
+
+Groves, et al.              Standards Track                   [Page 117]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   hexseq               = hex4 *( ":" hex4)
+   hex4                 = 1*4HEXDIG
+
+   portNumber           = UINT16
+
+   ; Addressing structure of mtpAddress:
+   ; 25 - 15            0
+   ;    |  PC        | NI |
+   ;    24 - 14 bits    2 bits
+   ; Note: 14 bits are defined for international use.
+   ; Two national options exist where the point code is 16 or 24 bits.
+   ; To octet align the mtpAddress the MSBs shall be encoded as 0s.
+   ; An octet shall be represented by 2 hex digits.
+   mtpAddress           = MTPToken LBRKT 4*8 (HEXDIG) RBRKT
+
+   terminationIDList  = LBRKT TerminationID *(COMMA TerminationID) RBRKT
+
+   ; Total length of pathNAME must not exceed 64 chars.
+   pathNAME      = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
+                          ["@" pathDomainName ]
+
+   ; ABNF allows two or more consecutive "." although it is meaningless
+   ; in a path domain name.
+   pathDomainName       = (ALPHA / DIGIT / "*" )
+                          *63(ALPHA / DIGIT / "-" / "*" / ".")
+
+   TerminationID        = "ROOT" / pathNAME / "$" / "*"
+
+   mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT
+
+   ; at-most one terminationStateDescriptor
+   ; and either streamParm(s) or streamDescriptor(s) but not both
+   mediaParm            = (streamParm / streamDescriptor /
+                           terminationStateDescriptor)
+
+   ; at-most-once per item
+   streamParm           = ( localDescriptor / remoteDescriptor /
+                           localControlDescriptor )
+
+   streamDescriptor     = StreamToken EQUAL StreamID LBRKT streamParm
+                          *(COMMA streamParm) RBRKT
+
+   localControlDescriptor = LocalControlToken LBRKT localParm
+                            *(COMMA localParm) RBRKT
+
+   ; at-most-once per item except for propertyParm
+   localParm = ( streamMode / propertyParm / reservedValueMode
+                  / reservedGroupMode )
+
+
+
+Groves, et al.              Standards Track                   [Page 118]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   reservedValueMode    = ReservedValueToken EQUAL ( "ON" / "OFF" )
+   reservedGroupMode    = ReservedGroupToken EQUAL ( "ON" / "OFF" )
+
+   streamMode           = ModeToken EQUAL streamModes
+
+   streamModes     = (SendonlyToken / RecvonlyToken / SendrecvToken /
+                          InactiveToken / LoopbackToken )
+
+   propertyParm         = pkgdName parmValue
+   parmValue            = (EQUAL alternativeValue/ INEQUAL VALUE)
+   alternativeValue     = ( VALUE
+                  / LSBRKT VALUE *(COMMA VALUE) RSBRKT
+                   ; sublist (i.e., A AND B AND ...)
+                  / LBRKT VALUE *(COMMA VALUE) RBRKT
+                   ; alternatives (i.e., A OR B OR ...)
+                  /  LSBRKT VALUE COLON VALUE RSBRKT )
+                   ; range
+
+   INEQUAL              = LWSP (">" / "<" / "#" ) LWSP
+   LSBRKT               = LWSP "[" LWSP
+   RSBRKT               = LWSP "]" LWSP
+
+   ; Note - The octet zero is not among the permitted characters in
+   ; octet string.  As the current definition is limited to SDP, and a
+   ; zero octet would not be a legal character in SDP, this is not a
+   ; concern.
+
+   localDescriptor      = LocalToken LBRKT octetString RBRKT
+
+   remoteDescriptor     = RemoteToken LBRKT octetString RBRKT
+
+   eventBufferDescriptor= EventBufferToken [ LBRKT eventSpec
+                          *( COMMA eventSpec) RBRKT ]
+
+   eventSpec      = pkgdName [ LBRKT eventSpecParameter
+                *(COMMA eventSpecParameter) RBRKT ]
+   eventSpecParameter   = (eventStream / eventOther)
+
+   eventBufferControl     = BufferToken EQUAL ( "OFF" / LockStepToken )
+
+   terminationStateDescriptor = TerminationStateToken LBRKT
+              terminationStateParm *( COMMA terminationStateParm ) RBRKT
+
+   ; at-most-once per item except for propertyParm
+   terminationStateParm = (propertyParm / serviceStates /
+                           eventBufferControl )
+
+
+
+
+Groves, et al.              Standards Track                   [Page 119]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   serviceStates        = ServiceStatesToken EQUAL ( TestToken /
+                          OutOfSvcToken / InSvcToken )
+
+   muxDescriptor        = MuxToken EQUAL MuxType  terminationIDList
+
+   MuxType              = ( H221Token / H223Token / H226Token / V76Token
+                           / extensionParameter )
+
+   StreamID             = UINT16
+   pkgdName     = (PackageName SLASH ItemID) ;specific item
+                / (PackageName SLASH "*") ;all items in package
+                / ("*" SLASH "*") ; all items supported by the MG
+   PackageName          = NAME
+   ItemID               = NAME
+
+   eventsDescriptor     = EventsToken [ EQUAL RequestID LBRKT
+                        requestedEvent *( COMMA requestedEvent ) RBRKT ]
+
+   requestedEvent       = pkgdName [ LBRKT eventParameter
+                          *( COMMA eventParameter ) RBRKT ]
+
+   ; at-most-once each of KeepActiveToken , eventDM and eventStream
+   ;at most one of either embedWithSig or embedNoSig but not both
+   ;KeepActiveToken and embedWithSig must not both be present
+   eventParameter       = ( embedWithSig / embedNoSig / KeepActiveToken
+                            /eventDM / eventStream / eventOther )
+
+   embedWithSig         = EmbedToken LBRKT signalsDescriptor
+                            [COMMA embedFirst ] RBRKT
+   embedNoSig        = EmbedToken LBRKT embedFirst RBRKT
+
+   ; at-most-once of each
+   embedFirst      = EventsToken [ EQUAL RequestID LBRKT
+              secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT ]
+
+   secondRequestedEvent = pkgdName [ LBRKT secondEventParameter
+                          *( COMMA secondEventParameter ) RBRKT ]
+
+   ; at-most-once each of embedSig , KeepActiveToken, eventDM or
+   ; eventStream
+   ; KeepActiveToken and embedSig must not both be present
+   secondEventParameter = ( embedSig / KeepActiveToken / eventDM /
+                            eventStream / eventOther )
+
+   embedSig  = EmbedToken LBRKT signalsDescriptor RBRKT
+
+   eventStream          = StreamToken EQUAL StreamID
+
+
+
+
+Groves, et al.              Standards Track                   [Page 120]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   eventOther           = eventParameterName parmValue
+
+   eventParameterName   = NAME
+
+   eventDM              = DigitMapToken EQUAL(( digitMapName ) /
+                          (LBRKT digitMapValue RBRKT ))
+
+   signalsDescriptor    = SignalsToken LBRKT [ signalParm
+                          *(COMMA signalParm)] RBRKT
+
+   signalParm           = signalList / signalRequest
+
+   signalRequest        = signalName [ LBRKT sigParameter
+                          *(COMMA sigParameter) RBRKT ]
+
+   signalList           = SignalListToken EQUAL signalListId LBRKT
+                          signalListParm *(COMMA signalListParm) RBRKT
+
+   signalListId         = UINT16
+
+   ;exactly once signalType, at most once duration and every signal
+   ;parameter
+   signalListParm       = signalRequest
+
+   signalName           = pkgdName
+   ;at-most-once sigStream, at-most-once sigSignalType,
+   ;at-most-once sigDuration, every signalParameterName at most once
+   sigParameter = sigStream / sigSignalType / sigDuration / sigOther
+               / notifyCompletion / KeepActiveToken
+   sigStream            = StreamToken EQUAL StreamID
+   sigOther             = sigParameterName parmValue
+   sigParameterName     = NAME
+   sigSignalType        = SignalTypeToken EQUAL signalType
+   signalType           = (OnOffToken / TimeOutToken / BriefToken)
+   sigDuration          = DurationToken EQUAL UINT16
+   notifyCompletion     = NotifyCompletionToken EQUAL (LBRKT
+            notificationReason *(COMMA notificationReason) RBRKT)
+
+   notificationReason   = ( TimeOutToken / InterruptByEventToken
+                        / InterruptByNewSignalsDescrToken
+                        / OtherReasonToken )
+   observedEventsDescriptor = ObservedEventsToken EQUAL RequestID
+                      LBRKT observedEvent *(COMMA observedEvent) RBRKT
+
+   ;time per event, because it might be buffered
+   observedEvent        = [ TimeStamp LWSP COLON] LWSP
+                          pkgdName [ LBRKT observedEventParameter
+                          *(COMMA observedEventParameter) RBRKT ]
+
+
+
+Groves, et al.              Standards Track                   [Page 121]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   ;at-most-once eventStream, every eventParameterName at most once
+   observedEventParameter = eventStream / eventOther
+
+   ; For an AuditCapReply with all events, the RequestID should be ALL.
+   RequestID            = ( UINT32 / "*" )
+
+   modemDescriptor      = ModemToken (( EQUAL modemType) /
+                      (LSBRKT modemType *(COMMA modemType) RSBRKT))
+                     [ LBRKT propertyParm *(COMMA propertyParm) RBRKT ]
+
+
+   ; at-most-once except for extensionParameter
+   modemType            = (V32bisToken / V22bisToken / V18Token /
+                           V22Token / V32Token / V34Token / V90Token /
+                         V91Token / SynchISDNToken / extensionParameter)
+
+   digitMapDescriptor  = DigitMapToken EQUAL
+                        ( ( LBRKT digitMapValue RBRKT ) /
+                        (digitMapName [ LBRKT digitMapValue RBRKT ]) )
+   digitMapName        = NAME
+   digitMapValue       = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA]
+                         ["L" COLON Timer COMMA] digitMap
+   Timer               = 1*2DIGIT
+   ; Units are seconds for T, S, and L timers, and hundreds of
+   ; milliseconds for Z timer.  Thus T, S, and L range from 1 to 99
+   ; seconds and Z from 100 ms to 9.9 s
+   digitMap = (digitString /
+               LWSP "(" LWSP digitStringList LWSP ")" LWSP)
+   digitStringList   = digitString *( LWSP "|" LWSP digitString )
+   digitString       = 1*(digitStringElement)
+   digitStringElement = digitPosition [DOT]
+   digitPosition     = digitMapLetter / digitMapRange
+   digitMapRange     = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
+   digitLetter       = *((DIGIT "-" DIGIT ) / digitMapLetter)
+   digitMapLetter    = DIGIT   ;Basic event symbols
+               / %x41-4B / %x61-6B ; a-k, A-K
+               / "L" / "S"   ;Inter-event timers (long, short)
+               / "Z"         ;Long duration modifier
+
+   ;at-most-once, and DigitMapToken and PackagesToken are not allowed
+   ;in AuditCapabilities command
+   auditItem            = ( MuxToken / ModemToken / MediaToken /
+                           SignalsToken / EventBufferToken /
+                           DigitMapToken / StatsToken / EventsToken /
+                           ObservedEventsToken / PackagesToken )
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 122]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
+                            *(COMMA serviceChangeParm) RBRKT
+
+   ; each parameter at-most-once
+   ; at most one of either serviceChangeAddress or serviceChangeMgcId
+   ; but not both
+   ; serviceChangeMethod and serviceChangeReason are REQUIRED
+   serviceChangeParm    = (serviceChangeMethod / serviceChangeReason /
+                          serviceChangeDelay / serviceChangeAddress /
+                          serviceChangeProfile / extension / TimeStamp /
+                          serviceChangeMgcId / serviceChangeVersion )
+
+   serviceChangeReplyDescriptor = ServicesToken LBRKT
+                        servChgReplyParm *(COMMA servChgReplyParm) RBRKT
+
+   ; at-most-once.  Version is REQUIRED on first ServiceChange response
+   ; at most one of either serviceChangeAddress or serviceChangeMgcId
+   ; but not both
+   servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
+                          serviceChangeProfile / serviceChangeVersion /
+                          TimeStamp)
+   serviceChangeMethod  = MethodToken EQUAL (FailoverToken /
+                          ForcedToken / GracefulToken / RestartToken /
+                          DisconnectedToken / HandOffToken /
+                          extensionParameter)
+   ; A serviceChangeReason consists of a numeric reason code
+   ; and an optional text description.
+   ; A serviceChangeReason MUST be encoded using the quotedString
+   ; form of VALUE.
+   ; The quotedString SHALL contain a decimal reason code,
+   ; optionally followed by a single space character and a
+   ; textual description string.
+
+
+   serviceChangeReason  = ReasonToken  EQUAL VALUE
+   serviceChangeDelay   = DelayToken   EQUAL UINT32
+   serviceChangeAddress = ServiceChangeAddressToken EQUAL ( mId /
+                          portNumber )
+   serviceChangeMgcId   = MgcIdToken   EQUAL mId
+   serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
+   serviceChangeVersion = VersionToken EQUAL Version
+   extension            = extensionParameter parmValue
+
+   packagesDescriptor   = PackagesToken LBRKT packagesItem
+                          *(COMMA packagesItem) RBRKT
+
+   Version              = 1*2(DIGIT)
+   packagesItem         = NAME "-" UINT16
+
+
+
+Groves, et al.              Standards Track                   [Page 123]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   TimeStamp            = Date "T" Time ; per ISO 8601:1988
+   ; Date = yyyymmdd
+   Date                 = 8(DIGIT)
+   ; Time = hhmmssss
+   Time                 = 8(DIGIT)
+   statisticsDescriptor = StatsToken LBRKT statisticsParameter
+                         *(COMMA statisticsParameter ) RBRKT
+
+   ;at-most-once per item
+   statisticsParameter  = pkgdName [EQUAL VALUE]
+
+   topologyDescriptor   = TopologyToken LBRKT topologyTriple
+                          *(COMMA topologyTriple) RBRKT
+   topologyTriple       = terminationA COMMA
+                          terminationB COMMA topologyDirection
+   terminationA         = TerminationID
+   terminationB         = TerminationID
+   topologyDirection    = BothwayToken / IsolateToken / OnewayToken
+
+   priority             = PriorityToken EQUAL UINT16
+
+   extensionParameter   = "X"  ("-" / "+") 1*6(ALPHA / DIGIT)
+
+   ; octetString is used to describe SDP defined in RFC2327.
+   ; Caution should be taken if CRLF in RFC2327 is used.
+   ; To be safe, use EOL in this ABNF.
+   ; Whenever "}" appears in SDP, it is escaped by "\", e.g., "\}"
+   octetString          = *(nonEscapeChar)
+   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )
+   ; Note - The double-quote character is not allowed in quotedString.
+   quotedString         = DQUOTE *(SafeChar / RestChar/ WSP) DQUOTE
+
+   UINT16               = 1*5(DIGIT)  ; %x0-FFFF
+   UINT32               = 1*10(DIGIT) ; %x0-FFFFFFFF
+
+   NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )
+   VALUE                = quotedString / 1*(SafeChar)
+   SafeChar             = DIGIT / ALPHA / "+" / "-" / "&" /
+                          "!" / "_" / "/" / "\'" / "?" / "@" /
+                          "^" / "`" / "~" / "*" / "$" / "\" /
+                          "(" / ")" / "%" / "|" / "."
+
+   EQUAL                = LWSP %x3D LWSP ; "="
+   COLON                = %x3A           ; ":"
+   LBRKT                = LWSP %x7B LWSP ; "{"
+   RBRKT                = LWSP %x7D LWSP ; "}"
+   COMMA                = LWSP %x2C LWSP ; ","
+
+
+
+Groves, et al.              Standards Track                   [Page 124]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   DOT                  = %x2E           ; "."
+   SLASH                = %x2F           ; "/"
+   ALPHA                = %x41-5A / %x61-7A ; A-Z / a-z
+   DIGIT                = %x30-39         ; 0-9
+   DQUOTE               = %x22            ; " (Double Quote)
+   HEXDIG               = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )
+   SP                   = %x20        ; space
+   HTAB                 = %x09        ; horizontal tab
+   CR                   = %x0D        ; Carriage return
+   LF                   = %x0A        ; linefeed
+   LWSP                 = *( WSP / COMMENT / EOL )
+   EOL                  = (CR [LF] / LF )
+   WSP                  = SP / HTAB ; white space
+   SEP                  = ( WSP / EOL / COMMENT) LWSP
+   COMMENT              = ";" *(SafeChar/ RestChar / WSP / %x22) EOL
+   RestChar            = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
+                          "<" / ">" / "="
+
+   ; New Tokens added to sigParameter must take the format of SPA*
+   ; * may be of any form i.e., SPAM
+   ; New Tokens added to eventParameter must take the form of EPA*
+   ; * may be of any form i.e., EPAD
+
+   AddToken                   = ("Add"                   / "A")
+   AuditToken                 = ("Audit"                 / "AT")
+   AuditCapToken              = ("AuditCapability"       / "AC")
+   AuditValueToken            = ("AuditValue"            / "AV")
+   AuthToken                  = ("Authentication"        / "AU")
+   BothwayToken               = ("Bothway"               / "BW")
+   BriefToken                 = ("Brief"                 / "BR")
+   BufferToken                = ("Buffer"                / "BF")
+   CtxToken                   = ("Context"               / "C")
+   ContextAuditToken       = ("ContextAudit"    / "CA")
+   DigitMapToken              = ("DigitMap"              / "DM")
+   DisconnectedToken          = ("Disconnected"          / "DC")
+   DelayToken                 = ("Delay"                 / "DL")
+   DurationToken              = ("Duration"              / "DR")
+   EmbedToken                 = ("Embed"                 / "EM")
+   EmergencyToken             = ("Emergency"             / "EG")
+   ErrorToken                 = ("Error"                 / "ER")
+   EventBufferToken           = ("EventBuffer"           / "EB")
+   EventsToken                = ("Events"                / "E")
+   FailoverToken              = ("Failover"              / "FL")
+   ForcedToken                = ("Forced"                / "FO")
+   GracefulToken              = ("Graceful"              / "GR")
+   H221Token                  = ("H221" )
+   H223Token                  = ("H223" )
+   H226Token                  = ("H226" )
+
+
+
+Groves, et al.              Standards Track                   [Page 125]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   HandOffToken               = ("HandOff"               / "HO")
+   ImmAckRequiredToken        = ("ImmAckRequired"        / "IA")
+   InactiveToken              = ("Inactive"              / "IN")
+   IsolateToken               = ("Isolate"               / "IS")
+   InSvcToken                 = ("InService"             / "IV")
+   InterruptByEventToken      = ("IntByEvent"            / "IBE")
+   InterruptByNewSignalsDescrToken
+                              = ("IntBySigDescr"         / "IBS")
+   KeepActiveToken            = ("KeepActive"            / "KA")
+   LocalToken                 = ("Local"                 / "L")
+   LocalControlToken          = ("LocalControl"          / "O")
+   LockStepToken              = ("LockStep"              / "SP")
+   LoopbackToken              = ("Loopback"              / "LB")
+   MediaToken                 = ("Media"                 / "M")
+   MegacopToken               = ("MEGACO"                / "!")
+   MethodToken                = ("Method"                / "MT")
+   MgcIdToken                 = ("MgcIdToTry"            / "MG")
+   ModeToken                  = ("Mode"                  / "MO")
+   ModifyToken                = ("Modify"                / "MF")
+   ModemToken                 = ("Modem"                 / "MD")
+   MoveToken                  = ("Move"                  / "MV")
+   MTPToken                   = ("MTP")
+   MuxToken                   = ("Mux"                   / "MX")
+   NotifyToken                = ("Notify"                / "N")
+   NotifyCompletionToken      = ("NotifyCompletion"      / "NC")
+   ObservedEventsToken        = ("ObservedEvents"        / "OE")
+   OnewayToken                = ("Oneway"                / "OW")
+   OnOffToken                 = ("OnOff"                 / "OO")
+   OtherReasonToken           = ("OtherReason"           / "OR")
+   OutOfSvcToken              = ("OutOfService"          / "OS")
+   PackagesToken              = ("Packages"              / "PG")
+   PendingToken               = ("Pending"               / "PN")
+   PriorityToken              = ("Priority"              / "PR")
+   ProfileToken               = ("Profile"               / "PF")
+   ReasonToken                = ("Reason"                / "RE")
+   RecvonlyToken              = ("ReceiveOnly"           / "RC")
+   ReplyToken                 = ("Reply"                 / "P")
+   RestartToken               = ("Restart"               / "RS")
+   RemoteToken                = ("Remote"                / "R")
+   ReservedGroupToken         = ("ReservedGroup"         / "RG")
+   ReservedValueToken         = ("ReservedValue"         / "RV")
+   SendonlyToken              = ("SendOnly"              / "SO")
+   SendrecvToken              = ("SendReceive"           / "SR")
+   ServicesToken              = ("Services"              / "SV")
+   ServiceStatesToken         = ("ServiceStates"         / "SI")
+   ServiceChangeToken         = ("ServiceChange"         / "SC")
+   ServiceChangeAddressToken  = ("ServiceChangeAddress"  / "AD")
+   SignalListToken            = ("SignalList"            / "SL")
+
+
+
+Groves, et al.              Standards Track                   [Page 126]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   SignalsToken               = ("Signals"               / "SG")
+   SignalTypeToken            = ("SignalType"            / "SY")
+   StatsToken                 = ("Statistics"            / "SA")
+   StreamToken                = ("Stream"                / "ST")
+   SubtractToken              = ("Subtract"              / "S")
+   SynchISDNToken             = ("SynchISDN"             / "SN")
+   TerminationStateToken      = ("TerminationState"      / "TS")
+   TestToken                  = ("Test"                  / "TE")
+   TimeOutToken               = ("TimeOut"               / "TO")
+   TopologyToken              = ("Topology"              / "TP")
+   TransToken                 = ("Transaction"           / "T")
+   ResponseAckToken           = ("TransactionResponseAck" / "K")
+   V18Token                   = ("V18")
+   V22Token                   = ("V22")
+   V22bisToken                = ("V22b")
+   V32Token                   = ("V32")
+   V32bisToken                = ("V32b")
+   V34Token                   = ("V34")
+   V76Token                   = ("V76")
+   V90Token                   = ("V90")
+   V91Token                   = ("V91")
+   VersionToken               = ("Version"               / "V")
+
+B.3   Hexadecimal octet coding
+
+   Hexadecimal octet coding is a means for representing a string of
+   octets as a string of hexadecimal digits, with two digits
+   representing each octet.  This octet encoding should be used when
+   encoding octet strings in the text version of the protocol.  For each
+   octet, the 8-bit sequence is encoded as two hexadecimal digits.  Bit
+   0 is the first transmitted; bit 7 is the last.  Bits 7-4 are encoded
+   as the first hexadecimal digit, with Bit 7 as MSB and Bit 4 as LSB.
+   Bits 3-0 are encoded as the second hexadecimal digit, with Bit 3 as
+   MSB and Bit 0 as LSB. Examples:
+
+        Octet bit pattern                   Hexadecimal coding
+        00011011                            D8
+        11100100                            27
+        10000011 10100010 11001000 00001001 C1451390
+
+B.4   Hexadecimal octet sequence
+
+   A hexadecimal octet sequence is an even number of hexadecimal digits,
+   terminated by a <CR> character.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 127]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+ANNEX C - Tags for media stream properties
+
+   Parameters for Local, Remote and LocalControl descriptors are
+   specified as tag-value pairs if binary encoding is used for the
+   protocol.  This annex contains the property names (PropertyID), the
+   tags (Property tag), type of the property (Type) and the values
+   (Value).  Values presented in the Value field when the field contains
+   references shall be regarded as "information".  The reference
+   contains the normative values.  If a value field does not contain a
+   reference, then the values in that field can be considered as
+   "normative".
+
+   Tags are given as hexadecimal numbers in this annex.  When setting
+   the value of a property, a MGC may underspecify the value according
+   to one of the mechanisms specified in 7.1.1.
+
+   It is optional to support the properties in this Annex or any of its
+   sub-sections.  For example, only three properties from C.3 and only
+   five properties from C.8 might be implemented.
+
+   For type "enumeration" the value is represented by the value in
+   brackets, e.g., Send(0), Receive(1).  Annex C properties with the
+   types "N bits" or "M Octets" should be treated as octet strings when
+   encoding the protocol.  Properties with "N bit integer" shall be
+   treated as an integers.  "String" shall be treated as an IA5String
+   when encoding the protocol.
+
+   When a type is smaller than one octet, the value shall be stored in
+   the low-order bits of an octet string of size 1.
+
+C.1   General media attributes
+
+   PropertyID    Property Type          Value
+                 tag
+
+   Media         1001     Enumeration   Audio(0), Video(1), Data(2)
+
+   Transmission  1002     Enumeration   Send(0), Receive(1),
+   mode                                 Send&Receive(2)
+
+   Number of     1003     Unsigned      0-255
+   Channels               integer
+
+   Sampling      1004     Unsigned      0-2^32
+   rate                   integer
+
+   Bitrate       1005     Integer       (0..4294967295)NOTE - Units of
+                                        100 bit/s.
+
+
+
+Groves, et al.              Standards Track                   [Page 128]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   ACodec        1006     Octet string  Audio Codec Type:
+                                        Ref.: ITU-T Q.765
+                                        Non-ITU-T codecs are defined
+                                        with the appropriate standards
+                                        organization under a defined
+                                        Organizational Identifier.
+
+   Samplepp      1007     Unsigned      Maximum samples or frames per
+                          integer       packet: 0..65535
+
+   Silencesupp   1008     Boolean       Silence Suppression: True/False
+
+   Encrypttype   1009     Octet string  Ref.: ITU-T H.245
+
+   Encryptkey    100A     Octet string  Encryption key
+                          size          Ref.: ITU-T H.235
+                          (0..65535)
+
+   Echocanc      100B                    Not Used.  See H.248.1 E.13 for
+                                        an example of possible Echo
+                                        Control properties.
+
+   Gain          100C     Unsigned      Gain in dB: 0..65535
+                          integer
+
+   Jitterbuff    100D     Unsigned      Jitter buffer size in ms:
+                          integer       0..65535
+
+   PropDelay     100E     Unsigned      Propagation Delay: 0..65535
+                          integer       Maximum propagation delay in
+                                        milliseconds for the bearer
+                                        connection between two media
+                                        gateways.  The maximum delay
+                                        will be dependent on the bearer
+                                        technology.
+
+   RTPpayload    100F     Integer       Payload type in RTP Profile for
+                                        Audio and Video Conferences
+                                        with Minimal Control
+                                        Ref.: RFC 1890
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 129]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+C.2   Mux properties
+
+   PropertyID Property tag Type         Value
+
+   H222       2001         Octet string H222LogicalChannelParameters
+                                         Ref.: ITU-T H.245
+
+   H223       2002         Octet string H223LogicalChannelParameters
+                                         Ref.: ITU-T H.245
+
+   V76        2003         Octet string V76LogicalChannelParameters
+                                         Ref.: ITU-T H.245
+
+   H2250      2004         Octet string H2250LogicalChannelParameters
+                                         Ref.: ITU-T H.245
+
+C.3   General bearer properties
+
+   PropertyID Property   Type        Value
+              tag
+
+   Mediatx    3001       Enumeration Media Transport TypeTDM
+                                      Circuit(0), ATM(1), FR(2),
+                                      Ipv4(3), Ipv6(4), ...
+
+   BIR        3002       4 octets    Value depends on transport
+                                      technology
+
+   NSAP       3003       1-20 octets See NSAP.
+                                      Ref.: Annex A/X.213
+
+C.4   General ATM properties
+
+   PropertyID Property Type              Value
+              tag
+
+   AESA       4001     20 octets         ATM End System Address
+
+   VPVC       4002     4 octets: VPCI    VPCI/VCI
+                        in first two
+                        least             Ref.: ITU-T Q.2931
+                        significant
+                        octets, VCI in
+                        second two
+                        octets
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 130]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   SC         4003     Enumeration       Service Category: CBR(0),
+                                          nrt-VBR1(1), nrt  VBR2(2),
+                                          nrt-VBR3(3), rt-VBR1(4),
+                                          rt  VBR2(5), rt-VBR3(6),
+                                          UBR1(7), UBR2(8), ABR(9).
+                                          Ref.: ATM Forum UNI 4.0
+
+   BCOB       4004     5-bit integer     Broadband Bearer Class
+                                          Ref.: ITU-T Q.2961.2
+
+   BBTC       4005     7-bit integer     Broadband Transfer Capability
+                                          Ref.: ITU-T Q.2961.1
+
+   ATC        4006     Enumeration       I.371 ATM Traffic
+                                          CapabilityDBR(0), SBR1(1),
+                                          SBR2(2), SBR3(3), ABT/IT(4),
+                                          ABT/DT(5), ABR(6)
+                                          Ref.: ITU-T I.371
+
+   STC        4007     2 bits            Susceptibility to clipping:
+                                          Bits
+                                          2 1
+                                          ---
+                                          0 0     not susceptible to
+                                                  clipping
+                                          0 1     susceptible to
+                                                  clipping
+                                          Ref.: ITU-T Q.2931
+
+   UPCC       4008     2 bits            User Plane Connection
+                                          configuration:
+                                          Bits
+                                          2 1
+                                          ---
+                                          0 0     point-to-point
+                                          0 1     point-to-multipoint
+                                          Ref.: ITU-T Q.2931
+
+   PCR0       4009     24-bit integer    Peak Cell Rate (For CLP = 0)
+                                          Ref.: ITU-T Q.2931
+
+   SCR0       400A     24-bit integer    Sustainable Cell Rate (For
+                                          CLP = 0)
+                                          Ref.: ITU-T Q.2961.1
+
+   MBS0       400B     24-bit integer    Maximum Burst Size (For CLP =
+                                          0)
+                                          Ref.: ITU-T Q.2961.1
+
+
+
+Groves, et al.              Standards Track                   [Page 131]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   PCR1       400C     24-bit integer    Peak Cell Rate (For CLP = 0 +
+                                          1)
+                                          Ref.: ITU-T Q.2931
+
+   SCR1       400D     24-bit integer    Sustainable Cell Rate (For
+                                          CLP = 0 + 1)
+                                          Ref.: ITU-T Q.2961.1
+
+   MBS1       400E     24-bit integer    Maximum Burst Size (For CLP =
+                                          0 + 1)
+                                          Ref.: ITU-T Q.2961.1
+
+   BEI        400F     Boolean           Best Effort Indicator
+                                          Value 1 indicates that BEI is
+                                          to be included in the ATM
+                                          signaling; value 0 indicates
+                                          that BEI is not to be
+                                          included in the ATM
+                                          signaling.
+                                          Ref.: ATM Forum UNI 4.0
+
+   TI         4010     Boolean           Tagging Indicator
+                                          Value 0 indicates that
+                                          tagging is not allowed; value
+                                          1 indicates that tagging is
+                                          requested.
+                                          Ref.: ITU-T Q.2961.1
+
+   FD         4011     Boolean           Frame Discard
+                                          Value 0 indicates that no
+                                          frame discard is allowed;
+                                          value 1 indicates that frame
+                                          discard is allowed.
+                                          Ref.: ATM Forum UNI 4.0
+
+   A2PCDV     4012     24-bit integer    Acceptable 2-point CDV
+                                          Ref.: ITU-T Q.2965.2
+
+   C2PCDV     4013     24-bit integer    Cumulative 2-point CDV
+                                          Ref.: ITU-T Q.2965.2
+
+   APPCDV     4014     24-bit integer    Acceptable P-P CDV
+                                          Ref.: ATM Forum UNI 4.0
+
+   CPPCDV     4015     24-bit integer    Cumulative P-P CDV
+                                          Ref.: ATM Forum UNI 4.0
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 132]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   ACLR       4016     8-bit integer     Acceptable Cell Loss Ratio
+                                          Ref.: ITU-T Q.2965.2, ATM
+                                          Forum UNI 4.0
+
+   MEETD      4017     16-bit integer    Maximum End-to-end transit
+                                          delay
+                                          Ref.: ITU-T Q.2965.2, ATM
+                                          Forum UNI 4.0
+
+   CEETD      4018     16-bit integer    Cumulative End-to-end transit
+                                          delay
+                                          Ref.: ITU-T Q.2965.2, ATM
+                                          Forum UNI 4.0
+
+   QosClass   4019     Integer 0-5          QoS Class
+
+                                            QoS Class     Meaning
+
+                                            0             Default QoS
+                                                           associated
+                                                           with the ATC
+                                                           as defined
+                                                           in ITU-T
+                                                           Q.2961.2
+
+                                            1             Stringent
+
+                                            2             Tolerant
+
+                                            3             Bi-level
+
+                                            4             Unbounded
+
+                                            5             Stringent
+                                                           Bi-level
+                                          Ref.: ITU-T Q.2965.1
+
+   AALtype    401A     1 octet           AAL Type
+                                          Bits
+                                          8 7 6 5 4 3 2 1
+                                          ---------------
+                                          0 0 0 0 0 0 0 0   AAL for
+                                                            voice
+                                          0 0 0 0 0 0 0 1   AAL type 1
+                                          0 0 0 0 0 0 1 0   AAL type 2
+                                          0 0 0 0 0 0 1 1   AAL type
+                                                            3/4
+                                          0 0 0 0 0 1 0 1   AAL type 5
+
+
+
+Groves, et al.              Standards Track                   [Page 133]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                          0 0 0 1 0 0 0 0   user-
+                                                            defined AAL
+                                          Ref.: ITU-T Q.2931
+
+C.5   Frame Relay
+
+   PropertyID         Property    Type          Value
+                      tag
+
+   DLCI               5001        Unsigned      Data link connection
+                                  integer       id
+
+   CID                5002        Unsigned      sub-channel id
+                                  integer
+
+   SID/Noiselevel     5003        Unsigned      silence insertion
+                                  integer       descriptor
+
+   Primary Payload    5004        Unsigned      Primary Payload Type
+   type                           integer       Covers FAX and codecs
+
+C.6   IP
+
+   PropertyID Property tag Type                Value
+
+   IPv4       6001         32 bits Ipv4Address Ipv4Address
+                                                Ref.: IETF RFC 791
+
+   IPv6       6002         128 bits            IPv6 Address
+                                                Ref.: IETF RFC 2460
+
+   Port       6003         Unsigned integer    0..65535
+
+   Porttype   6004         Enumerated          TCP(0), UDP(1), SCTP(2)
+
+
+C.7   ATM AAL2
+
+   PropertyID Property Type                   Value
+              tag
+
+   AESA       7001     20 octets              AAL2 service endpoint
+                                                address as defined in
+                                                the referenced
+                                                Recommendation.
+                                                ESEANSEA
+                                                Ref.: ITU-T Q.2630.1
+
+
+
+
+Groves, et al.              Standards Track                   [Page 134]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   BIR        See C.3  4 octets               Served user generated
+                                                reference as defined in
+                                                the referenced
+                                                Recommendation.
+                                                SUGR
+                                                Ref.: ITU-T Q.2630.1
+
+   ALC        7002     12 octets              AAL2 link
+                                                characteristics as
+                                                defined in the
+                                                referenced
+                                                Recommendation.
+                                                Maximum/Average CPS-SDU
+                                                bit rate;
+                                                Maximum/Average CPS-SDU
+                                                size
+                                                Ref.: ITU-T Q.2630.1
+
+   SSCS       7003     I.366.2: Audio (8      Service specific
+                        octets); Multirate (3  convergence sublayer
+                        octets), or I.366.1:   information as defined
+                        SAR-assured (14        in:
+                        octets);SAR-unassured  - ITU-T Q.2630.1,and
+                        (7 octets).            used in:
+                                                - ITU-T I.366.2:
+                                                Audio/Multirate;
+                                                - ITU-T I.366.1: SAR-
+                                                assured/unassured.
+                                                Ref.: ITU-T Q.2630.1,
+                                                I.366.1 and I.366.2
+
+   SUT        7004     1..254 octets          Served user transport
+                                                parameter as defined in
+                                                the referenced
+                                                Recommendation.
+                                                Ref.: ITU-T Q.2630.1
+
+   TCI        7005     Boolean                Test connection
+                                                indicator as defined in
+                                                the referenced
+                                                Recommendation.
+                                                Ref.: ITU-T Q.2630.1
+
+   Timer_CU   7006     32-bit integer         Timer-CU
+                                                Milliseconds to hold
+                                                partially filled cell
+                                                before sending.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 135]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   MaxCPSSDU  7007     8-bit integer          Maximum Common Part
+                                                Sublayer Service Data
+                                                Unit
+                                                Ref.: ITU-T Q.2630.1
+
+   CID        7008     8 bits                 subchannel id: 0-255
+                                                Ref.: ITU-T I.363.2
+C.8   ATM AAL1
+
+   PropertyID Property   Type        Value
+              tag
+
+   BIR        See table  4-29 octets GIT (Generic Identifier
+              in C.3                 Transport)
+                                      Ref.: ITU-T Q.2941.1
+
+   AAL1ST     8001       1 octet     AAL1 Subtype
+                                      Bits
+                                      8 7 6 5 4 3 2 1
+                                      ---------------
+                                      0 0 0 0 0 0 0 0     null
+                                      0 0 0 0 0 0 0 1     voiceband
+                                      signal transport on 64 kbit/s
+                                      0 0 0 0 0 0 1 0     circuit
+                                      transport
+                                      0 0 0 0 0 1 0 0     high-quality
+                                      audio signal transport
+                                      0 0 0 0 0 1 0 1     video signal
+                                      transport
+                                      Ref.: ITU-T Q.2931
+
+   CBRR       8002       1 octet     CBR Rate
+                                      Bits
+                                      8 7 6 5 4 3 2 1
+                                      ---------------
+                                      0 0 0 0 0 0 0 1       64 kbit/s
+                                      0 0 0 0 0 1 0 0     1544 kbit/s
+                                      0 0 0 0 0 1 0 1     6312 kbit/s
+                                      0 0 0 0 0 1 1 0   32 064 kbit/s
+                                      0 0 0 0 0 1 1 1   44 736 kbit/s
+                                      0 0 0 0 1 0 0 0   97 728 kbit/s
+                                      0 0 0 1 0 0 0 0     2048 kbit/s
+                                      0 0 0 1 0 0 0 1     8448 kbit/s
+                                      0 0 0 1 0 0 1 0   34 368 kbit/s
+                                      0 0 0 1 0 0 1 1  139 264 kbit/s
+                                      0 1 0 0 0 0 0 0   n x 64 kbit/s
+                                      0 1 0 0 0 0 0 1    n x 8 kbit/s
+                                      Ref.: ITU-T Q.2931
+
+
+
+Groves, et al.              Standards Track                   [Page 136]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   MULT       See table              Multiplier, or n x 64k/8k/300
+              in C.9                 Ref.: ITU-T Q.2931
+
+   SCRI       8003       1 octet     Source Clock Frequency Recovery
+                                      Method
+                                      Bits
+                                      8 7 6 5 4 3 2 1
+                                      ---------------
+                                      0 0 0 0 0 0 0 0     null
+                                      0 0 0 0 0 0 0 1     SRTS
+                                      0 0 0 0 0 0 1 0     ACM
+                                      Ref.: ITU-T Q.2931
+
+   ECM        8004       1 octet     Error Correction Method
+                                      Bits
+                                      8 7 6 5 4 3 2 1
+                                      ---------------
+                                      0 0 0 0 0 0 0 0     null
+                                      0 0 0 0 0 0 0 1     FEC - Loss
+                                      0 0 0 0 0 0 1 0     FEC - Delay
+                                      Ref.: ITU-T Q.2931
+
+   SDTB       8005       16-bit      Structured Data Transfer
+                         integer     Blocksize
+                                      Block size of SDT CBR service
+                                      Ref.: ITU-T I.363.1
+
+   PFCI       8006       8-bit       Partially filled cells identifier
+                         integer     1-47
+                                      Ref.: ITU-T I.363.1
+
+C.9   Bearer capabilities
+
+   The table entries referencing Recommendation Q.931 refer to the
+   encoding in the bearer capability information element of Q.931, not
+   to the low layer information element.
+
+   PropertyID    Tag    Type      Value
+
+   TMR           9001   1 octet   Transmission Medium
+                                  Requirement (Q.763)
+                                  Bits
+                                  87654321
+                                  --------
+                                  00000000  speech
+                                  00000001  spare
+                                  00000010  64 kbit/s
+                                  unrestricted
+
+
+
+Groves, et al.              Standards Track                   [Page 137]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  00000011  3.1 kHz audio
+                                  00000100  reserved for
+                                  alternate speech (service
+                                  2)/64 kbit/s unrestricted
+                                  (service 1)
+                                  00000101  reserved for
+                                  alternate 64 kbit/s
+                                  unrestricted (service
+                                  1)/speech (service 2)
+                                  00000110  64 kbit/s preferred
+
+                                  The assigned codepoints
+                                  listed below are all for
+                                  unrestricted service.
+                                  00000111  2 x 64 kbit/s
+                                  00001000  384 kbit/s
+                                  00001001  1536 kbit/s
+                                  00001010  1920 kbit/s
+                                  00001011
+                                   through
+                                  00001111  spare
+                                  00010000
+                                   through
+                                  00101010:
+                                     3 x 64 kbit/s through
+                                    29 x 64 kbit/s
+                                  except
+                                  00010011  spare
+                                  00100101  spare
+
+                                  00101011
+                                   through
+                                  11111111  spare
+                                  Ref.: ITU-T Q.763
+
+   TMRSR         9002   1 octet   Transmission Medium
+                                  Requirement Subrate
+                                  0     unspecified
+                                  1      8 kbit/s
+                                  2     16 kbit/s
+                                  3     32 kbit/s
+
+   Contcheck     9003   Boolean   Continuity Check
+                                  0     continuity check not
+                                  required on this circuit
+                                  1     continuity check
+                                  required on this circuit
+                                  Ref.: ITU-T Q.763
+
+
+
+Groves, et al.              Standards Track                   [Page 138]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   ITC           9004   5 bits    Information Transfer
+                                  Capability
+                                  Bits
+                                  5 4 3 2 1
+                                  ---------
+                                  0 0 0 0 0     Speech
+                                  0 1 0 0 0     Unrestricted
+                                  digital information
+                                  0 1 0 0 1     Restricted
+                                  digital information
+                                  1 0 0 0 0     3.1 kHz audio
+                                  1 0 0 0 1     Unrestricted
+                                  digital information with
+                                  tones/announcements
+                                  1 1 0 0 0     Video
+                                  All other values are
+                                  reserved.
+                                  Ref.: ITU-T Q.763
+
+   TransMode     9005   2 bits    Transfer Mode
+                                  Bits
+                                  2 1
+                                  ---
+                                  0 0     Circuit mode
+                                  1 0     Packet mode
+                                  Ref.: ITU-T Q.931
+
+   TransRate     9006   5 bits    Transfer Rate
+                                  Bits
+                                  5 4 3 2 1
+                                  ---------
+                                  0 0 0 0 0     This code shall
+                                  be used for packet mode calls
+                                  1 0 0 0 0      64 kbit/s
+                                  1 0 0 0 1  2 x 64 kbit/s
+                                  1 0 0 1 1     384 kbit/s
+                                  1 0 1 0 1    1536 kbit/s
+                                  1 0 1 1 1    1920 kbit/s
+                                  1 1 0 0 0  Multirate (64
+                                  kbit/s base rate)
+                                  Ref.: ITU-T Q.931
+
+   MULT          9007   7 bits    Rate Multiplier
+                                  Any value from 2 to n
+                                  (maximum number of B-
+                                  channels)
+                                  Ref.: ITU-T Q.931
+
+
+
+Groves, et al.              Standards Track                   [Page 139]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   layer1prot    9008   5 bits    User Information Layer 1
+                                  Protocol
+                                  Bits
+                                  5 4 3 2 1
+                                  ---------
+                                  0 0 0 0 1     ITU-T
+                                  standardized rate adaption
+                                  V.110 and X.30.
+                                  0 0 0 1 0     Recommendation
+                                  G.711 m-law
+                                  0 0 0 1 1     Recommendation
+                                  G.711 A-law
+                                  0 0 1 0 0     Recommendation
+                                  G.721 32 kbit/s ADPCM and
+                                  Recommendation I.460
+                                  0 0 1 0 1     Recommendations
+                                  H.221 and H.242
+                                  0 0 1 1 0     Recommendations
+                                  H.223 and H.245
+                                  0 0 1 1 1     Non-ITU-T
+                                  standardized rate adaption.
+                                  0 1 0 0 0     ITU-T
+                                  standardized rate adaption
+                                  V.120.
+                                  0 1 0 0 1     ITU-T
+                                  standardized rate adaption
+                                  X.31 HDLC flag stuffing
+                                  All other values are
+                                  reserved.
+                                  Ref.: ITU Recommendation
+                                  Q.931
+
+   syncasync     9009   Boolean   Synchronous/Asynchronous
+                                  0     Synchronous data
+                                  1     Asynchronous data
+                                  Ref.: ITU-T Q.931
+
+   negotiation   900A   Boolean   Negotiation
+                                  0     In-band negotiation
+                                  possible
+                                  1     In-band negotiation not
+                                  possible
+                                  Ref.: ITU-T Q.931
+
+   Userrate      900B   5 bits    User Rate
+                                  Bits
+                                  5 4 3 2 1
+
+
+
+Groves, et al.              Standards Track                   [Page 140]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  ---------
+                                  0 0 0 0 0     Rate is
+                                  indicated by E-bits specified
+                                  in Recommendation I.460 or
+                                  may be negotiated in-band
+                                  0 0 0 0 1     0.6 kbit/s
+                                  Recommendations V.6 and X.1
+                                  0 0 0 1 0     1.2 kbit/s
+                                  Recommendation V.6
+                                  0 0 0 1 1     2.4 kbit/s
+                                  Recommendations V.6 and X.1
+                                  0 0 1 0 0     3.6 kbit/s
+                                  Recommendation V.6
+                                  0 0 1 0 1     4.8 kbit/s
+                                  Recommendations V.6 and X.1
+                                  0 0 1 1 0     7.2 kbit/s
+                                  Recommendation V.6
+                                  0 0 1 1 1     8 kbit/s
+                                  Recommendation I.460
+                                  0 1 0 0 0     9.6 kbit/s
+                                  Recommendations V.6 and X.1
+                                  0 1 0 0 1     14.4 kbit/s
+                                  Recommendation V.6
+                                  0 1 0 1 0     16 kbit/s
+                                  Recommendation I.460
+                                  0 1 0 1 1     19.2 kbit/s
+                                  Recommendation V.6
+                                  0 1 1 0 0     32 kbit/s
+                                  Recommendation I.460
+                                  0 1 1 0 1     38.4 kbit/s
+                                  Recommendation V.110
+                                  0 1 1 1 0     48 kbit/s
+                                  Recommendations V.6 and X.1
+                                  0 1 1 1 1     56 kbit/s
+                                  Recommendation V.6
+                                  1 0 0 1 0     57.6 kbit/s
+                                  Recommendation V.14 extended
+                                  1 0 0 1 1     28.8 kbit/s
+                                  Recommendation V.110
+                                  1 0 1 0 0     24 kbit/s
+                                  Recommendation V.110
+                                  1 0 1 0 1     0.1345 kbit/s
+                                  Recommendation X.1
+                                  1 0 1 1 0     0.100 kbit/s
+                                  Recommendation X.1
+                                  1 0 1 1 1     0.075/1.2
+                                  kbit/s Recommendations V.6
+                                  and X.1
+
+
+
+Groves, et al.              Standards Track                   [Page 141]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  1 1 0 0 0     1.2/0.075
+                                  kbit/s Recommendations V.6
+                                  and X.1
+                                  1 1 0 0 1     0.050 kbit/s
+                                  Recommendations V.6 and X.1
+                                  1 1 0 1 0     0.075 kbit/s
+                                  Recommendations V.6 and X.1
+                                  1 1 0 1 1     0.110 kbit/s
+                                  Recommendations V.6 and X.1
+                                  1 1 1 0 0     0.150 kbit/s
+                                  Recommendations V.6 and X.1
+                                  1 1 1 0 1     0.200 kbit/s
+                                  Recommendations V.6 and X.1
+                                  1 1 1 1 0     0.300 kbit/s
+                                  Recommendations V.6 and X.1
+                                  1 1 1 1 1     12 kbit/s
+                                  Recommendation V.6
+                                  All other values are
+                                  reserved.
+                                  Ref.: ITU-T Q.931
+   INTRATE       900C   2 bits    Intermediate Rate
+                                  Bits
+                                  2 1
+                                  ---
+                                  0 0     Not used
+                                  0 1     8 kbit/s
+                                  1 0     16 kbit/s
+                                  1 1     32 kbit/s
+                                  Ref.: ITU-T Q.931
+
+   nictx         900D   Boolean   Network Independent Clock
+                                  (NIC) on transmission
+                                  0     Not required to send
+                                  data with network independent
+                                  clock
+                                  1     Required to send data
+                                  with network independent
+                                  clock
+                                  Ref.: ITU-T Q.931
+
+   nicrx         900E   Boolean   Network independent clock
+                                  (NIC) on reception
+                                  0     Cannot accept data with
+                                  network independent clock
+                                  (i.e., sender does not support
+                                  this optional procedure)
+                                  1     Can accept data with
+                                  network independent clock
+
+
+
+Groves, et al.              Standards Track                   [Page 142]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  (i.e., sender does support
+                                  this optional procedure)
+                                  Ref.: ITU-T Q.931
+
+   flowconttx    900F   Boolean   Flow Control on transmission
+                                  (Tx)
+                                  0     Not required to send
+                                  data with flow control
+                                  mechanism
+                                  1     Required to send data
+                                  with flow control mechanism
+                                  Ref.: ITU-T Q.931
+
+   flowcontrx    9010   Boolean   Flow control on reception
+                                  (Rx)
+                                  0     Cannot accept data with
+                                  flow control mechanism (i.e.,
+                                  sender does not support this
+                                  optional procedure)
+                                  1     Can accept data with
+                                  flow control mechanism (i.e.,
+                                  sender does support this
+                                  optional procedure)
+                                  Ref.: ITU-T Q.931
+
+   rateadapthdr  9011   Boolean   Rate adaption header/no
+                                  header
+                                  0     Rate adaption header
+                                  not included
+                                  1     Rate adaption header
+                                  included
+                                  Ref.: ITU-T Q.931
+
+   multiframe    9012   Boolean   Multiple frame establishment
+                                  support in data link
+                                  0     Multiple frame
+                                  establishment not supported.
+                                  Only UI frames allowed
+                                  1     Multiple frame
+                                  establishment supported
+                                  Ref.: ITU-T Q.931
+
+   OPMODE        9013   Boolean   Mode of operation
+                                  0     Bit transparent mode of
+                                  operation
+                                  1     Protocol sensitive mode
+                                  of operation
+                                  Ref.: ITU-T Q.931
+
+
+
+Groves, et al.              Standards Track                   [Page 143]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   llidnegot     9014   Boolean   Logical link identifier
+                                  negotiation
+                                  0     Default, LLI = 256 only
+                                  1     Full protocol
+                                  negotiation
+                                  Ref.: ITU-T Q.931
+
+   assign        9015   Boolean   Assignor/assignee
+                                  0     Message originator is
+                                  "default assignee"
+                                  1     Message originator is
+                                  "assignor only"
+                                  Ref.: ITU-T Q.931
+
+   inbandneg     9016   Boolean   In-band/out-band negotiation
+                                  0     Negotiation is done
+                                  with USER INFORMATION
+                                  messages on a temporary
+                                  signalling connection
+                                  1     Negotiation is done in-
+                                  band using logical link zero
+                                  Ref.: ITU-T Q.931
+
+   stopbits      9017   2 bits    Number of stop bits
+                                  Bits
+                                  2 1
+                                  ---
+                                  0 0     Not used
+                                  0 1     1 bit
+                                  1 0     1.5 bits
+                                  1 1     2 bits
+                                  Ref.: ITU-T Q.931
+
+   databits      9018   2 bits    Number of data bits excluding
+                                  parity bit if present
+                                  Bits
+                                  2 1
+                                  ---
+                                  0 0     Not used
+                                  0 1     5 bits
+                                  1 0     7 bits
+                                  1 1     8 bits
+                                  Ref.: ITU-T Q.931
+
+   parity        9019   3 bits    Parity information
+                                  Bits
+                                  3 2 1
+
+
+
+Groves, et al.              Standards Track                   [Page 144]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  ------
+                                  0 0 0     Odd
+                                  0 1 0     Even
+                                  0 1 1     None
+                                  1 0 0     Forced to 0
+                                  1 0 1     Forced to 1
+                                  All other values are
+                                  reserved.
+                                  Ref.: ITU-T Q.931
+
+   duplexmode    901A   Boolean   Mode duplex
+                                  0     Half duplex
+                                  1     Full duplex
+                                  Ref.: ITU-T Q.931
+
+   modem         901B   6 bits    Modem Type
+                                  Bits
+                                  6 5 4 3 2 1
+                                  -----------
+                                  0 0 0 0 0 0 through
+                                  0 0 0 1 0 1   National use
+                                  0 1 0 0 0 1   Rec.  V.21
+                                  0 1 0 0 1 0     Rec.  V.22
+                                  0 1 0 0 1 1     Rec.  V.22 bis
+                                  0 1 0 1 0 0     Rec.  V.23
+                                  0 1 0 1 0 1     Rec.  V.26
+                                  0 1 1 0 0 1     Rec.  V.26 bis
+                                  0 1 0 1 1 1     Rec.  V.26 ter
+                                  0 1 1 0 0 0     Rec.  V.27
+                                  0 1 1 0 0 1     Rec.  V.27 bis
+                                  0 1 1 0 1 0     Rec.  V.27 ter
+                                  0 1 1 0 1 1     Rec.  V.29
+                                  0 1 1 1 0 1     Rec.  V.32
+                                  0 1 1 1 1 0     Rec.  V.34
+                                  1 0 0 0 0 0  through
+                                  1 0 1 1 1 1    National use
+                                  1 1 0 0 0 0  through
+                                  1 1 1 1 1 1    User specified
+                                  Ref.: ITU-T Q.931
+
+   layer2prot    901C   5 bits    User information layer 2
+                                  protocol
+                                  Bits
+                                  5 4 3 2 1
+                                  ---------
+                                  0 0 0 1 0    Rec.  Q.921/I.441
+                                  0 0 1 1 0    Rec.  X.25, link
+                                  layer
+
+
+
+Groves, et al.              Standards Track                   [Page 145]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  0 1 1 0 0    LAN logical link
+                                  control (ISO/IEC 8802  2)
+                                  All other values are
+                                  reserved.
+                                  Ref.: ITU-T Q.931
+
+   layer3prot    901D   5 bits    User information layer 3
+                                  protocol
+                                  Bits
+                                  5 4 3 2 1
+                                  ---------
+                                  0 0 0 1 0     ITU-T Q.931
+                                  0 0 1 1 0     ITU-T X.25,
+                                  packet layer
+                                  0 1 0 1 1     ISO/IEC TR 9577
+                                  (Protocol identification in
+                                  the network layer)
+                                  All other values are
+                                  reserved.
+                                  Ref.: ITU-T Q.931
+
+   addlayer3prot 901E   Octet     Additional User Information
+                                  layer 3 protocol
+                                  Bits        Bits
+                                  4 3 2 1     4 3 2 1
+                                  -------     -------
+                                  1 1 0 0     1 1 0 0
+                                  Internet Protocol (RFC 791)
+                                  (ISO/IEC TR 9577)
+                                  1 1 0 0     1 1 1 1
+                                  Point-to-point Protocol (RFC
+                                  1661)
+                                  Ref.: ITU-T Q.931
+
+   DialledN      901F   30        Dialled Number
+                        octets
+
+   DiallingN     9020   30        Dialling Number
+                        octets
+
+   ECHOCI        9021             Not Used.  See H.248.1 E.13
+                                  for an example of possible
+                                  Echo Control properties.
+
+   NCI           9022   1 octet   Nature of Connection
+                                  Indicators
+                                  Bits
+                                  2 1     Satellite Indicator
+
+
+
+Groves, et al.              Standards Track                   [Page 146]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                                  ---
+                                  0 0     no satellite circuit
+                                  in the connection
+                                  0 1     one satellite circuit
+                                  in the connection
+                                  1 0     two satellite
+                                  circuits in the connection
+                                  1 1     spare
+
+                                  Bits
+                                  4 3     Continuity check
+                                  ---     indicator
+                                  0 0     continuity check not
+                                  required
+                                  0 1     continuity check
+                                  required on this circuit
+                                  1 0     continuity check
+                                  performed on a previous
+                                  circuit
+                                  1 1     spare
+
+                                  Bit
+                                  5     Echo control device
+                                  -     indicator
+                                  0     outgoing echo control
+                                  device not included
+                                  1     outgoing echo control
+                                  device included
+
+                                  Bits
+                                  8 7 6     Spare
+                                  Ref.: ITU-T Q.763
+
+   USI           9023   Octet     User Service Information
+                        string    Ref.: ITU-T Q.763 Clause 3.57
+
+C.10  AAL5 properties
+
+   PropertyID Property    Type       Value
+              tag
+
+   FMSDU      A001        32-bit     Forward Maximum CPCS-SDU Size:
+                          integer    Maximum CPCS-SDU size sent in the
+                                     direction from the calling user to
+                                     the called user.
+                                     Ref.: ITU-T Q.2931
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 147]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   BMSDU      A002        32-bit     Backwards Maximum CPCS-SDU Size:
+                          integer    Maximum CPCS-SDU size sent in the
+                                     direction from the called user to
+                                     the calling user.
+                                     Ref.: ITU-T Q.2931
+
+   SSCS       See table   See table  See table in C.7
+              in C.7      in C.7     Additional values:
+                                     VPI/VCI
+
+C.11  SDP equivalents
+
+   PropertyID Property    Type   Value
+              tag
+
+   SDP_V      B001        String Protocol Version
+                                  Ref.: RFC 2327
+
+   SDP_O      B002        String Owner/creator and session ID
+                                  Ref.: RFC 2327
+
+   SDP_S      B003        String Session name
+                                  Ref.: RFC 2327
+
+   SDP_I      B004        String Session identifier
+                                  Ref.: RFC 2327
+
+   SDP_U      B005        String URI of descriptor
+                                  Ref.: RFC 2327
+
+   SDC_E      B006        String email address
+                                  Ref.: RFC 2327
+
+   SDP_P      B007        String phone number
+                                  Ref.: RFC 2327
+
+   SDP_C      B008        String Connection information
+                                  Ref.: RFC 2327
+
+   SDP_B      B009        String Bandwidth Information
+                                  Ref.: RFC 2327
+
+   SDP_Z      B00A        String Time zone adjustment
+                                  Ref.: RFC 2327
+
+   SDP_K      B00B        String Encryption Key
+                                  Ref.: RFC 2327
+
+
+
+
+Groves, et al.              Standards Track                   [Page 148]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   SDP_A      B00C        String Zero or more session attributes
+                                  Ref.: RFC 2327
+
+   SDP_T      B00D        String Active Session Time
+                                  Ref.: RFC 2327
+
+   SDP_R      B00E        String Zero or more repeat times
+                                  Reference: RFC 2327
+
+   SDP_M      B00F        String Media type, port, transport and format
+                                  Ref.: RFC 2327
+
+C.12  H.245
+
+   PropertyID Property   Type     Value
+              tag
+
+   OLC        C001       Octet    The value of H.245
+                                   OpenLogicalChannel structure.
+                         string   Ref.: ITU-T H.245
+
+   OLCack     C002       Octet    The value of H.245
+                         string   OpenLogicalChannelAck structure.
+                                   Ref.: ITU-T H.245
+
+   OLCcnf     C003       Octet    The value of H.245
+                         string   OpenLogicalChannelConfirm structure.
+                                   Ref.: ITU-T H.245
+
+   OLCrej     C004       Octet    The value of H.245
+                         string   OpenLogicalChannelReject structure.
+                                   Ref.: ITU-T H.245
+
+   CLC        C005       Octet    The value of H.245
+                         string   CloseLogicalChannel structure.
+                                   Ref.: ITU-T H.245
+
+   CLCack     C006       Octet    The value of H.245
+                         string   CloseLogicalChannelAck structure.
+                                   Ref.: ITU-T H.245
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 149]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+ANNEX D - Transport over IP
+
+D.1   Transport over IP/UDP using Application Level Framing (ALF)
+
+   Protocol messages defined in this RFC may be transmitted over UDP.
+   When no port is provided by the peer (see 7.2.8), commands should be
+   sent to the default port number: 2944 for text-encoded operation, or
+   2945 for binary-encoded operation.  Responses must be sent to the
+   address and port from which the corresponding commands were sent.
+
+   ALF is a set of techniques that allows an application, as opposed to
+   a stack, to affect how messages are sent to the other side.  A
+   typical ALF technique is to allow an application to change the order
+   of messages sent when there is a queue after it has queued them.
+   There is no formal specification for ALF.  The procedures in Annex
+   D.1 contain a minimum suggested set of ALF behaviours
+
+   Implementors using IP/UDP with ALF should be aware of the
+   restrictions of the MTU on the maximum message size.
+
+D.1.1 Providing At-Most-Once functionality
+
+   Messages, being carried over UDP, may be subject to losses.  In the
+   absence of a timely response, commands are repeated.  Most commands
+   are not idempotent.  The state of the MG would become unpredictable
+   if, for example, Add commands were executed several times.  The
+   transmission procedures shall thus provide an "At-Most-Once"
+   functionality.
+
+   Peer protocol entities are expected to keep in memory a list of the
+   responses that they sent to recent transactions and a list of the
+   transactions that are currently outstanding.  The transaction
+   identifier of each incoming message is compared to the transaction
+   identifiers of the recent responses sent to the same MId.  If a match
+   is found, the entity does not execute the transaction, but simply
+   repeats the response.  If no match is found, the message will be
+   compared to the list of currently outstanding transactions.  If a
+   match is found in that list, indicating a duplicate transaction, the
+   entity does not execute the transaction (see D.1.4 for procedures on
+   sending TransactionPending).
+
+   The procedure uses a long timer value, noted LONG-TIMER in the
+   following.  The timer should be set larger than the maximum duration
+   of a transaction, which should take into account the maximum number
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 150]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   of repetitions, the maximum value of the repetition timer and the
+   maximum propagation delay of a packet in the network.  A suggested
+   value is 30 seconds.
+
+   The copy of the responses may be destroyed either LONG-TIMER seconds
+   after the response is issued, or when the entity receives a
+   confirmation that the response has been received, through the
+   "Response Acknowledgement parameter".  For transactions that are
+   acknowledged through this parameter, the entity shall keep a copy of
+   the transaction-id for LONG-TIMER seconds after the response is
+   issued, in order to detect and ignore duplicate copies of the
+   transaction request that could be produced by the network.
+
+D.1.2 Transaction identifiers and three-way handshake
+
+D.1.2.1  Transaction identifiers
+
+   Transaction identifiers are 32-bit integer numbers.  A Media Gateway
+   Controller may decide to use a specific number space for each of the
+   MGs that they manage, or to use the same number space for all MGs
+   that belong to some arbitrary group.  MGCs may decide to share the
+   load of managing a large MG between several independent processes.
+   These processes will share the same transaction number space.  There
+   are multiple possible implementations of this sharing, such as having
+   a centralized allocation of transaction identifiers, or
+   pre-allocating non-overlapping ranges of identifiers to different
+   processes.  The implementations shall guarantee that unique
+   transaction identifiers are allocated to all transactions that
+   originate from a logical MGC (identical mId).  MGs can simply detect
+   duplicate transactions by looking at the transaction identifier and
+   mId only.
+
+D.1.2.2  Three-way handshake
+
+   The TransactionResponse Acknowledgement parameter can be found in any
+   message.  It carries a set of "confirmed transaction-id ranges".
+   Entities may choose to delete the copies of the responses to
+   transactions whose id is included in "confirmed transaction-id
+   ranges" received in the transaction response messages.  They should
+   silently discard further commands when the transaction-id falls
+   within these ranges.
+
+   The "confirmed transaction-id ranges" values shall not be used if
+   more than LONG-TIMER seconds have elapsed since the MG issued its
+   last response to that MGC, or when a MG resumes operation.  In this
+   situation, transactions should be accepted and processed, without any
+   test on the transaction-id.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 151]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Messages that carry the "Transaction Response Acknowledgement"
+   parameter may be transmitted in any order.  The entity shall retain
+   the "confirmed transaction-id ranges" received for LONG-TIMER
+   seconds.
+
+   In the binary encoding, if only the firstAck is present in a response
+   acknowledgement (see A.2), only one transaction is acknowledged.  If
+   both firstAck and lastAck are present, then the range of transactions
+   from firstAck to lastAck is acknowledged.  In the text encoding, a
+   horizontal dash is used to indicate a range of transactions being
+   acknowledged (see B.2).
+
+D.1.3 Computing retransmission timers
+
+   It is the responsibility of the requesting entity to provide suitable
+   timeouts for all outstanding transactions, and to retry transactions
+   when timeouts have been exceeded.  Furthermore, when repeated
+   transactions fail to be acknowledged, it is the responsibility of the
+   requesting entity to seek redundant services and/or clear existing or
+   pending connections.
+
+   The specification purposely avoids specifying any value for the
+   retransmission timers.  These values are typically network dependent.
+   The retransmission timers should normally estimate the timer value by
+   measuring the time spent between the sending of a command and the
+   return of a response.  Implementations SHALL ensure that the
+   algorithm used to calculate retransmission timing performs an
+   exponentially increasing backoff of the retransmission timeout for
+   each retransmission or repetition after the first one.
+
+     NOTE - One possibility is to use the algorithm implemented in
+     TCP-IP, which uses two variables:
+
+   -  The average acknowledgement delay (AAD), estimated through an
+      exponentially smoothed average of the observed delays.
+
+   -  The average deviation (ADEV), estimated through an exponentially
+      smoothed average of the absolute value of the difference between
+      the observed delay and the current average.  The retransmission
+      timer, in TCP, is set to the sum of the average delay plus N times
+      the average deviation.  The maximum value of the timer should
+      however be bounded for the protocol defined in this
+      RFC, in order to guarantee that no repeated packet
+      would be received by the gateways after LONG-TIMER seconds.  A
+      suggested maximum value is 4 seconds.
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 152]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   After any retransmission, the entity SHOULD do the following:
+
+   -  It should double the estimated value of the average delay, AAD.
+
+   -  It should compute a random value, uniformly distributed between
+      0.5 AAD and AAD.
+
+   -  It should set the retransmission timer to the sum of that random
+      value and N times the average deviation.
+
+   This procedure has two effects.  Because it includes an exponentially
+   increasing component, it will automatically slow down the stream of
+   messages in case of congestion.  Because it includes a random
+   component, it will break the potential synchronization between
+   notifications triggered by the same external event.
+
+D.1.4 Provisional responses
+
+   Executing some transactions may require a long time.  Long execution
+   times may interact with the timer-based retransmission procedure.
+   This may result either in an inordinate number of retransmissions, or
+   in timer values that become too long to be efficient.  Entities that
+   can predict that a transaction will require a long execution time may
+   send a provisional response, "Transaction Pending".  They SHOULD send
+   this response if they receive a repetition of a transaction that is
+   still being executed.
+
+   Entities that receive a Transaction Pending shall switch to a
+   different repetition timer for repeating requests.  The root
+   Termination has a property (ProvisionalResponseTimerValue), which can
+   be set to the requested maximum number of milliseconds between
+   receipt of a command and transmission of the TransactionPending
+   response.  Upon receipt of a final response following receipt of
+   provisional responses, an immediate confirmation shall be sent, and
+   normal repetition timers shall be used thereafter.  An entity that
+   sends a provisional response, SHALL include the immAckRequired field
+   in the ensuing final response, indicating that an immediate
+   confirmation is expected.  Receipt of a Transaction Pending after
+   receipt of a reply shall be ignored.
+
+D.1.5 Repeating Requests, Responses and Acknowledgements
+
+   The protocol is organized as a set of transactions, each of which is
+   composed of a request and a response, commonly referred to as an
+   acknowledgement.  The protocol messages, being carried over UDP, may
+   be subject to losses.  In the absence of a timely response,
+   transactions are repeated.  Entities are expected to keep in memory a
+
+
+
+
+Groves, et al.              Standards Track                   [Page 153]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   list of the responses that they sent to recent transactions, i.e., a
+   list of all the responses they sent over the last LONG-TIMER seconds,
+   and a list of the transactions that are currently being executed.
+
+   The repetition mechanism is used to guard against three types of
+   possible errors:
+
+   -  transmission errors, when for example a packet is lost due to
+      noise on a line or congestion in a queue;
+
+   -  component failure, when for example an interface to a entity
+      becomes unavailable;
+
+   -  entity failure, when for example an entire entity becomes
+      unavailable.
+
+   The entities should be able to derive from the past history an
+   estimate of the packet loss rate due to transmission errors.  In a
+   properly configured system, this loss rate should be kept very low,
+   typically less than 1%.  If a Media Gateway Controller or a Media
+   Gateway has to repeat a message more than a few times, it is very
+   legitimate to assume that something else than a transmission error is
+   occurring.   For example, given a loss rate of 1%, the probability
+   that five consecutive transmission attempts fail is 1 in 100 billion,
+   an event that should occur less than once every 10 days for a Media
+   Gateway Controller that processes 1000 transactions per second.
+   (Indeed, the number of repetition that is considered excessive should
+   be a function of the prevailing packet loss rate.)  We should note
+   that the "suspicion threshold", which we will call "Max1", is
+   normally lower than the "disconnection threshold", which should be
+   set to a larger value.
+
+   A classic retransmission algorithm would simply count the number of
+   successive repetitions, and conclude that the association is broken
+   after retransmitting the packet an excessive number of times
+   (typically between 7 and 11 times.)  In order to account for the
+   possibility of an undetected or in  progress "failover", we modify
+   the classic algorithm so that if the Media Gateway receives a valid
+   ServiceChange message announcing a failover, it will start
+   transmitting outstanding commands to that new MGC.  Responses to
+   commands are still transmitted to the source address of the command.
+
+   In order to automatically adapt to network load, this RFC specifies
+   exponentially increasing timers.  If the initial timer is set to 200
+   milliseconds, the loss of a fifth retransmission will be detected
+   after about 6 seconds.  This is probably an acceptable waiting delay
+   to detect a failover.  The repetitions should continue after that
+   delay not only in order to perhaps overcome a transient connectivity
+
+
+
+Groves, et al.              Standards Track                   [Page 154]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   problem, but also in order to allow some more time for the execution
+   of a failover  (waiting a total delay of 30 seconds is probably
+   acceptable).
+
+   It is, however, important that the maximum delay of retransmissions
+   be bounded.  Prior to any retransmission, it is checked that the time
+   elapsed since the sending of the initial datagram is no greater than
+   T-MAX.  If more than T-MAX time has elapsed, the MG concludes that
+   the MGC has failed, and it begins its recovery process as described
+   in section 11.5.  If the MG retries to connect to the current MGC it
+   shall use a ServiceChange with ServiceChangeMethod set to
+   Disconnected so that the new MGC will be aware that the MG lost one
+   or more transactions.  The value T-MAX is related to the LONG-TIMER
+   value: the LONG-TIMER value is obtained by adding to T  MAX the
+   maximum propagation delay in the network.
+
+D.2   Using TCP
+
+   Protocol messages as defined in this RFC may be transmitted over TCP.
+   When no port is specified by the other side (see 7.2.8), the commands
+   should be sent to the default port.  The defined protocol has
+   messages as the unit of transfer, while TCP is a stream-oriented
+   protocol.  TPKT, according to RFC 1006, SHALL be used to delineate
+   messages within the TCP stream.
+
+   In a transaction-oriented protocol, there are still ways for
+   transaction requests or responses to be lost.  As such, it is
+   recommended that entities using TCP transport implement application
+   level timers for each request and each response, similar to those
+   specified for application level framing over UDP.
+
+D.2.1 Providing the At-Most-Once functionality
+
+   Messages, being carried over TCP, are not subject to transport
+   losses, but loss of a transaction request or its reply may
+   nonetheless be noted in real implementations.  In the absence of a
+   timely response, commands are repeated.  Most commands are not
+   idempotent.  The state of the MG would become unpredictable if, for
+   example, Add commands were executed several times.
+
+   To guard against such losses, it is recommended that entities follow
+   the procedures in D.1.1.
+
+D.2.2 Transaction identifiers and three-way handshake
+
+   For the same reasons, it is possible that transaction replies may be
+   lost even with a reliable delivery protocol such as TCP.  It is
+   recommended that entities follow the procedures in D.1.2.2.
+
+
+
+Groves, et al.              Standards Track                   [Page 155]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+D.2.3 Computing retransmission timers
+
+   With reliable delivery, the incidence of loss of a transaction
+   request or reply is expected to be very low.  Therefore, only simple
+   timer mechanisms are required.  Exponential back-off algorithms
+   should not be necessary, although they could be employed where, as in
+   an MGC, the code to do so is already required, since MGCs must
+   implement ALF/UDP as well as TCP.
+
+D.2.4 Provisional responses
+
+   As with UDP, executing some transactions may require a long time.
+   Entities that can predict that a transaction will require a long
+   execution time may send a provisional response, "Transaction
+   Pending".  They should send this response if they receive a
+   repetition of a transaction that is still being executed.
+
+   Entities that receive a Transaction Pending shall switch to a longer
+   repetition timer for that transaction.
+
+   Entities shall retain Transactions and replies until they are
+   confirmed.  The basic procedure of D.1.4 should be followed, but
+   simple timer values should be sufficient.  There is no need to send
+   an immediate confirmation upon receipt of a final response.
+
+D.2.5 Ordering of commands
+
+   TCP provides ordered delivery of transactions.  No special procedures
+   are required.  It should be noted that ALF/UDP allows sending entity
+   to modify its behaviour under congestion, and in particular, could
+   reorder transactions when congestion is encountered.  TCP could not
+   achieve the same results.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 156]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+ANNEX E - Basic packages
+
+   This annex contains definitions of some packages for use with
+   Recommendation H.248.1.
+
+E.1   Generic
+
+   PackageID: g (0x0001)
+   Version: 1
+   Extends: None
+
+   Description:
+      Generic package for commonly encountered items.
+
+E.1.1 Properties
+
+   None.
+
+E.1.2 Events
+
+   Cause
+
+      EventID: cause (0x0001)
+      Generic error event
+
+      EventsDescriptor parameters:  None
+
+      ObservedEvents Descriptor Parameters:
+
+         General Cause
+         ParameterID: Generalcause (0x0001)
+
+            This parameter groups the failures into six groups, which
+            the MGC may act upon.
+
+            Type: enumeration
+
+            Possible values:
+                     "NR" Normal Release (0x0001)
+                     "UR" Unavailable Resources (0x0002)
+                     "FT" Failure, Temporary (0x0003)
+                     "FP" Failure, Permanent (0x0004)
+                     "IW" Interworking Error (0x0005)
+                     "UN" Unsupported (0x0006)
+
+         Failure Cause
+         ParameterID: Failurecause (0x0002)
+
+
+
+
+Groves, et al.              Standards Track                   [Page 157]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+            Possible values:  OCTET STRING
+
+            Description: The Failure Cause is the value generated by the
+            Released equipment, i.e., a released network connection.
+            The concerned value is defined in the appropriate bearer
+            control protocol.
+
+   Signal Completion
+
+      EventID: sc (0x0002)
+
+      Indicates the termination of a signal for which the
+      notifyCompletion parameter was set to enable reporting of a
+      completion event.  For further procedural description, see 7.1.1,
+      7.1.17 and 7.2.7.
+
+      EventsDescriptor parameters:  None
+
+      ObservedEvents Descriptor parameters:
+
+         Signal Identity
+         ParameterID: SigID (0x0001)
+
+            This parameter identifies the signal which has terminated.
+            For a signal that is contained in a signal list, the signal
+            list identity parameter should also be returned indicating
+            the appropriate list.
+
+            Type: Binary: octet (string), Text: string
+
+            Possible values: a signal which has terminated.  A signal
+            shall be identified using the pkgdName syntax without
+            wildcarding.
+
+         Termination Method
+         ParameterID: Meth (0x0002)
+
+            Indicates the means by which the signal terminated.
+
+            Type: enumeration
+
+            Possible values:
+               "TO" (0x0001) Signal timed out or otherwise completed on
+               its own
+               "EV" (0x0002) Interrupted by event
+               "SD" (0x0003) Halted by new Signals descriptor
+               "NC" (0x0004) Not completed, other cause
+
+
+
+
+Groves, et al.              Standards Track                   [Page 158]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         Signal List ID
+         ParameterID:  SLID (0x0003)
+
+            Indicates to which signal list a signal belongs.  The
+            SignalList ID is only returned in cases where the signal
+            resides in a signal list.
+
+            Type: integer
+
+            Possible values: any integer
+
+E.1.3 Signals
+
+   None.
+
+E.1.4 Statistics
+
+   None.
+
+E.2   Base Root Package
+
+   PackageID: root (0x0002)
+   Version: 1
+   Extends: None
+
+   Description:
+      This package defines Gateway wide properties.
+
+E.2.1 Properties
+
+   MaxNrOfContexts
+   PropertyID: maxNumberOfContexts (0x0001)
+
+      The value of this property gives the maximum number of contexts
+      that can exist at any time.  The NULL context is not included in
+      this number.
+
+      Type: double
+
+      Possible values: 1 and up
+
+      Defined in: TerminationState
+
+      Characteristics: read only
+
+   MaxTerminationsPerContext
+   PropertyID: maxTerminationsPerContext (0x0002)
+
+
+
+
+Groves, et al.              Standards Track                   [Page 159]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      The maximum number of allowed terminations in a context, see 6.1
+
+      Type: integer
+
+      Possible values: any integer
+
+      Defined in: TerminationState
+
+      Characteristics: read only
+
+   normalMGExecutionTime
+   PropertyId: normalMGExecutionTime (0x0003)
+
+      Settable by the MGC to indicate the interval within which the MGC
+      expects a response to any transaction from the MG (exclusive of
+      network delay)
+
+      Type: integer
+
+      Possible values: any integer, represents milliseconds
+
+      Defined in: TerminationState
+
+      Characteristics: read / write
+
+   normalMGCExecutionTime
+   PropertyId: normalMGCExecutionTime (0x0004)
+
+      Settable by the MGC to indicate the interval within which the MG
+      should expects a response to any transaction from the MGC
+      (exclusive of network delay)
+
+      Type: integer
+
+      Possible values: any integer, represents milliseconds
+
+      Defined in: TerminationState
+
+      Characteristics: read / write
+
+   MGProvisionalResponseTimerValue
+   PropertyId: MGProvisionalResponseTimerValue (0x0005)
+
+      Indicates the time within which the MGC should expect a Pending
+      Response from the MG if a Transaction cannot be completed.
+
+      Initially set to normalMGExecutionTime plus network delay, but may
+      be lowered.
+
+
+
+Groves, et al.              Standards Track                   [Page 160]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      Type: Integer
+
+      Possible Values: any integer, represents milliseconds
+
+      Defined in: TerminationState
+
+      Characteristics: read / write
+
+   MGCProvisionalResponseTimerValue
+   PropertyId: MGCProvisionalResponseTimerValue (0x0006)
+
+      Indicates the time within which the MG should expect a Pending
+      Response from the MGC if a Transaction cannot be completed.
+      Initially set to normalMGCExecutionTime plus network delay, but
+      may be lowered.
+
+      Type: Integer
+
+      Possible Values: any integer, represents milliseconds
+
+      Defined in: TerminationState
+
+      Characteristics: read / write
+
+E.2.2 Events
+
+   None.
+
+E.2.3 Signals
+
+   None.
+
+E.2.4 Statistics
+
+   None.
+
+E.2.5 Procedures
+
+   None.
+
+E.3   Tone Generator Package
+
+   PackageID: tonegen (0x0003)
+   Version: 1
+   Extends: None
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 161]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Description:
+
+      This package defines signals to generate audio tones.  This
+      package does not specify parameter values.  It is intended to be
+      extendable.  Generally, tones are defined as an individual signal
+      with a parameter, ind, representing "interdigit" time delay, and a
+      tone id to be used with playtones.  A tone id should be kept
+      consistent with any tone generation for the same tone.  MGs are
+      expected to be provisioned with the characteristics of appropriate
+      tones for the country in which the MG is located.
+
+   Designed to be extended only.
+
+E.3.1 Properties
+
+   None.
+
+E.3.2 Events
+
+   None.
+
+E.3.3 Signals
+
+   Play tone
+   SignalID: pt (0x0001)
+
+      Plays audio tone over an audio channel
+
+      Signal Type: Brief
+
+      Duration: Provisioned
+
+      Additional parameters:
+
+         Tone id list
+         ParameterID: tl (0x0001)
+
+            Type: list of tone ids
+
+            List of tones to be played in sequence.  The list SHALL
+            contain one or more tone ids.
+
+         Inter signal duration
+         ParameterID: ind (0x0002)
+
+            Type: integer
+
+            Timeout between two consecutive tones in milliseconds
+
+
+
+Groves, et al.              Standards Track                   [Page 162]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+   No tone ids are specified in this package.  Packages that extend this
+   package can add possible values for tone id as well as adding
+   individual tone signals.
+
+E.3.4 Statistics
+
+   None.
+
+E.3.5 Procedures
+
+   None.
+
+E.4   Tone Detection Package
+
+   PackageID: tonedet (0x0004)
+   Version: 1
+   Extends: None
+
+   This Package defines events for audio tone detection.  Tones are
+   selected by name (tone id).  MGs are expected to be provisioned with
+   the characteristics of appropriate tones for the country in which the
+   MG is located.
+
+   Designed to be extended only:
+      This package does not specify parameter values.  It is intended to
+      be extendable.
+
+E.4.1 Properties
+
+   None.
+
+E.4.2 Events
+
+   Start tone detected
+   EventID: std, 0x0001
+
+      Detects the start of a tone.  The characteristics of positive tone
+      detection are implementation dependent.
+
+      EventsDescriptor parameters:
+
+         Tone id list
+         ParameterID: tl (0x0001)
+
+            Type: list of tone ids
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 163]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+            Possible values: The only tone id defined in this package is
+            "wild card" which is "*" in text encoding and 0x0000 in
+            binary.  Extensions to this package would add possible
+            values for tone id.  If tl is "wild card", any tone id is
+            detected.
+
+         ObservedEventsDescriptor parameters:
+
+         Tone id
+         ParameterID: tid (0x0003)
+
+            Type: enumeration
+
+            Possible values: "wildcard" as defined above is the only
+            value defined in this package.  Extensions to this package
+            would add additional possible values for tone id.
+
+         End tone detected
+         EventID: etd, 0x0002
+
+         Detects the end of a tone.
+
+         EventDescriptor parameters:
+
+            Tone id list
+            ParameterID: tl (0x0001)
+
+               Type: enumeration or list of enumerated types
+
+               Possible values: No possible values are specified in this
+               package.  Extensions to this package would add possible
+               values for tone id.
+
+         ObservedEventsDescriptor parameters:
+
+            Tone id
+            ParameterID: tid (0x0003)
+
+               Type: enumeration
+
+               Possible values: "wildcard" as defined above is the only
+               value defined in this package.  Extensions to this
+               package would add possible values for tone id.
+
+            Duration
+            ParameterId: dur (0x0002)
+
+               Type: integer, in milliseconds
+
+
+
+Groves, et al.              Standards Track                   [Page 164]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+
+               This parameter contains the duration of the tone from
+               first detection until it stopped.
+
+   Long tone detected
+   EventID: ltd, 0x0003
+
+      Detects that a tone has been playing for at least a certain amount
+      of time.
+
+      EventDescriptor parameters:
+
+         Tone id list
+         ParameterID: tl (0x0001)
+
+            Type: enumeration or list
+
+            Possible values: "wildcard" as defined above is the only
+            value defined in this package.  Extensions to this package
+            would add possible values for tone id.
+
+         Duration
+         ParameterID: dur (0x0002)
+
+            Type: integer, duration to test against
+
+            Possible values: any legal integer, expressed in
+            milliseconds
+
+      ObservedEventsDescriptor parameters:
+
+         Tone id
+         ParameterID: tid (0x0003)
+
+            Type: Enumeration
+
+            Possible values: No possible values are specified in this
+            package.  Extensions to this package would add possible
+            values for tone id.
+
+E.4.3 Signals
+
+   None.
+
+E.4.4 Statistics
+
+   None.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 165]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+E.4.5 Procedures
+
+   None.
+
+E.5   Basic DTMF Generator Package
+
+   PackageID: dg (0x0005)
+   Version: 1
+   Extends: tonegen version 1
+
+   This package defines the basic DTMF tones as signals and extends the
+   allowed values of parameter tl of playtone in tonegen.
+
+E.5.1 Properties
+
+   None.
+
+E.5.2 Events
+
+   None.
+
+E.5.3 Signals
+
+   DTMF character 0
+   SignalID: d0 (0x0010)
+
+      Generate DTMF 0 tone.  The physical characteristic of DTMF 0 is
+      defined in the gateway.
+
+      Signal Type: Brief
+
+      Duration: Provisioned
+
+      Additional parameters:
+
+         None.
+
+   Additional values:
+
+      d0 (0x0010) is defined as a tone id for playtone
+
+   The other DTMF characters are specified in exactly the same way.  A
+   table with all signal names and signal IDs is included.  Note that
+   each DTMF character is defined as both a signal and a tone id, thus
+   extending the basic tone generation package.  Also note that DTMF
+   SignalIds are different from the names used in a digit map.
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 166]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                     Signal name     Signal ID/Tone id
+
+                    DTMF character 0    d0 (0x0010)
+                    DTMF character 1    d1 (0x0011)
+                    DTMF character 2    d2 (0x0012)
+                    DTMF character 3    d3 (0x0013)
+                    DTMF character 4    d4 (0x0014)
+                    DTMF character 5    d5 (0x0015)
+                    DTMF character 6    d6 (0x0016)
+                    DTMF character 7    d7 (0x0017)
+                    DTMF character 8    d8 (0x0018)
+                    DTMF character 9    d9 (0x0019)
+                    DTMF character *    ds (0x0020)
+                    DTMF character #    do (0x0021)
+                    DTMF character A    da (0x001a)
+                    DTMF character B    db (0x001b)
+                    DTMF character C    dc (0x001c)
+                    DTMF character D    dd (0x001d)
+
+E.5.4 Statistics
+
+   None.
+
+E.5.5 Procedures
+
+   None.
+
+E.6   DTMF detection Package
+
+   PackageID: dd (0x0006)
+   Version: 1
+   Extends: tonedet version 1
+
+   This package defines the basic DTMF tones detection.  This Package
+   extends the possible values of tone id in the "start tone detected"
+   "end tone detected" and "long tone detected" events.
+
+   Additional tone id values are all tone ids described in package dg
+   (basic DTMF generator package).
+
+   The following table maps DTMF events to digit map symbols as
+   described in 7.1.14.
+
+                           DTMF Event Symbol
+
+                           d0   "0"
+                           d1   "1"
+                           d2   "2"
+
+
+
+Groves, et al.              Standards Track                   [Page 167]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                           d3   "3"
+                           d4   "4"
+                           d5   "5"
+                           d6   "6"
+                           d7   "7"
+                           d8   "8"
+                           d9   "9"
+                           da   "A" or "a"
+                           db   "B" or "b"
+                           dc   "C" or "c"
+                           dd   "D" or "d"
+                           ds   "E" or "e"
+                           do   "F" or "f"
+
+E.6.1 Properties
+
+   None.
+
+E.6.2 Events
+
+   DTMF digits
+
+      EventIds are defined with the same names as the SignalIds defined
+      in the table found in E.5.3.
+
+   DigitMap Completion Event
+   EventID: ce, 0x0004
+
+      Generated when a digit map completes as described in 7.1.14.
+
+      EventsDescriptor parameters: None.
+
+      ObservedEventsDescriptor parameters:
+
+         DigitString
+         ParameterID: ds (0x0001)
+
+            Type: string of digit map symbols (possibly empty) returned
+            as a quotedString
+
+            Possible values: a sequence of the characters "0" through
+            "9", "A" through "F", and the long duration modifier "Z".
+
+            Description: the portion of the current dial string as
+            described in 7.1.14 which matched part or all of an
+            alternative event sequence specified in the digit map.
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 168]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         Termination Method
+         ParameterID: Meth (0x0003)
+
+            Type: enumeration
+
+            Possible values:
+
+               "UM" (0x0001) Unambiguous match
+
+               "PM" (0x0002) Partial match, completion by timer expiry
+               or unmatched event
+
+               "FM" (0x0003) Full match, completion by timer expiry or
+               unmatched event
+
+            Description: indicates the reason for generation of the
+            event.  See the procedures in 7.1.14.
+
+E.6.3 Signals
+
+   None.
+
+E.6.4 Statistics
+
+   None.
+
+E.6.5 Procedures
+
+   Digit map processing is activated only if an events descriptor is
+   activated that contains a digit map completion event as defined in
+   Section E.6.2 and that digit map completion event contains an eventDM
+   field in the requested actions as defined in Section 7.1.9.  Other
+   parameters such as KeepActive or embedded events of signals
+   descriptors may also be present in the events descriptor and do not
+   affect the activation of digit map processing.
+
+E.7   Call Progress Tones Generator Package
+
+   PackageID: cg, 0x0007
+   Version: 1
+   Extends: tonegen version 1
+
+   This package defines the basic call progress tones as signals and
+   extends the allowed values of the tl parameter of playtone in
+   tonegen.
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 169]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+E.7.1 Properties
+
+   None.
+
+E.7.2 Events
+
+   None.
+
+E.7.3 Signals
+
+   Dial Tone
+   SignalID: dt (0x0030)
+
+      Generate dial tone.  The physical characteristic of dial tone is
+      available in the gateway.
+
+      Signal Type: TimeOut
+
+      Duration: Provisioned
+
+      Additional parameters:
+
+         None.
+
+   Additional values:
+
+      dt (0x0030) is defined as a tone id for playtone
+
+   The other tones of this package are defined in exactly the same way.
+   A table with all signal names and signal IDs is included.  Note that
+   each tone is defined as both a signal and a tone id, thus extending
+   the basic tone generation package.
+
+     Signal Name                 Signal ID/tone id
+
+     Dial Tone                   dt (0x0030)
+     Ringing Tone                rt (0x0031)
+     Busy Tone                   bt (0x0032)
+     Congestion Tone             ct (0x0033)
+     Special Information Tone    sit(0x0034)
+     Warning Tone                wt (0x0035)
+     Payphone Recognition Tone   prt (0x0036)
+     Call Waiting Tone           cw (0x0037)
+     Caller Waiting Tone         cr (0x0038)
+
+E.7.4 Statistics
+
+   None.
+
+
+
+Groves, et al.              Standards Track                   [Page 170]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+E.7.5 Procedures
+
+      NOTE - The required set of tone ids corresponds to those defined
+      in Recommendation E.180/Q.35.  See Recommendation E.180/Q.35 for
+      definition of the meanings of these tones.
+
+
+E.8   Call Progress Tones Detection Package
+
+   PackageID: cd (0x0008)
+   Version: 1
+   Extends: tonedet version 1
+
+   This package defines the basic call progress detection tones.  This
+   package extends the possible values of tone id in the "start tone
+   detected", "end tone detected" and "long tone detected" events.
+
+   Additional values
+
+      toneID values are defined for start tone detected, end tone
+      detected and long tone detected with the same values as those in
+      package cg (call progress tones generation package).
+
+   The required set of tone ids corresponds to Recommendation
+   E.180/Q.35.  See Recommendation E.180/Q.35 for definition of the
+   meanings of these tones.
+
+E.8.1 Properties
+
+   None.
+
+E.8.2 Events
+
+   Events are defined as in the call progress tones generator package
+   (cg) for the tones listed in the table of E.7.3.
+
+E.8.3 Signals
+
+   None.
+
+E.8.4 Statistics
+
+   None.
+
+E.8.5 Procedures
+
+   None.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 171]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+E.9   Analog Line Supervision Package
+
+   PackageID: al, 0x0009
+   Version: 1
+   Extends: None
+
+   This package defines events and signals for an analog line.
+
+   E.9.1 Properties
+
+   None.
+
+E.9.2 Events
+
+   onhook
+   EventID: on (0x0004)
+
+      Detects handset going on hook.  Whenever an events descriptor is
+      activated that requests monitoring for an on-hook event and the
+      line is already on-hook, then the MG shall behave according to the
+      setting of the "strict" parameter.
+
+      EventDescriptor parameters:
+
+         Strict Transition
+         ParameterID: strict (0x0001)
+
+            Type: enumeration
+
+            Possible values: "exact" (0x00), "state" (0x01), "failWrong"
+            (0x02)
+
+              "exact" means that only an actual hook state transition to
+              on-hook is to be recognized;
+
+              "state" means that the event is to be recognized either if
+              the hook state transition is detected or if the hook state
+              is already on-hook;
+
+              "failWrong" means that if the hook state is already
+              on-hook, the command fails and an error is reported.
+
+      ObservedEventsDescriptor parameters:
+
+         Initial State
+         ParameterID: init (0x0002)
+
+            Type: Boolean
+
+
+
+Groves, et al.              Standards Track                   [Page 172]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+            Possible values:
+
+               "True" means that the event was reported because the line
+               was already on-hook when the events descriptor containing
+               this event was activated;
+
+               "False" means that the event represents an actual state
+               transition to on-hook.
+
+   offhook
+   EventID: of (0x0005)
+
+      Detects handset going off hook.  Whenever an events descriptor is
+      activated that requests monitoring for an off-hook event and the
+      line is already off-hook, then the MG shall behave according to
+      the setting of the "strict" parameter.
+
+      EventDescriptor parameters:
+
+         Strict Transition
+         ParameterID: strict (0x0001)
+
+            Type: enumeration
+
+            Possible values: "exact" (0x00), "state" (0x01), "failWrong"
+            (0x02)
+
+               "exact" means that only an actual hook state transition
+               to off-hook is to be recognized;
+
+               "state" means that the event is to be recognized either
+               if the hook state transition is detected or if the hook
+               state is already off-hook;
+
+               "failWrong" means that if the hook state is already off-
+               hook, the command fails and an error is reported.
+
+      ObservedEventsDescriptor parameters
+
+         Initial State
+         ParameterID: init (0x0002)
+
+            Type: Boolean
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 173]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+            Possible values:
+
+               "True" means that the event was reported because the line
+               was already off-hook when the events descriptor
+               containing this event was activated;
+
+               "False" means that the event represents an actual state
+               transition to off-hook.
+
+   flashhook
+   EventID: fl, 0x0006
+
+      Detects handset flash.  A flash occurs when an onhook is followed
+      by an offhook between a minimum and maximum duration.
+
+      EventDescriptor parameters:
+
+         Minimum duration
+         ParameterID: mindur (0x0004)
+
+            Type: integer in milliseconds
+
+            Default value is provisioned.
+
+         Maximum duration
+         ParameterID: maxdur (0x0005)
+
+            Type: integer in milliseconds
+
+            Default value is provisioned.
+
+      ObservedEventsDescriptor parameters:
+
+         None
+
+E.9.3 Signals
+
+   ring
+   SignalID: ri, 0x0002
+
+      Applies ringing on the line
+
+      Signal Type: TimeOut
+
+      Duration: Provisioned
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 174]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      Additional parameters:
+
+         Cadence
+         ParameterID: cad (0x0006)
+
+            Type: list of integers representing durations of alternating
+            on and off segments, constituting a complete ringing cycle
+            starting with an on.  Units in milliseconds
+
+            Default is fixed or provisioned.  Restricted function MGs
+            may ignore cadence values they are incapable of generating.
+
+         Frequency
+         ParameterID: freq (0x0007)
+
+            Type: integer in Hz
+
+            Default is fixed or provisioned.  Restricted function MGs
+            may ignore frequency values they are incapable of
+            generating.
+
+E.9.4 Statistics
+
+   None.
+
+E.9.5 Procedures
+
+   If the MGC sets an EventsDescriptor containing a hook state
+   transition event (on-hook or off-hook) with the "strict" (0x0001)
+   parameter set to "failWrong", and the hook state is already what the
+   transition implies, the execution of the command containing that
+   EventsDescriptor fails.  The MG SHALL include error code 540
+   "Unexpected initial hook state" in its reponse.
+
+E.9.6 Error code
+
+   This package defines a new error code:
+
+      540 - Unexpected initial hook state
+
+   The procedure for use of this code is given in E.9.5.
+
+E.10  Basic Continuity Package
+
+   PackageID: ct (0x000a)
+   Version: 1
+   Extends: None
+
+
+
+
+Groves, et al.              Standards Track                   [Page 175]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   This package defines events and signals for continuity test.  The
+   continuity test includes provision of either a loopback or
+   transceiver functionality.
+
+E.10.1   Properties
+
+   None.
+
+E.10.2   Events
+
+   Completion
+   EventID: cmp, 0x0005
+
+      This event detects test completion of continuity test.
+
+      EventDescriptor parameters
+
+         None.
+
+      ObservedEventsDescriptor parameters
+
+         Result
+         ParameterID: res (0x0008)
+
+            Type: enumeration
+
+            Possible values: success (0x0001), failure (0x0000)
+
+E.10.3   Signals
+
+   Continuity test
+   SignalID: ct (0x0003)
+
+      Initiates sending of continuity test tone on the termination to
+      which it is applied.
+
+      Signal Type: TimeOut
+
+      Default value is provisioned
+
+      Additional parameters:
+
+         None.
+
+   Respond
+   SignalID: rsp (0x0004)
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 176]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      The signal is used to respond to a continuity test.  See E.10.5
+      for further explanation.
+
+      Signal Type: On/Off
+
+      Default duration is provisioned
+
+      Additional parameters:
+
+         None.
+
+E.10.4   Statistics
+
+   None.
+
+E.10.5   Procedures
+
+   When a MGC wants to initiate a continuity test, it sends a command to
+   the MG containing:
+
+   -  a signals descriptor with the ct signal; and
+
+   -  an events descriptor containing the cmp event.
+
+   Upon reception of a command containing the ct signal and cmp event,
+   the MG initiates the continuity test tone for the specified
+   Termination.  If the return tone is detected and any other required
+   conditions are satisfied before the signal times out, the cmp event
+   shall be generated with the value of the result parameter equal to
+   success.  In all other cases, the cmp event shall be generated with
+   the value of the result parameter equal to failure.
+
+   When a MGC wants the MG to respond to a continuity test, it sends a
+   command to the MG containing a signals descriptor with the rsp
+   signal.  Upon reception of a command with the rsp signal, the MG
+   either applies a loopback or (for 2-wire circuits) awaits reception
+   of a continuity test tone.  In the loopback case, any incoming
+   information shall be reflected back as outgoing information.  In the
+   2-wire case, any time the appropriate test tone is received, the
+   appropriate response tone should be sent.  The MGC determines when to
+   remove the rsp signal.
+
+   When a continuity test is performed on a Termination, no echo devices
+   or codecs shall be active on that Termination.
+
+   Performing voice path assurance as part of continuity testing is
+   provisioned by bilateral agreement between network operators.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 177]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      (Informative Note) Example tones and test procedure details are
+      given in Q.724 sections 7 and 8, Q.764 section 2.1.8 and Q.1902.4.
+
+E.11  Network Package
+
+   PackageID: nt (0x000b)
+   Version: 1
+   Extends: None
+
+   This package defines properties of network terminations independent
+   of network type.
+
+E.11.1   Properties
+
+   Maximum Jitter Buffer
+   PropertyID: jit (0x0007)
+
+      This property puts a maximum size on the jitter buffer.
+
+      Type: integer in milliseconds
+
+      Possible values: This property is specified in milliseconds.
+
+      Defined in: LocalControlDescriptor
+
+      Characteristics: read/write
+
+E.11.2   Events
+
+   network failure
+   EventID: netfail, 0x0005
+
+      The termination generates this event upon detection of a failure
+      due to external or internal network reasons.
+
+      EventDescriptor parameters
+
+         None.
+
+      ObservedEventsDescriptor parameters
+
+         cause
+         ParameterID: cs (0x0001)
+
+            Type: string
+
+            Possible values: any text string
+
+
+
+
+Groves, et al.              Standards Track                   [Page 178]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+            This parameter may be included with the failure event to
+            provide diagnostic information on the reason of failure.
+
+   quality alert
+   EventID: qualert, 0x0006
+
+      This property allows the MG to indicate a loss of quality of the
+      network connection.  The MG may do this by measuring packet loss,
+      interarrival jitter, propagation delay and then indicating this
+      using a percentage of quality loss.
+
+      EventDescriptor parameters
+
+         Threshold
+         ParameterId: th (0x0001)
+
+            Type: integer
+
+            Possible values: 0 to 99
+
+            Description: threshold for percent of quality loss measured,
+            calculated based on a provisioned method, that could take
+            into consideration packet loss, jitter, and delay for
+            example.  Event is triggered when calculation exceeds the
+            threshold.
+
+      ObservedEventsDescriptor parameters
+
+         Threshold
+         ParameterId: th (0x0001)
+
+            Type: integer
+
+            Possible values: 0 to 99
+
+            Description: percent of quality loss measured, calculated
+            based on a provisioned method, that could take into
+            consideration packet loss, jitter, and delay for example.
+
+E.11.3   Signals
+
+   None.
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 179]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+E.11.4   Statistics
+
+   Duration
+   StatisticsID: dur (0x0001)
+
+      Description: provides duration of time the termination has been in
+      the Context.
+
+      Type: double, in milliseconds
+
+   Octets Sent
+   StatisticID: os (0x0002)
+
+      Type: double
+
+      Possible values: any 64-bit integer
+
+   Octets Received
+   StatisticID: or (0x0003)
+
+      Type: double
+
+      Possible values: any 64-bit integer
+
+E.11.5   Procedures
+
+   None.
+
+E.12  RTP Package
+
+   PackageID: rtp (0x000c)
+   Version: 1
+   Extends: Network Package version 1
+
+   This package is used to support packet-based multimedia data transfer
+   by means of the Real-time Transport Protocol (RTP) [RFC 1889].
+
+E.12.1   Properties
+
+   None.
+
+E.12.2   Events
+
+   Payload Transition
+   EventID: pltrans, 0x0001
+
+      This event detects and notifies when there is a transition of the
+      RTP payload format from one format to another.
+
+
+
+Groves, et al.              Standards Track                   [Page 180]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      EventDescriptor parameters
+
+         None.
+
+      ObservedEventsDescriptor parameters
+
+         ParameterName: rtppayload
+         ParameterID: rtppltype, 0x01
+
+         Type: list of enumerated types.
+
+         Possible values: The encoding method shall be specified by
+         using one or several valid encoding names, as defined in the
+         RTP AV Profile or registered with IANA.
+
+E.12.3   Signals
+
+   None.
+
+E.12.4   Statistics
+
+   Packets Sent
+   StatisticID: ps (0x0004)
+
+      Type: double
+
+      Possible values: any 64-bit integer
+
+   Packets Received
+   StatisticID: pr (0x0005)
+
+      Type: double
+
+      Possible values: any 64-bit integer
+
+   Packet Loss
+   StatisticID: pl (0x0006)
+
+      Describes the current rate of packet loss on an RTP stream, as
+      defined in IETF RFC 1889.  Packet loss is expressed as percentage
+      value: number of packets lost in the interval between two
+      reception reports, divided by the number of packets expected
+      during that interval.
+
+      Type: double
+
+      Possible values: a 32-bit whole number and a 32-bit fraction.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 181]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Jitter
+   StatisticID: jit (0x0007)
+
+      Requests the current value of the interarrival jitter on an RTP
+      stream as defined in IETF RFC 1889.  Jitter measures the variation
+      in interarrival time for RTP data packets.
+
+   Delay
+   StatisticID:delay (0x0008)
+
+      Requests the current value of packet propagation delay expressed
+      in timestamp units.  Same as average latency.
+
+E.12.5   Procedures
+
+   None.
+
+E.13  TDM Circuit Package
+
+      PackageID: tdmc (0x000d)
+      Version: 1
+      Extends: Network Package version 1
+
+      This package may be used by any termination that supports gain and
+      echo control.  It was originally intended for use on TDM circuits
+      but may be more widely used.
+
+
+      New versions or extensions of this package should take non-TDM use
+      into account.
+
+E.13.1   Properties
+
+      Echo Cancellation
+      PropertyID: ec (0x0008)
+
+         Type: boolean
+
+         Possible values:
+
+            "on" (when the echo cancellation is requested) and
+
+            "off" (when it is turned off.)
+
+            The default is provisioned.
+
+         Defined in: LocalControlDescriptor
+
+
+
+
+Groves, et al.              Standards Track                   [Page 182]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+         Characteristics: read/write
+
+      Gain Control
+      PropertyID: gain (0x000a)
+
+         Gain control, or usage of of signal level adaptation and
+         noise level reduction is used to adapt the level of the signal.
+         However, it is necessary, for example for modem calls, to turn
+         off this function.
+
+         Type: integer
+
+         Possible values:
+
+         The gain control parameter may either be specified as
+         "automatic" (0xffffffff), or as an explicit number of decibels
+         of gain (any other integer value).  The default is provisioned
+         in the MG.
+
+      Defined in: LocalControlDescriptor
+
+      Characteristics: read/write
+
+E.13.2   Events
+
+   None.
+
+E.13.3   Signals
+
+   None.
+
+E.13.4   Statistics
+
+   None.
+
+E.13.5   Procedures
+
+   None.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 183]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+APPENDIX I  EXAMPLE CALL FLOWS (INFORMATIVE)
+
+   All H.248.1 implementors must read the normative part of this RFC
+   carefully before implementing from it.  The examples in this appendix
+   should not be used as stand-alone explanations of how to create
+   protocol messages.
+
+   The examples in this appendix use SDP for encoding of the Local and
+   and Remote stream descriptors. SDP is defined in RFC 2327. If there
+   is is any discrepancy between the SDP in the examples, and RFC 2327,
+   the the RFC should be consulted for correctness. Audio profiles used
+   are are those defined in IETF RFC 1890, and others registered with
+   IANA.  For example, G.711 A-law is called PCMA in SDP, and is
+   assigned profile 0. G.723.1 is called G723 and is profile 4; H.263 is
+   called H263 and is profile 34. See also
+   http://www.iana.org/assignments/rtp-parameters.
+
+A.1   Residential Gateway to Residential Gateway Call
+
+   This example scenario illustrates the use of the elements of the
+   protocol to set up a Residential Gateway to Residential Gateway call
+   over an IP-based network.  For simplicity, this example assumes that
+   both Residential Gateways involved in the call are controlled by the
+   same Media Gateway Controller.
+
+A.1.1 Programming Residential GW Analog Line Terminations for Idle
+   Behavior
+
+   The following illustrates the API invocations from the Media Gateway
+   Controller and Media Gateways to get the Terminations in this
+   scenario programmed for idle behavior.  Both the originating and
+   terminating Media Gateways have idle AnalogLine Terminations
+   programmed to look for call initiation events (i.e., -offhook) by
+   using the Modify Command with the appropriate parameters.  The null
+   Context is used to indicate that the Terminations are not yet
+   involved in a Context.  The ROOT termination is used to indicate the
+   entire MG instead of a termination within the MG.
+
+   In this example, MG1 has the IP address 124.124.124.222, MG2 is
+   125.125.125.111, and the MGC is 123.123.123.4. The default Megaco
+   port is 55555 for all three.
+
+   1. An MG registers with an MGC using the ServiceChange command:
+
+   MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222] Transaction = 9998 {
+       Context = - {
+
+
+
+Groves, et al.              Standards Track                   [Page 184]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+           ServiceChange = ROOT {Services {
+               Method=Restart,
+               ServiceChangeAddress=55555, Profile=ResGW/1}
+           }
+       } }
+
+   2. The MGC sends a reply:
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Reply = 9998 {
+      Context = - {ServiceChange = ROOT {
+        Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } }
+
+   3. The MGC programs a Termination in the NULL context.  The
+   terminationId is A4444, the streamId is 1, the requestId in the
+   Events descriptor is 2222.  The mId is the identifier of the sender
+   of this message, in this case, it is the IP address and port
+   [123.123.123.4]:55555.  Mode for this stream is set to SendReceive.
+   "al" is the analog line supervision package.  Local and Remote are
+   assumed to be provisioned.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 {
+       Context = - {
+           Modify = A4444 {
+               Media { Stream = 1 {
+                        LocalControl {
+                            Mode = SendReceive,
+                            tdmc/gain=2,  ; in dB,
+                            tdmc/ec=on
+                        },
+
+                    }
+               },
+               Events = 2222 {al/of(strict=state)}
+           }
+       } }
+
+
+   The dialplan script could have been loaded into the MG previously.
+   Its function would be to wait for the OffHook, turn on dialtone and
+   start collecting DTMF digits.  However in this example, we use the
+   digit map, which is put into place after the offhook is detected
+   (step 5 below).
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 185]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   Note that the embedded EventsDescriptor could have been used to
+   combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
+
+   4. The MG1 accepts the Modify with this reply:
+
+   MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222]:55555
+
+   Reply = 9999 {
+      Context = - {Modify = A4444} }
+
+   5. A similar exchange happens between MG2 and the MGC, resulting in
+   an idle Termination called A5555.
+
+A.1.2 Collecting Originator Digits and Initiating Termination
+
+   The following builds upon the previously shown conditions.  It
+   illustrates the transactions from the Media Gateway Controller and
+   originating Media Gateway (MG1) to get the originating Termination
+   (A4444) through the stages of digit collection required to initiate a
+   connection to the terminating Media Gateway (MG2).
+
+   6. MG1 detects an offhook event from User 1 and reports it to the
+   Media Gateway Controller via the Notify Command.
+
+   MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222]:55555 Transaction = 10000 {
+      Context = - {
+          Notify = A4444 {ObservedEvents =2222 {
+            19990729T22000000:al/of(init=false)}}
+      } }
+
+   7. And the Notify is acknowledged.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Reply = 10000 {
+
+       Context = - {Notify = A4444} }
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 186]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   8. The MGC Modifies the termination to play dial tone, to look for
+   digits according to Dialplan0 and to look for the on-hook event now.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 10001 {
+       Context = - {
+           Modify = A4444 {
+               Events = 2223 {
+                   al/on(strict=state), dd/ce {DigitMap=Dialplan0}
+               },
+               Signals {cg/dt},
+               DigitMap= Dialplan0{ (0| 00|[1-
+   7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
+           }
+       } }
+
+   9. And the Modify is acknowledged.
+
+   MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222]:55555 Reply = 10001 {
+       Context = - {Modify = A4444} }
+
+   10.   Next, digits are accumulated by MG1 as they are dialed by User
+   1.  Dialtone is stopped upon detection of the first digit.  When an
+   appropriate match is made of collected digits against the currently
+   programmed Dialplan for A4444, another Notify is sent to the Media
+   Gateway Controller.
+
+   MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222]:55555 Transaction = 10002 {
+      Context = - {
+          Notify = A4444 {ObservedEvents =2223 {
+            19990729T22010001:dd/ce{ds="916135551212",Meth=UM}}}
+      } }
+
+   11.   And the Notify is acknowledged.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Reply = 10002 {
+       Context = - {Notify = A4444} }
+
+
+   12.   The controller then analyses the digits and determines that a
+   connection needs to be made from MG1 to MG2.  Both the TDM
+
+
+
+Groves, et al.              Standards Track                   [Page 187]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   termination A4444, and an RTP termination are added to a new context
+   in MG1.  Mode is ReceiveOnly since Remote descriptor values are not
+   yet specified.  Preferred codecs are in the MGC's preferred order of
+   choice.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 {
+       Context = $ {
+          Add = A4444,
+          Add = $ {
+              Media {
+                Stream = 1 {
+                     LocalControl {
+                         Mode = ReceiveOnly,
+
+                         nt/jit=40 ; in ms
+                     },
+                     Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4
+   a=ptime:30 v=0 c=IN IP4 $ m=audio $ RTP/AVP 0
+                     }
+                }
+             }
+          }
+       } }
+
+
+      NOTE - The MGC states its preferred parameter values as a series
+      of SDP blocks in  Local.  The MG fills in the Local Descriptor in
+      the Reply.
+
+   13.   MG1 acknowledges the new Termination and fills in the Local IP
+   address and UDP port.  It also makes a choice for the codec based on
+   the MGC preferences in Local.  MG1 sets the RTP port to 2222.
+
+   MG1 -> MGC:
+
+   MEGACO/1 [124.124.124.222]:55555 Reply = 10003 {
+      Context = 2000 {
+         Add = A4444,
+         Add=A4445{
+            Media {
+                Stream = 1 {
+                    Local { v=0 o=- 2890844526 2890842807 IN IP4
+   124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
+   RTP/AVP 4 a=ptime:30 a=recvonly
+                    } ; RTP profile for G.723.1 is 4
+                }
+
+
+
+Groves, et al.              Standards Track                   [Page 188]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+            }
+         }
+      } }
+
+   14.   The MGC will now associate A5555 with a new Context on MG2, and
+   establish an RTP Stream (i.e., A5556 will be assigned), SendReceive
+   connection through to the originating user, User 1.  The MGC also
+   sets ring on A5555.
+
+   MGC to MG2:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 50003 {
+       Context = $ {
+          Add = A5555  { Media {
+               Stream = 1 {
+                    LocalControl {Mode = SendReceive} }},
+         Events=1234{al/of(strict=state)},
+               Signals {al/ri}
+
+               },
+          Add  = $ {Media {
+               Stream = 1 {
+                    LocalControl {
+                       Mode = SendReceive,
+                       nt/jit=40 ; in ms
+                    },
+                    Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4
+   a=ptime:30
+                    },
+                    Remote { v=0 c=IN IP4 124.124.124.222 m=audio 2222
+   RTP/AVP 4 a=ptime:30
+                    } ; RTP profile for G.723.1 is 4
+                }
+             }
+         }
+      } }
+
+   15.   This is acknowledged.  The stream port number is different from
+   the control port number.  In this case it is 1111 (in the SDP).
+
+   MG2 to MGC:
+
+   MEGACO/1 [125.125.125.111]:55555 Reply = 50003 {
+      Context = 5000 {
+      Add = A5555,
+         Add = A5556{
+            Media {
+               Stream = 1 {
+
+
+
+Groves, et al.              Standards Track                   [Page 189]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                   Local { v=0 o=- 7736844526 7736842807 IN IP4
+   125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
+   RTP/AVP 4 }
+               } ; RTP profile for G723.1 is 4
+            }
+          }
+
+      } }
+
+   16.   The above IPAddr and UDPport need to be given to MG1 now.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 10005 {
+     Context = 2000 {
+       Modify = A4444 {
+         Signals {cg/rt}
+       },
+       Modify = A4445 {
+          Media {
+               Stream = 1 {
+                   Remote { v=0 o=- 7736844526 7736842807 IN IP4
+   125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
+   RTP/AVP 4
+                   }
+               } ; RTP profile for G723.1 is 4
+           }
+       }
+     } }
+
+
+   MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222]:55555 Reply = 10005 {
+      Context = 2000 {Modify = A4444, Modify = A4445} }
+
+   17.   The two gateways are now connected and User 1 hears the
+   RingBack.  The MG2 now waits until User2 picks up the receiver and
+   then the two-way call is established.
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 190]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   From MG2 to MGC:
+
+   MEGACO/1 [125.125.125.111]:55555 Transaction = 50005 {
+      Context = 5000 {
+
+          Notify = A5555 {ObservedEvents =1234 {
+            19990729T22020002:al/of(init=false)}}
+      } }
+
+   From MGC to MG2:
+
+   MEGACO/1 [123.123.123.4]:55555 Reply = 50005 {
+       Context = - {Notify = A5555} }
+
+   From MGC to MG2:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 50006 {
+      Context = 5000 {
+         Modify = A5555 {
+            Events = 1235 {al/on(strict=state)},
+            Signals { } ; to turn off ringing
+         }
+      } }
+
+   From MG2 to MGC:
+
+   MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
+    Context = 5000 {Modify = A4445} }
+
+   18.   Change mode on MG1 to SendReceive, and stop the ringback.
+
+   MGC to MG1:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 10006 {
+      Context = 2000 {
+         Modify = A4445 {
+            Media {
+               Stream = 1 {
+                  LocalControl {
+                     Mode=SendReceive
+
+                  }
+               }
+            }
+         },
+         Modify = A4444 {
+            Signals { }
+         }
+
+
+
+Groves, et al.              Standards Track                   [Page 191]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+      } }
+
+   from MG1 to MGC:
+
+   MEGACO/1 [124.124.124.222]:55555 Reply = 10006 {
+      Context = 2000 {Modify = A4445, Modify = A4444}}
+
+   19.   The MGC decides to Audit the RTP termination on MG2.
+
+   MGC -> MG2:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 50007 {
+      Context = - {AuditValue = A5556{
+         Audit{Media, DigitMap, Events, Signals, Packages, Statistics }}
+      } }
+
+   20.   The MG2 replies.
+
+   MG2 -> MGC:
+
+   MEGACO/1 [125.125.125.111]:55555 Reply = 50007 {
+      Context = - { AuditValue = A5556 {
+             Media {
+                TerminationState { ServiceStates = InService,
+            Buffer = OFF },
+          Stream = 1 {
+                    LocalControl { Mode = SendReceive,
+                       nt/jit=40 },
+                    Local { v=0 o=- 7736844526 7736842807 IN IP4
+   125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
+   RTP/AVP  4 a=ptime:30
+                   },
+                    Remote { v=0 o=- 2890844526 2890842807 IN IP4
+   124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
+   RTP/AVP  4 a=ptime:30
+                    } } },
+              Events,
+           Signals,
+           DigitMap,
+          Packages {nt-1, rtp-1},
+             Statistics { rtp/ps=1200,  ; packets sent
+                          nt/os=62300, ; octets sent
+                          rtp/pr=700, ; packets received
+                          nt/or=45100, ; octets received
+                          rtp/pl=0.2,  ; % packet loss
+                          rtp/jit=20,
+                          rtp/delay=40 } ; avg latency
+          }
+
+
+
+Groves, et al.              Standards Track                   [Page 192]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+       } }
+
+   21.   When the MGC receives an onhook signal from one of the MGs, it
+   brings down the call.  In this example, the user at MG2 hangs up
+   first.
+
+   From MG2 to MGC:
+
+   MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 {
+      Context = 5000 {
+          Notify = A5555 {ObservedEvents =1235 {
+             19990729T24020002:al/on(init=false)}
+          }
+      } }
+
+   From MGC to MG2:
+
+   MEGACO/1 [123.123.123.4]:55555 Reply = 50008 {
+
+       Context = - {Notify = A5555} }
+
+   22.   The MGC now sends both MGs a Subtract to take down the call.
+   Only the subtracts to MG2 are shown here.  Each termination has its
+   own set of statistics that it gathers.  An MGC may not need to
+   request both to be returned.  A5555 is a physical termination, and
+   A5556 is an RTP termination.
+
+   From MGC to MG2:
+
+   MEGACO/1 [123.123.123.4]:55555 Transaction = 50009 {
+      Context = 5000 {
+         Subtract = A5555 {Audit{Statistics}},
+         Subtract = A5556 {Audit{Statistics}}
+      } }
+
+   From MG2 to MGC:
+
+   MEGACO/1 [125.125.125.111]:55555 Reply = 50009 {
+      Context = 5000 {
+        Subtract = A5555 {
+             Statistics {
+                nt/os=45123, ; Octets Sent
+                nt/dur=40 ; in seconds
+                }
+          },
+          Subtract = A5556 {
+             Statistics {
+                rtp/ps=1245, ; packets sent
+
+
+
+Groves, et al.              Standards Track                   [Page 193]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+                nt/os=62345, ; octets sent
+                rtp/pr=780, ; packets received
+                nt/or=45123, ; octets received
+                rtp/pl=10, ;  % packets lost
+                rtp/jit=27,
+                rtp/delay=48 ; average latency
+             }
+          }
+      } }
+
+   23.   The MGC now sets up both MG1 and MG2 to be ready to detect the
+   next off-hook event.  See step 1.  Note that this could be the
+   default state of a termination in the null context, and if this were
+   the case, no message need be sent from the MGC to the MG.  Once a
+   termination returns to the null context, it goes back to the default
+   termination values for that termination.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 194]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+APPENDIX II  Changes From RFC 3015
+
+   In the following table, "source" indicates when the change was first
+   approved.  It has the following values:
+
+   IG1100: H.248 Implementor's Guide approved in November, 2000 (as TD
+   Plen-39, Christian Groves, editor).
+
+   IG0601: H.248 Implementor's Guide approved in June, 2001 (as  TD
+   Plen-15, Christian Groves, editor).
+
+   IGDUB: Draft H.248 Implementor's Guide approved at the Q.3
+   Rapporteur's meeting held near Dublin, October 2001 (as TD-28, Terry
+   Anderson, editor).
+
+   GEN0202: added at the Geneva meeting, February 2002, which consented
+   to H.248 v1 Amendment 1 (as TD Plen-36r1, Marcello Pantaleo, editor).
+
+   ITUPOST: added in post-Geneva editing by the ITU-T.
+
+   TTPOST: added in post-approval editing by the Megaco Chair, Tom
+   Taylor, who assembled this document for submission.
+
+   Section    Source                       Change
+
+   1          ITUPOST   Reference changed from H.248 to H.248.1.
+
+   2.1        ITUPOST   Reference added for error codes, changed from
+                        H.248 Annex L to H.248.8 (2002).
+
+   2.1        IG1100    Corrected Q.765 reference to Q.765.5.
+
+   2.1        GEN0202   Added reference to X.690.
+
+   2.2        GEN0202   Added reference to H.226.
+
+   2.2         IGDUB    Added informative references to Q.724, Q.764,
+                        and Q.1902.4.
+
+   4          IG0601    Added expansion of ALF.
+
+   5          TTPOST    Gave priority to IETF conventions (added at
+                        start of document).
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 195]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   6.1.1      IG0601    Added text regarding use of wildcards for
+                        context identifiers.  (This information
+                        already appeared in section 8.1.2.  The IG
+                        change subsequently disappeared.)
+
+   6.1.1      IG1100    Added ranking of priority values.
+
+   6.2         IGDUB    Deleted definition of signals.
+
+   6.2        GEN0202   Expanded text and diagrams describing
+                        multiplexing terminations.
+
+   6.2        TTPOST    Added asterisks to multiplexing diagrams to
+                        indicate centre of context.  Added Figure 6a
+                        showing cascading of multiplexes.
+
+   6.2.2      IG0601    Added text indicating that ALL does not
+                        include ROOT.
+
+   6.2.3      IG1100    Added text clarifying what must be supported
+                        to claim support of a package.
+
+   6.2.3      IG1100    Added text indicating what packages a peer can
+                        indicate support for, when some of them are
+                        extensions of others.
+
+   6.2.4      IG0601    Added text on ability of provisioning to
+                        override default values, and need for MGC to
+                        audit to learn the provisioned defaults.
+
+   6.2.4      IG0601    Added text indicating effect of omitting
+                        specific properties from Descriptors in
+                        commands modifying a termination.
+                        Contradicted original text saying that omitted
+                        properties retain their prior values (still
+                        true for entirely-omitted Descriptors).
+
+   6.2.4      GEN0202   Modified above text to restrict it to
+                        read/write properties, allow for default
+                        behaviour in place of default values if so
+                        specified in the property definition.
+
+   6.2.4       IGDUB    Trimmed definition of signals Descriptor in
+                        table and inserted cross-reference to section
+                        7.1.11.
+
+   6.2.4      IG1100    Added Topology and Error Descriptors to table.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 196]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   6.2.5       IGDUB    Specified error code to return if ROOT used
+                        inappropriately.
+
+   7.1.1      IG1100    Added qualification to explanation of effect
+                        of missing Audit Descriptor, excepting
+                        Subtract.
+
+   7.1.3      GEN0202   Changed "inputs" to "bearers" to be consistent
+                        with terminology in 6.2.
+
+   7.1.4      IG0601    Small change to make clear that more than one
+                        of Local, Remote, and LocalControl can be
+                        included in the default streamId.
+
+   7.1.7      IG0601    Default value for Mode specified to be
+                        Inactive.
+
+   7.1.7      GEN0202   Added text requiring processing of media in
+                        any of the reserved formats, where more than
+                        one has been reserved in a given stream.
+
+   7.1.8       IGDUB    Added restriction to at most one m= line per
+                        session description.
+
+   7.1.9      IG0601    Text added to omit request identifier if the
+                        EventsDescriptor is empty.  Further text added
+                        at end to indicate the effects of an empty
+                        EventsDescriptor and an empty
+                        EventBufferDescriptor.
+
+   7.1.9      IG0601    Fixed typo for destination of a Notify.
+
+   7.1.9      IG1100    Added note to say event remains active after
+                        it has been notified, so long as it is still
+                        present in the active Events Descriptor.
+
+   7.1.11      IGDUB    Added definition of signals.
+
+   7.1.11     GEN0202   Modified definition to include example of more
+                        complex signal, and added role of signal in
+                        media preparation for future signals.
+
+   7.1.11      IGDUB    The timeout completion reason was broadened to
+                        include other circumstances where the signal
+                        completed on its own.  Text added to indicate
+                        that if default signal type changed to TO,
+                        duration parameter must be provided.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 197]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   7.1.11     GEN0202   Removed reference to BR signal being "so
+                        short" it will stop on its own.  Added text
+                        indicating that if the type of a signal is
+                        changed to TO, the Duration parameter must be
+                        supplied.
+
+   7.1.11     IG1100    Deleted text discussing type of Signals List.
+
+   7.1.12     GEN0202   Improved wording of introductory paragraph and
+                        added text making content of returned
+                        Descriptor clear.
+
+   7.1.14.2   GEN0202   Added text indicating that when the start
+                        timer is set to 0, initial digit timing is
+                        disabled and the MG waits indefinitely for
+                        digits.
+
+   7.1.14.2   GEN0202   Added text pointing out that default digit
+                        timer values should be provisioned, but can be
+                        overridden in the digit map.
+
+   7.1.14.3   GEN0202   Changed result of long-short digit timer
+                        conflict from undefined to long.
+
+   7.1.14.6   IG1100    Clarified that the digit map is provided by
+                        the eventDM parameter, which must be present.
+
+   7.1.14.7   GEN0202   Added text clarifying that events covered by
+                        the digit map completion event have no side-
+                        effects unless separately enabled.
+
+   7.1.14.8   IG0601    Added requirement that the event specification
+                        include the eventDM parameter.
+
+   7.1.17      IGDUB    Added text to indicate timestamp is optional
+                        and to include observed event parameters in
+                        reported content.
+
+   7.1.17     GEN0202   Deleted provision that time is expressed in
+                        UTC (since intention was to use format, not
+                        time zone).
+
+   7.1.18      IGDUB    Added text indicating error to return if
+                        topology option not supported.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 198]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   7.1.18     IG1100    Added text clarifying effect of not mentioning
+              TTPOST    a termination in a topology Descriptor, and
+                        default topology for a new termination.  (This
+                        text got lost between the Dublin meeting and
+                        the production of H.248 Amendment 1 out of the
+                        Geneva 02/02 meeting.  It has been added back
+                        to the present document.)
+
+   7.1.19     IG1100    New section to describe Error Descriptor.
+              GEN0202   Slightly edited in Geneva 02/02 meeting.
+              ITUPOST   Reference for error code documentation updated
+                        to H.248.8.
+
+   7.1.19     IG0601    Added paragraph giving guidance on level at
+                        which errors should be reported.
+
+   7.2        IG1100    Noted possibility of Error Descriptor in reply
+                        to any command.
+
+   7.2.1      IG1100    Added EventBufferDescriptor as Add parameter.
+
+   7.2.1      IG1100    Removed restriction on use of CHOOSE wildcard.
+
+   7.2.2      IG1100    Added EventBufferDescriptor as Modify
+                        parameter.
+
+   7.2.2      GEN0202   Added text on side-effects of Modify of a
+                        multiplexing termination.
+
+   7.2.3      IG1100    Added prohibition against subtracting from the
+                        NULL context.
+
+   7.2.3      GEN0202   Added text on side-effects of Subtract of a
+                        multiplexing termination.
+
+   7.2.3       IGDUB    Added text clarifying effect of empty
+                        AuditDescriptor in Subtract.
+
+   7.2.4      IG1100    Added EventBufferDescriptor as Move parameter.
+
+   7.2.4      GEN0202   Removed misleading statement that Move acts as
+                        subtract from original context.
+
+   7.2.4      IG1100    Clarified effect of Move on properties of the
+                        moved termination.
+
+   7.2.4      GEN0202   Added text on side-effects of Move of a
+                        multiplexing termination.
+
+
+
+Groves, et al.              Standards Track                   [Page 199]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   7.2.5      IG1100    Added examples showing W- wildcard usage.
+
+   7.2.5      IG1100    Noted that returning a list of all contextIDs
+                        requires that they be returned one per
+                        ActionReply.
+
+   7.2.5      IG1100    Added table entry (ALL, specific) to determine
+                        context in which termination currently
+                        resides.
+
+   7.2.6      GEN0202   Added table similar to that in 7.2.5.
+
+   7.2.7      IG0601    Added TerminationID to API.
+
+   7.2.7       IGDUB    Indicated timestamp was optional in Notify, to
+                        accord with syntax.
+
+   7.2.7      IG1100    Noted possibility of sending Error Descriptor
+                        in Notify.
+
+   7.2.8      IG0601    Added text to description of Forced method to
+                        indicate that Forced on ROOT indicates a cold
+                        restart (all context state lost).
+
+   7.2.8       IGDUB    Amplified explanation of Disconnected method
+                        to emphasize return to the previously
+                        controlling MGC.
+
+   7.2.8      IG0601    Added text for MG use of Failover method when
+                        it detects MGC failure.
+
+   7.2.8      IG1100    Added notes discouraging use of
+                        ServiceChangeAddress and warning that it could
+                        be either a full address or just a port
+                        number.
+
+   7.2.8      IG0601    Added text indicating that timestamp does not
+                        necessarily represent absolute time, only
+                        local clock reading.
+
+   7.2.8       IGDUB    Corrected "gateway" to "MGC" in discussion of
+                        returned ServiceChangeMgcId parameter.
+
+   7.3        IG0601    Removed error code documentation to Annex L
+              ITUPOST   (now H.248.8).
+
+   8          IG1100    Added requirement that an Action be non-empty.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 200]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   8          GEN0202   Added context properties and context property
+                        audit requests to commands as potential
+                        contents of actions.
+
+   8.1.2      GEN0202   Added prohibition on using partial contextIDs
+                        with ALL wildcards.
+
+   8.2.2      IG1100    Added text clarifying when in transaction
+                        processing the requested actions have been
+                        completed and a reply can be sent.
+
+   8.2.2      IG1100    Added ALL as allowed contextID in
+                        TransactionReply.
+
+   8.2.2      GEN0202   Provided general reference to section 7.1.19
+                        for generation of error Descriptors.
+
+   8.2.2      IG0601    Corrected Actions to Commands when discussing
+                        partially-understood action.
+
+   8.3        IG0601    Added text specifying that the same MId value
+                        must be used by a given entity throughout the
+                        life of a control association.
+
+   8.3        IG0601    Added text expanding on independence of
+                        transactions from messages.
+
+   9          ITUPOST   Indicated that additional transports may be
+                        defined in separate Recommendations as well as
+                        annexes to the primary specification.
+
+   9          IG0601    Gave specific example of "request source
+                        address" for IP.
+
+   9.1        IG1100    Deleted restriction to one outstanding Notify
+                        command on a termination at one time, since
+                        this is transport-specific.
+
+   9.1        IG0601    Restored restriction, but noted that it
+                        applied only to transport not guaranteeing
+                        ordered delivery.
+
+   10.2       IG1100    Corrected length of synthesized address field
+                        from 10 to 20 hex digits and indicated that
+                        calculation should be over entire message, not
+                        just one transaction.
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 201]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   11.2       IG1100    Corrected text in first two paragraphs
+                        describing use of ServiceChangeMgcId
+                        parameter.
+
+   11.2       IG1100    Corrected "Transaction Accept" to "Transaction
+                        Reply".
+
+   11.4       IG0601    Noted that support of redundant MGs requires
+              GEN0202   use of a reliable transport and support in the
+                        MGC.  Added more explanation in Geneva.
+
+   11.5       IG0601    Added text clarifying procedure if MG unable
+                        to establish a control relationship with any
+                        of its eligible MGCs.
+
+   11.5        IGDUB    Added text indicating that when trying to
+                        reestablish contact with the previously
+                        controlling MGC the MG uses the Disconnected
+                        method.
+
+   11.5       IG1100    Clarified handoff procedure.
+
+   11.5       GEN0202   Changed text on replies to transactions in
+                        progress during handoff.  Replies now
+                        discarded when the service relationship with
+                        the old MGC has ended, rather than sent to the
+                        new MGC.  The new MGC could still send replies
+                        to requests sent to the old MGC.
+
+   12.1.1     GEN0202   Added optional package designation as
+                        "designed to be extended only".
+
+   12.1.1     IG1100    Made prohibition on overloading of identifiers
+                        in extended packages transitive through all
+                        ancestors of the extended package.
+
+   12.1.2      IGDUB    Clarified the set of types allowed for
+                        properties.
+
+   12.1.2     GEN0202   Added requirement to specify the base type of
+                        a sub-list.
+
+   12.1.2     GEN0202   Provided requirements for content of the
+                        "Possible Values" template item, including
+                        specification of default values or behaviour.
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 202]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   12.1.4     GEN0202   Added requirement to specify the default
+                        signal type, and specify a default duration
+                        for TO signals.  Also noted that duration is
+                        meaningless for BR, and that the signal type
+                        might be dependent on the values of other
+                        signal parameters.
+
+   12.2       GEN0202   Fixed section title (covers only event and
+                        signal parameters, not properties or
+                        statistics).
+
+   12.2       IG1100    Reserved SPA and EPA prefixes, so they are not
+                        to be used for signal and event parameter
+                        tokens.
+
+   12.2       IG0601    Expanded list of reserved prefixes.
+
+   12.2        IGDUB    Clarified the set of types allowed for signal
+                        and event parameters.
+
+   12.2       GEN0202   Added requirement to specify the base type of
+                        a sub-list.
+
+   12.2       GEN0202   Provided requirements for content of the
+                        "Possible Values" template item, including
+                        specification of default values or behaviour.
+
+   12.4        IGDUB    Corrected to indicate identifiers must start
+                        with alphabetic rather than alphanumeric
+                        character.
+
+   13.1       IG0601    Changed private range of binary package
+                        identifiers to convenient hex values.
+
+   A          GEN0202   Removed versions from X.680 and X.690
+                        references.
+
+   A.2         IGDUB    Added note warning that the syntax alone does
+                        not provide a complete description of the
+                        constraints, but must be supplemented by a
+                        reading of the text and comments.
+
+   A.2        IG0601    Added description of double wrapping of
+                        parameters declared as OCTET STRING.
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 203]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   A.2        GEN0202   Some editing of double wrapping description to
+                        use ASN.1, BER in their proper places.  Added
+                        possibility of encoding strings as UTF8String,
+                        but only if they contain non-ASCII characters.
+
+   A.2         IGDUB    Added line in table on double wrapping of true
+                        octet strings.
+
+   A.2        IG1100    Corrected and expanded comments describing
+                        mtpAddress form of MId.  Fixed maximum length
+                        of mtpAddress both here and in
+                        ServiceChangeAddress.
+
+   A.2        IG0601   Inserted missing lines in IP4Address
+                        production.
+
+   A.2        IG0601    Modified TransactionResponseAck to allow
+                        acknowledgement of multiple ranges of
+                        transactionIds.
+
+   A.2        IG0601    Corrected numerical value of CHOOSE as a
+                        context identifier.
+
+   A.2         IGDUB    Added missing extension marker in
+                        TopologyRequest.
+
+   A.2        IG1100    AuditReply and AuditResult modified to bring
+                        binary functionality into line with text
+                        functionality.
+
+   A.2        IG0601    Removed OPTIONAL tag from terminationID in
+                        NotifyReply.
+
+   A.2        IG0601    Added extraInfo substructure to EventParameter
+                        and SigParameter.
+
+   A.2        IG0601    Modified MediaDescriptor to make it optional
+                        to specify a stream.
+
+   A.2        IG0601    Added OPTIONAL tags to reserveValue and
+                        reserveGroup.
+
+   A.2         IGDUB    Added to comments for pkgdName to indicate
+                        applicability to event names, signal names,
+                        and statisticIds as well as property.
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 204]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   A.2        IG0601    RequestID made optional in EventsDescriptor
+                        and SecondEventsDescriptor and comment added
+                        saying it must be present if events are
+                        present.
+
+   A.2        IG1100    Added OPTIONAL tags on RequestActions and
+                        SecondRequestedActions keepActive BOOLEANs.
+
+   A.2        IG1100    Added comment to indicate requestID value to
+                        use in an AuditCapReply.
+
+   A.2        GEN0202   Added comment to DigitMapValue indicating time
+                        units for timers.
+
+   A.2        IG0601    Added comment indicating coding of Value for
+              GEN0202   ServiceChangeReason.  Cleaned up in Geneva to
+                        use ASN.1 and BER in their proper places.
+
+   A.2        IG0601    Inserted missing extension marker in
+                        ServiceChangeParm production.
+
+   A.2        IG0601    Aligned definition of mtpAddress in
+                        ServiceChangeAddress with that in MId.
+
+   A.2        IG0601    Added timestamp to ServiceChangeResParm.
+
+   A.2         IGDUB    Changed type of profileName in
+                        ServiceChangeProfile to IA5String.
+
+   A.2        IG0601    Made returned value optional in
+                        statisticsParameter, to support
+                        auditCapability result.
+
+   A.2        GEN0202   Added reference to ISO 8601:1988 for
+                        TimeNotation.
+
+   A.2        IG1100    Value production modified to support the
+                        sublist parameter type.
+
+   A.3        IG1100    Corrected ABNF for digitStringlisT, replacing
+                        "/" with "|".
+
+   A.3        IG1100    Added parentheses to digitMapRange production.
+
+   A.3        IG1100    Replaced more abbreviated syntax for pathName
+                        with fuller definition and constraints copied
+                        from B.2.
+
+
+
+
+Groves, et al.              Standards Track                   [Page 205]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   B.2         IGDUB    Added note warning that the syntax alone does
+                        not provide a complete description of the
+                        constraints, but must be supplemented by a
+                        reading of the text and comments.
+
+   B.2        IG0601    Added note warning that the interpretation of
+                        symbols is context-dependent.
+
+   B.2        IG1100    Added comment to indicate case insensitivity
+                        of protocol (excepting SDP) and ABNF.
+
+   B.2        IG0601    Expanded upon and capitalized this comment.
+
+   B.2        IG0601    Lengthy note added on the coding of the VALUE
+                        construct.
+
+   B.2         IGDUB    Deleted sentence in note suggesting that
+                        packages could add new types for properties,
+                        parameters, or statistics.
+
+   B.2        IG0601    Added note indicating that parsers should
+                        allow for white space preceding the first line
+                        of SDP in Local or Remote.
+
+   B.2         IGDUB    Added comments identifying the O- and W- tags.
+
+   B.2        IG1100    Moved wildcard tag up from individual commands
+                        to commandRequestList.
+
+   B.2        GEN0202   Added additional error case to actionReply.
+
+   B.2        IG0601    Modified syntax of auditOther to allow return
+                        of terminationID only.
+
+   B.2         IGDUB    Corrected upper limit for V4hex.
+
+   B.2        IG1100    Corrected and expanded comments describing
+                        mtpAddress form of MId.
+
+   B.2        IG0601    Modified comment to mediaParm to make
+                        streamParms and StreamDescriptor mutually
+                        exclusive.
+
+   B.2        GEN0202   Modified comment further to indicate at most
+                        one instance of terminationStateDescriptor.
+
+   B.2        GEN0202   Expanded comment for streamParm to indicate
+                        the restriction on repetition is per item.
+
+
+
+Groves, et al.              Standards Track                   [Page 206]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   B.2        IG0601    Modified "at most once" comments to localParm,
+                        terminationStateParm, and modemType, to allow
+                        multiple instances of propertyParm in the
+                        first two cases and extensionParameter in the
+                        last one.
+
+   B.2        IG0601    Added note before description of Local and
+                        Remote, pointing out that the octet value x00
+                        is not allowed in octetString.
+
+   B.2        IG0601    Syntax for eventsDescriptor, embedFirst, and
+                        eventBufferDescriptor modified to make
+                        contents beyond token optional.
+
+   B.2         IGDUB    Replaced "event" by "item" in comment to
+                        pkgdName because pkgdName applies to
+                        properties, signals, and statistics as well.
+
+   B.2        IG0601    Corrected placement of EQUAL in eventDM
+                        production.
+
+   B.2        IG1100    Added comment and syntax to indicate requestID
+                        value to use in an AuditCapReply.
+
+   B.2        IG1100    Corrected Modem Descriptor to allow package
+                        items as properties.
+
+   B.2        IG0601    Comment to modemType changed to allow multiple
+                        instances of extensionParameter.
+
+   B.2        GEN0202   Comment added to indicate units for Timer.
+
+   B.2        IG1100    Added parentheses to digitMapRange production.
+
+   B.2        IG1100    Added comment to serviceChangeParm,
+                        restricting each parameter to one appearance.
+
+   B.2        IG0601    Added comments making serviceChangeMgcId and
+                        serviceChangeAddress mutually exclusive in
+                        ServiceChangeParm and servChgReplyParm.
+
+   B.2         IGDUB    Added comment to serviceChangeParm indicating
+                        that ServiceChangeMethod and
+                        ServiceChangeReason are required.
+
+   B.2        IG0601    Added Timestamp to servChgReplyParm.
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 207]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   B.2        IG0601    Added comment indicating coding of Value for
+                        ServiceChangeReason.
+
+   B.2        IG0601    Modified ServiceChangeAddress to use MId
+                        definition for full address.
+
+   B.2        IG1100    Made returned value optional in
+                        statisticsParameter, to support
+                        auditCapability result.
+
+   B.2        IG1100    Changed topologyDescriptor to allow multiple
+                        triples.
+
+   B.2        IG0601    Added comment forbidding use of a double quote
+                        within a quotedString value.
+
+   B.2        IG1100    Reserved prefixes for new tokens added to
+                        signalParameter and eventParameter, to avoid
+                        collision with package names.
+
+   B.2        IG1100    EmbedToken and EmergencyToken changed to
+                        remove clash with EventBufferToken.
+
+   B.3        IG1100    New section describing hexadecimal octet
+                        encoding.
+
+   B.4        IG1100    New section describing hex octet sequence.
+
+   C          IG1100    Added permission to use Annex C properties in
+                        LocalControl as well as in Local and Remote.
+
+   C          IG0601    Added text making support of all properties of
+                        Annex C optional.
+
+   C           IGDUB    Added directions to reconcile tabulated
+                        formats with allowed types for properties.
+
+   C.1        IG1100    Corrected Q.765 reference to Q.765.5 for
+                        ACodec.
+
+   C.1        IG1100    Deprecated Echocanc codepoint in favour of
+                        package-defined property.
+
+   C.4        ITUPOST   Updated references from Q.2961 to Q.2961.1.
+
+   C.4         IGDUB    Added details on format of VPVC.
+
+   C.9        IG1100    Renamed USI to layer1prot.
+
+
+
+Groves, et al.              Standards Track                   [Page 208]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   C.9        IG1100    Deprecated ECHOCI codepoint in favour of
+                        package-defined property.
+
+   C.9        IG1100    Added new USI property.
+
+   C.11       IG1100    Added m= line tag.
+
+   D.1        IG0601    Added explanation of ALF.
+
+   D.1.5       IGDUB    Expanded text indicating that when trying to
+                        reestablish contact with the previously
+                        controlling MGC the MG uses the Disconnected
+                        method.
+
+   E.1.2      GEN0202   Added missing EventsDescriptor parameters
+                        lines.
+
+   E.1.2      GEN0202   For the Signal Completion event:
+                        - corrected the description of how it is
+                        enabled
+                        - heavily edited the description of the Signal
+                        Identity observed event parameter and added a
+                        type.
+
+   E.1.2       IGDUB    The timeout completion reason for the Signal
+                        Completion event was broadened to include
+                        other circumstances where the signal completed
+                        on its own.
+
+   E.1.2      IG1100    Added signal list ID observed event parameter
+                        to the Signal Completion event.
+
+   E.2.1      IG0601    Added missing read only, read-write
+                        specifications.
+
+   E.2.1      IG0601    Split ProvisionalResponseTimer properties into
+                        one for MG, one for MGC.
+
+   E.3        GEN0202   Added "Designed to be extended only" to
+                        tonegen package description.
+
+   E.4        GEN0202   Added "Designed to be extended only" to
+                        tonedet package description.
+
+   E.4.2      GEN0202   Added type for tone ID observed parameter for
+                        Long Tone Detected event.
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 209]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   E.6.2      IG1100    Corrected binary identifier for digit map
+                        completion event to avoid clash with base
+                        package.
+
+   E.6.2      IG1100    Removed procedural text.
+
+   E.6.5      IG1100    Added procedural text indicating where to find
+                        the applicable digit map and indicating the
+                        error to return if the parameter is missing.
+
+   E.6.5      IG0601    Further modified procedural text.
+
+   E.7.3      IG1100    Corrected text identifier for payphone
+                        recognition tone to avoid clash with base
+                        package.
+
+   E.10.5      IGDUB    Provided informative references for tones and
+                        procedures for continuity check.
+
+   E.13       GEN0202   Added note that TDM package could also apply
+                        to other transports.
+
+   E.13.1     IG1100    Changed default for echo cancellation from
+                        "on" to provisioned.
+
+   E.13.1     IG0601    Corrected type for gain property.
+
+   Appendix   TTPOST    Included a number of corrections which were
+      I                 not picked up in H.248.1 Amendment 1 but which
+                        do appear in H.248.1 v2.
+
+Intellectual Property Rights
+
+   The ITU draws attention to the possibility that the practice or
+   implementation of this RFC may involve the use of a claimed
+   Intellectual Property Right.  The ITU takes no position concerning
+   the evidence, validity or applicability of claimed Intellectual
+   Property Rights, whether asserted by ITU members or others outside of
+   the Recommendation development process.
+
+   As of the date of approval of this RFC, the ITU had received notice
+   of intellectual property, protected by patents, which may be required
+   to implement this RFC.  However, implementors are cautioned that this
+   may not represent the latest information and are therefore strongly
+   urged to consult the TSB patent database.
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 210]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   The IETF has also received notice of intellectual property claims
+   relating to Megaco/H.248.1.  Please consult the IETF IPR
+   announcements at http://www.ietf.org/ipr.html.
+
+Acknowledgments
+
+   Megaco/H.248.1 is the result of hard work by many people in both the
+   IETF and in ITU-T Study Group 16.  This section records those who
+   played a prominent role in ITU-T meetings, on the Megaco list, or
+   both.
+
+   Megaco/H.248 owes a large initial debt to the MGCP protocol (RFC
+   2705), and thus to its authors, Mauricio Arango, Andrew Dugan, Ike
+   Elliott, Christian Huitema, and Scott Pickett.  Flemming Andreasen
+   does not appear on this list of authors, but was a major contributor
+   to the development of both MGCP and Megaco/H.248.1.  RFC 3435 has an
+   extensive acknowledgement of many other people who worked on media
+   gateway control before Megaco got started.
+
+   The authors of the first Megaco RFCs (2805, then 3015) were Fernando
+   Cuervo, Nancy Greene, Abdallah Rayhan, Christian Huitema, Brian
+   Rosen, and John Segers.  Christian Groves conceived and was editor of
+   Annex C.  The people most active on the Megaco list in the period
+   leading up to the completion of RFC 2885 were Brian Rosen, Tom
+   Taylor, Nancy Greene, Christian Huitema, Matt Holdrege, Chip Sharp,
+   John Segers, Michael Thomas, Henry Sinnreich, and Paul Sijben.  The
+   people who sacrificed sleep and meals to complete the massive amount
+   of work required in the decisive Study Group 16 meeting of February,
+   2000, were Michael Brown, Ranga Dendi, Larry Forni, Glen Freundlich,
+   Christian Groves, Alf Heidemark, Steve Magnell, Selvam Rengasami,
+   Rich Rubin, Klaus Sambor, John Segers, Chip Sharp, Tom Taylor, and
+   Stephen Terrill.
+
+   The most active people on the Megaco list in the period since the
+   February 2000 have been Tom Taylor, Brian Rosen, Christian Groves,
+   Madhu Babu Brahmanapally, Troy Cauble, Terry Anderson, Chuong Nguyen,
+   and Kevin Boyle, but many other people have been regular
+   contributors.  Brian Rosen did tremendous service in putting together
+   the Megaco interoperability tests.  On the Study Group 16 side, the
+   editorial team for the final revised document in February, 2002
+   included Christian Groves, Marcello Pantaleo, Terry Anderson, Peter
+   Leis, Kevin Boyle, and Tom Taylor.
+
+   Tom Taylor as Megaco Chair managed the day to day operation of the
+   Megaco list, with Brian Rosen taking an equal share of the burden for
+   most of the last three years.  Glen Freundlich as the Study Group 16
+   Rapporteur ran the ITU-T meetings and ensured that all of the work at
+   hand was completed.  Without Glen's determination the Megaco/H.248
+
+
+
+Groves, et al.              Standards Track                   [Page 211]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+   standard would have taken at least half a year longer to produce.
+   Christian Groves filled in ably as Rapporteur when Glen could no
+   longer take part.
+
+Authors' Addresses
+
+   Terry L. Anderson
+   24 Hill St
+   Bernardsville, NJ 07924
+   USA
+
+   EMail: tlatla@verizon.net
+
+
+   Christian Groves
+   Ericsson AsiaPacificLab Australia
+   37/360 Elizabeth St
+   Melbourne, Victoria 3000
+   Australia
+
+   EMail: Christian.Groves@ericsson.com.au
+
+
+   Marcello Pantaleo
+   Ericsson Eurolab Deuschland
+   Ericsson Allee 1
+   52134 Herzogenrath, Germany
+
+   EMail: Marcello.Pantaleo@eed.ericsson.se
+
+
+   Tom Taylor
+   Nortel Networks
+   1852 Lorraine Ave,
+   Ottawa, Ontario
+   Canada K1H 6Z8
+
+   Phone: +1 613 736 0961
+   EMail: taylor@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 212]
+
+RFC 3525                Gateway Control Protocol               June 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves, et al.              Standards Track                   [Page 213]
+