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