aboutsummaryrefslogtreecommitdiffstats
path: root/lib/megaco/doc/standard/rfc3525.txt
diff options
context:
space:
mode:
Diffstat (limited to 'lib/megaco/doc/standard/rfc3525.txt')
-rw-r--r--lib/megaco/doc/standard/rfc3525.txt11931
1 files changed, 11931 insertions, 0 deletions
diff --git a/lib/megaco/doc/standard/rfc3525.txt b/lib/megaco/doc/standard/rfc3525.txt
new file mode 100644
index 0000000000..80663cc2cd
--- /dev/null
+++ b/lib/megaco/doc/standard/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: [email protected]
+
+
+ Christian Groves
+ Ericsson AsiaPacificLab Australia
+ 37/360 Elizabeth St
+ Melbourne, Victoria 3000
+ Australia
+
+ EMail: [email protected]
+
+
+ Marcello Pantaleo
+ Ericsson Eurolab Deuschland
+ Ericsson Allee 1
+ 52134 Herzogenrath, Germany
+
+ EMail: [email protected]
+
+
+ Tom Taylor
+ Nortel Networks
+ 1852 Lorraine Ave,
+ Ottawa, Ontario
+ Canada K1H 6Z8
+
+ Phone: +1 613 736 0961
+ EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-25 04:38:16 +0000