7 Network Working Group C. Groves
8 Request for Comments: 3525 M. Pantaleo
9 Obsoletes: 3015 LM Ericsson
10 Category: Standards Track T. Anderson
18 Gateway Control Protocol Version 1
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 Copyright (C) The Internet Society (2003). All Rights Reserved.
34 This document defines the protocol used between elements of a
35 physically decomposed multimedia gateway, i.e., a Media Gateway and a
36 Media Gateway Controller. The protocol presented in this document
37 meets the requirements for a media gateway control protocol as
38 presented in RFC 2805.
40 This document replaces RFC 3015. It is the result of continued
41 cooperation between the IETF Megaco Working Group and ITU-T Study
42 Group 16. It incorporates the original text of RFC 3015, modified by
43 corrections and clarifications discussed on the Megaco
44 E-mail list and incorporated into the Study Group 16 Implementor's
45 Guide for Recommendation H.248. The present version of this document
46 underwent ITU-T Last Call as Recommendation H.248 Amendment 1.
47 Because of ITU-T renumbering, it was published by the ITU-T as
48 Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.
50 Users of this specification are advised to consult the H.248 Sub-
51 series Implementors' Guide at http://www.itu.int/itudoc/itu-
52 t/com16/implgd for additional corrections and clarifications.
58 Groves, et al. Standards Track [Page 1]
60 RFC 3525 Gateway Control Protocol June 2003
63 Conventions used in this document
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
67 document are to be interpreted as described in RFC 2119 [RFC2119].
71 1 Scope.........................................................5
72 1.1 Changes From RFC 3015.....................................5
73 1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)...5
74 2 References....................................................6
75 2.1 Normative references......................................6
76 2.2 Informative references....................................9
77 3 Definitions..................................................10
78 4 Abbreviations................................................11
79 5 Conventions..................................................12
80 6 Connection model.............................................13
81 6.1 Contexts.................................................16
82 6.2 Terminations.............................................17
83 6.2.1 Termination dynamics.................................21
84 6.2.2 TerminationIDs.......................................21
85 6.2.3 Packages.............................................22
86 6.2.4 Termination properties and descriptors...............23
87 6.2.5 Root Termination.....................................25
88 7 Commands.....................................................26
89 7.1 Descriptors..............................................27
90 7.1.1 Specifying parameters................................27
91 7.1.2 Modem descriptor.....................................28
92 7.1.3 Multiplex descriptor.................................28
93 7.1.4 Media descriptor.....................................29
94 7.1.5 TerminationState descriptor..........................29
95 7.1.6 Stream descriptor....................................30
96 7.1.7 LocalControl descriptor..............................31
97 7.1.8 Local and Remote descriptors.........................32
98 7.1.9 Events descriptor....................................35
99 7.1.10 EventBuffer descriptor..............................38
100 7.1.11 Signals descriptor..................................38
101 7.1.12 Audit descriptor....................................40
102 7.1.13 ServiceChange descriptor............................41
103 7.1.14 DigitMap descriptor.................................41
104 7.1.15 Statistics descriptor...............................46
105 7.1.16 Packages descriptor.................................47
106 7.1.17 ObservedEvents descriptor...........................47
107 7.1.18 Topology descriptor.................................47
108 7.1.19 Error Descriptor....................................50
109 7.2 Command Application Programming Interface................50
110 7.2.1 Add..................................................51
114 Groves, et al. Standards Track [Page 2]
116 RFC 3525 Gateway Control Protocol June 2003
119 7.2.2 Modify...............................................52
120 7.2.3 Subtract.............................................53
121 7.2.4 Move.................................................55
122 7.2.5 AuditValue...........................................56
123 7.2.6 AuditCapabilities....................................59
124 7.2.7 Notify...............................................60
125 7.2.8 ServiceChange........................................61
126 7.2.9 Manipulating and Auditing Context Attributes.........65
127 7.2.10 Generic Command Syntax..............................66
128 7.3 Command Error Codes......................................66
129 8 Transactions.................................................66
130 8.1 Common parameters........................................68
131 8.1.1 Transaction Identifiers..............................68
132 8.1.2 Context Identifiers..................................68
133 8.2 Transaction Application Programming Interface............69
134 8.2.1 TransactionRequest...................................69
135 8.2.2 TransactionReply.....................................69
136 8.2.3 TransactionPending...................................71
137 8.3 Messages.................................................72
138 9 Transport....................................................72
139 9.1 Ordering of Commands.....................................73
140 9.2 Protection against Restart Avalanche.....................74
141 10 Security Considerations.....................................75
142 10.1 Protection of Protocol Connections......................75
143 10.2 Interim AH scheme.......................................76
144 10.3 Protection of Media Connections.........................77
145 11 MG-MGC Control Interface....................................78
146 11.1 Multiple Virtual MGs....................................78
147 11.2 Cold start..............................................79
148 11.3 Negotiation of protocol version.........................79
149 11.4 Failure of a MG.........................................80
150 11.5 Failure of an MGC.......................................81
151 12 Package definition..........................................82
152 12.1 Guidelines for defining packages........................82
153 12.1.1 Package.............................................83
154 12.1.2 Properties..........................................84
155 12.1.3 Events..............................................85
156 12.1.4 Signals.............................................85
157 12.1.5 Statistics..........................................86
158 12.1.6 Procedures..........................................86
159 12.2 Guidelines to defining Parameters to Events and Signals.86
160 12.3 Lists...................................................87
161 12.4 Identifiers.............................................87
162 12.5 Package registration....................................88
163 13 IANA Considerations.........................................88
164 13.1 Packages................................................88
165 13.2 Error codes.............................................89
166 13.3 ServiceChange reasons...................................89
170 Groves, et al. Standards Track [Page 3]
172 RFC 3525 Gateway Control Protocol June 2003
175 ANNEX A Binary encoding of the protocol.......................90
176 A.1 Coding of wildcards......................................90
177 A.2 ASN.1 syntax specification...............................92
178 A.3 Digit maps and path names...............................111
179 ANNEX B Text encoding of the protocol.........................113
180 B.1 Coding of wildcards.....................................113
181 B.2 ABNF specification......................................113
182 B.3 Hexadecimal octet coding................................127
183 B.4 Hexadecimal octet sequence..............................127
184 ANNEX C Tags for media stream properties......................128
185 C.1 General media attributes................................128
186 C.2 Mux properties..........................................130
187 C.3 General bearer properties...............................130
188 C.4 General ATM properties..................................130
189 C.5 Frame Relay.............................................134
190 C.6 IP......................................................134
191 C.7 ATM AAL2................................................134
192 C.8 ATM AAL1................................................136
193 C.9 Bearer capabilities.....................................137
194 C.10 AAL5 properties........................................147
195 C.11 SDP equivalents........................................148
196 C.12 H.245..................................................149
197 ANNEX D Transport over IP.....................................150
198 D.1 Transport over IP/UDP using Application Level Framing ..150
199 D.1.1 Providing At-Most-Once functionality................150
200 D.1.2 Transaction identifiers and three-way handshake.....151
201 D.1.3 Computing retransmission timers.....................152
202 D.1.4 Provisional responses...............................153
203 D.1.5 Repeating Requests, Responses and Acknowledgements..153
204 D.2 Using TCP...............................................155
205 D.2.1 Providing the At-Most-Once functionality............155
206 D.2.2 Transaction identifiers and three-way handshake.....155
207 D.2.3 Computing retransmission timers.....................156
208 D.2.4 Provisional responses...............................156
209 D.2.5 Ordering of commands................................156
210 ANNEX E Basic packages.......................................157
211 E.1 Generic.................................................157
212 E.2 Base Root Package.......................................159
213 E.3 Tone Generator Package..................................161
214 E.4 Tone Detection Package..................................163
215 E.5 Basic DTMF Generator Package............................166
216 E.6 DTMF detection Package..................................167
217 E.7 Call Progress Tones Generator Package...................169
218 E.8 Call Progress Tones Detection Package...................171
219 E.9 Analog Line Supervision Package.........................172
220 E.10 Basic Continuity Package...............................175
221 E.11 Network Package........................................178
222 E.12 RTP Package............................................180
226 Groves, et al. Standards Track [Page 4]
228 RFC 3525 Gateway Control Protocol June 2003
231 E.13 TDM Circuit Package....................................182
232 APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE)...................184
233 A.1 Residential Gateway to Residential Gateway Call.........184
234 A.1.1 Programming Residential GW Analog Line Terminations
235 for Idle Behavior...................................184
236 A.1.2 Collecting Originator Digits and Initiating
237 Termination.........................................186
238 APPENDIX II Changes From RFC 3015............................195
239 Intellectual Property Rights..................................210
240 Acknowledgments...............................................211
241 Authors' Addresses............................................212
242 Full Copyright Statement......................................213
246 The present document, which is identical to the published version of
247 ITU-T Recommendation H.248.1 (03/2002) except as noted below, defines
248 the protocols used between elements of a physically decomposed
249 multimedia gateway. There are no functional differences from a
250 system view between a decomposed gateway, with distributed sub-
251 components potentially on more than one physical device, and a
252 monolithic gateway such as described in ITU-T Recommendation H.246.
253 This document does not define how gateways, multipoint control units
254 or interactive voice response units (IVRs) work. Instead it creates
255 a general framework that is suitable for these applications.
257 Packet network interfaces may include IP, ATM or possibly others.
258 The interfaces will support a variety of Switched Circuit Network
259 (SCN) signalling systems, including tone signalling, ISDN, ISUP, QSIG
260 and GSM. National variants of these signalling systems will be
261 supported where applicable.
263 1.1 Changes From RFC 3015
265 The differences between this document and RFC 3015 are documented in
268 1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)
270 This document differs from the corresponding ITU-T publication in the
273 - Added IETF front matter in place of the corresponding ITU-T
276 - The ITU-T summary is too H.323-specific and has been omitted.
282 Groves, et al. Standards Track [Page 5]
284 RFC 3525 Gateway Control Protocol June 2003
287 - The IETF conventions have been stated as governing this document.
288 As discussed in section 5 below, this gives slightly greater
289 strength to "should" requirements.
291 - The Scope section (just above) has been edited slightly to suit
294 - Added normative references to RFCs 2026 and 2119.
296 - Figures 4, 5, and 6 show the centre of the context for greater
297 clarity. Also added Figure 6a showing an important additional
300 - Added a paragraph in section 7.1.18 which was approved in the
301 Implementor's Guide but lost inadvertently in the ITU-T approved
304 - This document incorporates corrections to the informative examples
305 in Appendix I which also appear in H.248.1 version 2, but which
306 were not picked up in H.248.1 (03/2002).
308 - This document includes a new Appendix II listing all the changes
311 - This document includes an Acknowledgements section listing the
312 authors of RFC 3015 but also many other people who contributed to
313 the development of the Megaco/H.248.x protocol.
315 - Moved the Intellectual Property declaration to its usual place in
316 an IETF document and added a reference to declarations on the IETF
321 The following ITU-T Recommendations and other references contain
322 provisions which, through reference in this text, constitute
323 provisions of this RFC. At the time of publication, the editions
324 indicated were valid. All Recommendations and other references are
325 subject to revision; all users of this RFC are therefore encouraged
326 to investigate the possibility of applying the most recent edition of
327 the Recommendations and other references listed below. A list of the
328 currently valid ITU-T Recommendations is regularly published.
330 2.1 Normative references
332 - ITU-T Recommendation H.225.0 (1999), Call signalling protocols and
333 media stream packetization for packet-based multimedia
334 communication systems.
338 Groves, et al. Standards Track [Page 6]
340 RFC 3525 Gateway Control Protocol June 2003
343 - ITU-T Recommendation H.235 (1998), Security and encryption for
344 H-Series (H.323 and other H.245-based) multimedia terminals.
346 - ITU-T Recommendation H.245 (1998), Control protocol for multimedia
349 - ITU-T Recommendation H.246 (1998), Interworking of H-series
350 multimedia terminals with H-series multimedia terminals and
351 voice/voiceband terminals on GSTN and ISDN.
353 - ITU-T Recommendation H.248.8 (2002), H.248 Error Codes and Service
356 - ITU-T Recommendation H.323 (1999), Packet-based multimedia
357 communication systems.
359 - ITU-T Recommendation I.363.1 (1996), B-ISDN ATM adaptation layer
360 (AAL) specification: Type 1 AAL.
362 - ITU-T Recommendation I.363.2 (1997), B-ISDN ATM adaptation layer
363 (AAL) specification: Type 2 AAL.
365 - ITU-T Recommendation I.363.5 (1996), B-ISDN ATM adaptation layer
366 (AAL) specification: Type 5 AAL.
368 - ITU-T Recommendation I.366.1 (1998), Segmentation and Reassembly
369 Service Specific Convergence Sublayer for the AAL type 2.
371 - ITU-T Recommendation I.366.2 (1999), AAL type 2 service specific
372 convergence sublayer for trunking.
374 - ITU-T Recommendation I.371 (2000), Traffic control and congestion
377 - ITU-T Recommendation Q.763 (1999), Signalling System No. 7 - ISDN
378 user part formats and codes.
380 - ITU-T Recommendation Q.765.5 (2001), Application transport
381 mechanism - Bearer independent call control (BICC).
383 - ITU-T Recommendation Q.931 (1998), ISDN user-network interface
384 layer 3 specification for basic call control.
386 - ITU-T Recommendation Q.2630.1 (1999), AAL type 2 signalling
387 protocol (Capability Set 1).
394 Groves, et al. Standards Track [Page 7]
396 RFC 3525 Gateway Control Protocol June 2003
399 - ITU-T Recommendation Q.2931 (1995), Digital Subscriber Signalling
400 System No. 2 (DSS2) - User-Network Interface (UNI) - Layer 3
401 specification for basic call/connection control.
403 - ITU-T Recommendation Q.2941.1 (1997), Digital Subscriber
404 Signalling System No. 2 - Generic identifier transport.
406 - ITU-T Recommendation Q.2961.1 (1995), Additional signalling
407 capabilities to support traffic parameters for the tagging option
408 and the sustainable call rate parameter set.
410 - ITU-T Recommendation Q.2961.2 (1997), Additional traffic
411 parameters: Support of ATM transfer capability in the broadband
412 bearer capability information element.
414 - ITU-T Recommendation Q.2965.1 (1999), Digital subscriber
415 signalling system No. 2 - Support of Quality of Service classes.
417 - ITU-T Recommendation Q.2965.2 (1999), Digital subscriber
418 signalling system No. 2 - Signalling of individual Quality of
421 - ITU-T Recommendation V.76 (1996), Generic multiplexer using V.42
422 LAPM-based procedures.
424 - ITU-T Recommendation X.213 (1995), Information technology - Open
425 Systems Interconnection - Network service definition plus
426 Amendment 1 (1997), Addition of the Internet protocol address
429 - ITU-T Recommendation X.680 (1997), Information technology -
430 Abstract Syntax Notation One (ASN.1): Specification of basic
433 - ITU-T Recommendation X.690 (1997), Information Technology - ASN.1
434 Encoding Rules: Specification of Basic Encoding Rules (BER),
435 Canonical Encoding Rules (CER) and Distinguished Encoding Rules
438 - ATM Forum (1996), ATM User-Network Interface (UNI) Signalling
439 Specification - Version 4.0.
441 [RFC 1006] Rose, M. and D. Cass, "ISO Transport Service on top of the
442 TCP, Version 3", STD 35, RFC 1006, May 1987.
444 [RFC 2026] Brander, S., "The Internet Standards Process -- Revision
445 3", BCP 9, RFC 2026, October 1996.
450 Groves, et al. Standards Track [Page 8]
452 RFC 3525 Gateway Control Protocol June 2003
455 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
456 Requirement Levels", BCP 14, RFC 2119, March 1997.
458 [RFC 2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
459 Specifications: ABNF", RFC 2234, November 1997.
461 [RFC 2327] Handley, M. and V. Jacobson, "SDP: Session Description
462 Protocol", RFC 2327, April 1998.
464 [RFC 2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
467 [RFC 2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
468 Payload (ESP)", RFC 2406, November 1998.
470 2.2 Informative references
472 - ITU-T Recommendation E.180/Q.35 (1998), Technical characteristics
473 of tones for the telephone service.
475 - CCITT Recommendation G.711 (1988), Pulse Code Modulation (PCM) of
478 - ITU-T Recommendation H.221 (1999), Frame structure for a 64 to
479 1920 kbit/s channel in audiovisual teleservices.
481 - ITU T Recommendation H.223 (1996), Multiplexing protocol for low
482 bit rate multimedia communication.
484 - ITU-T Recommendation H.226 (1998), Channel aggregation protocol
485 for multilink operation on circuit-switched networks
487 - ITU-T Recommendation Q.724 (1998), Signalling procedures.
489 - ITU-T Recommendation Q.764 (1999), Signalling system No. 7 - ISDN
490 user part signalling procedures.
492 - ITU-T Recommendation Q.1902.4 (2001), Bearer independent call
493 control protocol - Basic call procedures.
495 [RFC 768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
498 [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
501 [RFC 793] Postel, J., "Transmission Control Protocol", STD 7, RFC
506 Groves, et al. Standards Track [Page 9]
508 RFC 3525 Gateway Control Protocol June 2003
511 [RFC 1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
512 51, RFC 1661, July 1994.
514 [RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
515 Jacobson, "RTP: A Transport Protocol for Real-Time
516 Applications", RFC 1889, January 1996.
518 [RFC 1890] Schulzrinne, H. and G. Fokus, "RTP Profile for Audio and
519 Video Conferences with Minimal Control", RFC 1890,
522 [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the
523 Internet Protocol", RFC 2401, November 1998.
525 [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
526 (IPv6) Specification", RFC 2460, December 1998.
528 [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
529 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
532 [RFC 2805] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway
533 Control Protocol Architecture and Requirements", RFC 2805,
538 This document defines the following terms:
541 A type of gateway that provides a User-Network Interface (UNI) such
545 A syntactic element of the protocol that groups related properties.
546 For instance, the properties of a media flow on the MG can be set by
547 the MGC by including the appropriate descriptor in a command.
550 The media gateway converts media provided in one type of network to
551 the format required in another type of network. For example, a MG
552 could terminate bearer channels from a switched circuit network
553 (e.g., DS0s) and media streams from a packet network (e.g., RTP
554 streams in an IP network). This gateway may be capable of processing
555 audio, video and T.120 alone or in any combination, and will be
556 capable of full duplex media translations. The MG may also play
557 audio/video messages and perform other IVR functions, or may perform
562 Groves, et al. Standards Track [Page 10]
564 RFC 3525 Gateway Control Protocol June 2003
567 Media Gateway Controller (MGC):
568 Controls the parts of the call state that pertain to connection
569 control for media channels in a MG.
571 Multipoint Control Unit (MCU):
572 An entity that controls the setup and coordination of a multi-user
573 conference that typically includes processing of audio, video and
577 A gateway that interworks an analogue line to a packet network. A
578 residential gateway typically contains one or two analogue lines and
579 is located at the customer premises.
581 SCN FAS signalling gateway:
582 This function contains the SCN Signalling Interface that terminates
583 SS7, ISDN or other signalling links where the call control channel
584 and bearer channels are collocated in the same physical span.
586 SCN NFAS signalling gateway:
587 This function contains the SCN Signalling Interface that terminates
588 SS7 or other signalling links where the call control channels are
589 separated from bearer channels.
592 Bidirectional media or control flow received/sent by a media gateway
593 as part of a call or conference.
596 A communication channel between two switching systems such as a DS0
600 A gateway between SCN network and packet network that typically
601 terminates a large number of digital circuits.
605 This RFC document uses the following abbreviations:
607 ALF Application Layer Framing
609 ATM Asynchronous Transfer Mode
611 CAS Channel Associated Signalling
613 DTMF Dual Tone Multi-Frequency
618 Groves, et al. Standards Track [Page 11]
620 RFC 3525 Gateway Control Protocol June 2003
623 FAS Facility Associated Signalling
625 GSM Global System for Mobile communications
629 IANA Internet Assigned Numbers Authority (superseded by Internet
630 Corporation for Assigned Names and Numbers - ICANN)
636 IVR Interactive Voice Response
640 MGC Media Gateway Controller
642 NFAS Non-Facility Associated Signalling
644 PRI Primary Rate Interface
646 PSTN Public Switched Telephone Network
648 QoS Quality of Service
650 RTP Real-time Transport Protocol
652 SCN Switched Circuit Network
654 SG Signalling Gateway
656 SS7 Signalling System No. 7
660 In the H.248.1 Recommendation, "SHALL" refers to a mandatory
661 requirement, while "SHOULD" refers to a suggested but optional
662 feature or procedure. The term "MAY" refers to an optional course of
663 action without expressing a preference. Note that these definition
664 are overridden in the present document by the RFC 2119 conventions
665 stated at the beginning of this document. RFC 2119 has a more
666 precise definition of "should" than is provided by the ITU-T.
674 Groves, et al. Standards Track [Page 12]
676 RFC 3525 Gateway Control Protocol June 2003
681 The connection model for the protocol describes the logical entities,
682 or objects, within the Media Gateway that can be controlled by the
683 Media Gateway Controller. The main abstractions used in the
684 connection model are Terminations and Contexts.
686 A Termination sources and/or sinks one or more streams. In a
687 multimedia conference, a Termination can be multimedia and sources or
688 sinks multiple media streams. The media stream parameters, as well
689 as modem, and bearer parameters are encapsulated within the
692 A Context is an association between a collection of Terminations.
693 There is a special type of Context, the null Context, which contains
694 all Terminations that are not associated to any other Termination.
695 For instance, in a decomposed access gateway, all idle lines are
696 represented by Terminations in the null Context.
698 Following is a graphical depiction of these concepts. The diagram of
699 Figure 1 gives several examples and is not meant to be an
700 all-inclusive illustration. The asterisk box in each of the Contexts
701 represents the logical association of Terminations implied by the
730 Groves, et al. Standards Track [Page 13]
732 RFC 3525 Gateway Control Protocol June 2003
735 +------------------------------------------------------+
737 | +-------------------------------------------------+ |
738 | |Context +-------------+ | |
739 | | | Termination | | |
740 | | |-------------| | |
741 | | +-------------+ +->| SCN Bearer |<---+->
742 | | | Termination | +-----+ | | Channel | | |
743 | | |-------------| | |---+ +-------------+ | |
744 <-+--->| RTP Stream |---| * | | |
745 | | | | | |---+ +-------------+ | |
746 | | +-------------+ +-----+ | | Termination | | |
747 | | | |-------------| | |
748 | | +->| SCN Bearer |<---+->
750 | | +-------------+ | |
751 | +-------------------------------------------------+ |
754 | +------------------------------+ |
755 | (NULL Context) |Context | |
756 | +-------------+ | +-------------+ | |
757 | | Termination | | +-----+ | Termination | | |
758 | |-------------| | | | |-------------| | |
759 | | SCN Bearer | | | * |------| SCN Bearer |<---+->
760 | | Channel | | | | | Channel | | |
761 | +-------------+ | +-----+ +-------------+ | |
762 | +------------------------------+ |
765 | +-------------------------------------------------+ |
767 | | +-------------+ +-------------+ | |
768 | | | Termination | +-----+ | Termination | | |
769 | | |-------------| | | |-------------| | |
770 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
771 | | | Channel | | | | Channel | | |
772 | | +-------------+ +-----+ +-------------+ | |
773 | +-------------------------------------------------+ |
774 | ___________________________________________________ |
775 +------------------------------------------------------+
777 Figure 1: Examples of Megaco/H.248 Connection Model
786 Groves, et al. Standards Track [Page 14]
788 RFC 3525 Gateway Control Protocol June 2003
791 The example in Figure 2 shows an example of one way to accomplish a
792 call-waiting scenario in a decomposed access gateway, illustrating
793 the relocation of a Termination between Contexts. Terminations T1
794 and T2 belong to Context C1 in a two-way audio call. A second audio
795 call is waiting for T1 from Termination T3. T3 is alone in Context
796 C2. T1 accepts the call from T3, placing T2 on hold. This action
797 results in T1 moving into Context C2, as shown in Figure 3.
799 +------------------------------------------------------+
801 | +-------------------------------------------------+ |
803 | | +-------------+ +-------------+ | |
804 | | | Term. T2 | +-----+ | Term. T1 | | |
805 | | |-------------| | | |-------------| | |
806 <-+--->| RTP Stream |---| * |------| SCN Bearer |<---+->
807 | | | | | | | Channel | | |
808 | | +-------------+ +-----+ +-------------+ | |
809 | +-------------------------------------------------+ |
811 | +-------------------------------------------------+ |
813 | | +-------------+ | |
814 | | +-----+ | Term. T3 | | |
815 | | | | |-------------| | |
816 | | | * |------| SCN Bearer |<---+->
817 | | | | | Channel | | |
818 | | +-----+ +-------------+ | |
819 | +-------------------------------------------------+ |
820 +------------------------------------------------------+
822 Figure 2: Example Call Waiting Scenario / Alerting Applied to T1
842 Groves, et al. Standards Track [Page 15]
844 RFC 3525 Gateway Control Protocol June 2003
847 +------------------------------------------------------+
849 | +-------------------------------------------------+ |
851 | | +-------------+ | |
852 | | | Term. T2 | +-----+ | |
853 | | |-------------| | | | |
854 <-+--->| RTP Stream |---| * | | |
856 | | +-------------+ +-----+ | |
857 | +-------------------------------------------------+ |
859 | +-------------------------------------------------+ |
861 | | +-------------+ +-------------+ | |
862 | | | Term. T1 | +-----+ | Term. T3 | | |
863 | | |-------------| | | |-------------| | |
864 <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
865 | | | Channel | | | | Channel | | |
866 | | +-------------+ +-----+ +-------------+ | |
867 | +-------------------------------------------------+ |
868 +------------------------------------------------------+
870 Figure 3. Example Call Waiting Scenario / Answer by T1
874 A Context is an association between a number of Terminations. The
875 Context describes the topology (who hears/sees whom) and the media
876 mixing and/or switching parameters if more than two Terminations are
877 involved in the association.
879 There is a special Context called the null Context. It contains
880 Terminations that are not associated to any other Termination.
881 Terminations in the null Context can have their parameters examined
882 or modified, and may have events detected on them.
884 In general, an Add command is used to add Terminations to Contexts.
885 If the MGC does not specify an existing Context to which the
886 Termination is to be added, the MG creates a new Context. A
887 Termination may be removed from a Context with a Subtract command,
888 and a Termination may be moved from one Context to another with a
889 Move command. A Termination SHALL exist in only one Context at a
898 Groves, et al. Standards Track [Page 16]
900 RFC 3525 Gateway Control Protocol June 2003
903 The maximum number of Terminations in a Context is a MG property.
904 Media gateways that offer only point-to-point connectivity might
905 allow at most two Terminations per Context. Media gateways that
906 support multipoint conferences might allow three or more Terminations
909 6.1.1 Context attributes and descriptors
911 The attributes of Contexts are:
915 - The topology (who hears/sees whom).
917 The topology of a Context describes the flow of media between the
918 Terminations within a Context. In contrast, the mode of a
919 Termination (send/receive/...) describes the flow of the media at
920 the ingress/egress of the media gateway.
922 - The priority is used for a Context in order to provide the MG with
923 information about a certain precedence handling for a Context.
924 The MGC can also use the priority to control autonomously the
925 traffic precedence in the MG in a smooth way in certain
926 situations (e.g., restart), when a lot of Contexts must be handled
927 simultaneously. Priority 0 is the lowest priority and a priority
928 of 15 is the highest priority.
930 - An indicator for an emergency call is also provided to allow a
931 preference handling in the MG.
933 6.1.2 Creating, deleting and modifying Contexts
935 The protocol can be used to (implicitly) create Contexts and modify
936 the parameter values of existing Contexts. The protocol has commands
937 to add Terminations to Contexts, subtract them from Contexts, and to
938 move Terminations between Contexts. Contexts are deleted implicitly
939 when the last remaining Termination is subtracted or moved out.
943 A Termination is a logical entity on a MG that sources and/or sinks
944 media and/or control streams. A Termination is described by a number
945 of characterizing Properties, which are grouped in a set of
946 Descriptors that are included in commands. Terminations have unique
947 identities (TerminationIDs), assigned by the MG at the time of their
954 Groves, et al. Standards Track [Page 17]
956 RFC 3525 Gateway Control Protocol June 2003
959 Terminations representing physical entities have a semi-permanent
960 existence. For example, a Termination representing a TDM channel
961 might exist for as long as it is provisioned in the gateway.
962 Terminations representing ephemeral information flows, such as RTP
963 flows, would usually exist only for the duration of their use.
965 Ephemeral Terminations are created by means of an Add command. They
966 are destroyed by means of a Subtract command. In contrast, when a
967 physical Termination is Added to or Subtracted from a Context, it is
968 taken from or to the null Context, respectively.
970 Terminations may have signals applied to them (see 7.1.11).
971 Terminations may be programmed to detect Events, the occurrence of
972 which can trigger notification messages to the MGC, or action by the
973 MG. Statistics may be accumulated on a Termination. Statistics are
974 reported to the MGC upon request (by means of the AuditValue command,
975 see 7.2.5) and when the Termination is taken out of the call it is
978 Multimedia gateways may process multiplexed media streams. For
979 example, Recommendation H.221 describes a frame structure for
980 multiple media streams multiplexed on a number of digital 64 kbit/s
981 channels. Such a case is handled in the connection model in the
982 following way. For every bearer channel that carries part of the
983 multiplexed streams, there is a physical or ephemeral "bearer
984 Termination". The bearer Terminations that source/sink the digital
985 channels are connected to a separate Termination called the
986 "multiplexing Termination". The multiplexing termination is an
987 ephemeral termination representing a frame-oriented session. The
988 MultiplexDescriptor for this Termination describes the multiplex used
989 (e.g., H.221 for an H.320 session) and indicates the order in which
990 the contained digital channels are assembled into a frame.
992 Multiplexing terminations may be cascades (e.g., H.226 multiplex of
993 digital channels feeding into a H.223 multiplex supporting an H.324
996 The individual media streams carried in the session are described by
997 StreamDescriptors on the multiplexing Termination. These media
998 streams can be associated with streams sourced/sunk by Terminations
999 in the Context other than the bearer Terminations supporting the
1000 multiplexing Termination. Each bearer Termination supports only a
1001 single data stream. These data streams do not appear explicitly as
1002 streams on the multiplexing Termination and they are hidden from the
1003 rest of the context.
1005 Figures 4, 5, 6, and 6a illustrate typical applications of the
1006 multiplexing termination and Multiplex Descriptor.
1010 Groves, et al. Standards Track [Page 18]
1012 RFC 3525 Gateway Control Protocol June 2003
1015 +-----------------------------------+
1016 | Context +-------+ |
1018 Circuit 1 -|--| TC1|---------+ Tmux | |
1019 | +----+ (Str 1) | | Audio +-----+
1020 | | | +-----*-----+ |-----
1021 | +----+ | H.22x | Stream 1 | |
1022 Circuit 2 -|--| TC2|---------+ multi-| | TR1 |
1023 | +----+ (Str 1) | plex | |(RTP)|
1025 | +----+ | +-----*-----+ |-----
1026 Circuit 3 -|--| TC3|---------+ | Stream 2 | |
1027 / +----+ (Str 1) | | +-----+
1029 / +-----------------\-----------------+
1030 Audio, video, and control \
1031 signals are carried in frames Tmux is an ephemeral with two
1032 spanning the circuits. explicit Stream Descriptors
1033 and a Multiplex Descriptor.
1035 Figure 4: Multiplexed Termination Scenario - Circuit to Packet
1036 (Asterisks * denote the centre of the context)
1039 +--------------------------------------+
1040 | +-------+ +-------+ |
1041 +----+ | | | | +----+
1042 Circuit 1 ----| TC1|---+ Tmux1 | Audio | Tmux2 +---| TC4|---
1043 +----+ | +---*----+ | +----+
1045 +----+ | H.22x | | H.22x | +----+
1046 Circuit 2 ----| TC2|---+ multi-| | multi-+---| TC5|---
1047 +----+ | plex | | plex | +----+
1049 +----+ | +---*----+ | +----+
1050 Circuit 3 ----| TC3|---+ | Str 2 | +---| TC6|---
1051 +----+ | | | | +----+
1052 | +-------+ +-------+ |
1053 +-----------------\-----/--------------+
1055 Tmux1 and Tmux2 are ephemerals each with two
1056 explicit Stream Descriptors and a Multiplex Descriptor.
1058 Figure 5: Multiplexed Termination Scenario - Circuit to Circuit
1059 (Asterisks * denote the centre of the context)
1066 Groves, et al. Standards Track [Page 19]
1068 RFC 3525 Gateway Control Protocol June 2003
1071 +-----------------------------------+
1072 | Context +-------+ |
1074 Circuit 1 -|--| TC1|---------+ Tmux | |
1075 | +----+ (Str 1) | | Audio +-----+
1076 | | | +-----*-----+ TR1 |-----
1077 | +----+ | H.22x | Stream 1 |(RTP)|
1078 Circuit 2 -|--| TC2|---------+ multi-| +-----+
1079 | +----+ (Str 1) | plex | |
1080 | | | | Video +-----+
1081 | +----+ | +-----*-----+ TR2 |-----
1082 Circuit 3 -|--| TC3|---------+ | Stream 2 |(RTP)|
1083 / +----+ (Str 1) | | +-----+
1085 / +-----------------\-----------------+
1086 Audio, video, and control \ Tmux is an ephemeral with two
1087 signals are carried in frames explicit Stream Descriptors and
1088 spanning the circuits. and a Multiplex Descriptor.
1090 Figure 6: Multiplexed Termination Scenario - Single to Multiple
1092 (Asterisks * denote the centre of the context)
1095 +---------------------------------------------+
1096 | +-------+ +-------+ |
1097 Cct 1 +----+ | | | | Audio +-----+
1098 ----| TC1|---+ Tmux1 | | Tmux2 +-----*-----| TR1 |-----
1099 +----+ | | | | Stream 1 |(RTP)|
1100 | | | Data | | +-----+
1101 Cct 2 +----+ | H.226 +-------+ H.223 | |
1102 ----| TC2|---+ multi-|(Str 1)| multi-| Control +-----+
1103 +----+ | plex | | plex +-----*-----+ Tctl|-----
1104 | | | | | Stream 3 +-----+
1105 Cct 3 +----+ | | | | |
1106 ----| TC3|---+ | | | +-----+
1107 +----+ | | | +-----*-----+ TR2 |-----
1108 | +-------+ | | Video |(RTP)|
1109 | +-------+ Stream 2 +-----+
1111 +---------------------------------------------+
1112 Tmux1 has a Multiplex Descriptor and a single data stream.
1113 Tmux2 has a Multiplex Descriptor with a single bearer and
1114 three explicit Stream Descriptors.
1116 Figure 6a: Multiplexed Termination Scenario - Cascaded Multiplexes
1117 (Asterisks * denote the centre of the context)
1118 Note: this figure does not appear in Rec. H.248.1
1122 Groves, et al. Standards Track [Page 20]
1124 RFC 3525 Gateway Control Protocol June 2003
1127 Terminations may be created which represent multiplexed bearers, such
1128 as an ATM AAL Type 2 bearer. When a new multiplexed bearer is to be
1129 created, an ephemeral Termination is created in a Context established
1130 for this purpose. When the Termination is subtracted, the
1131 multiplexed bearer is destroyed.
1133 6.2.1 Termination dynamics
1135 The protocol can be used to create new Terminations and to modify
1136 property values of existing Terminations. These modifications
1137 include the possibility of adding or removing events and/or signals.
1138 The Termination properties, and events and signals are described in
1139 the ensuing subclauses. An MGC can only release/modify Terminations
1140 and the resources that the Termination represents which it has
1141 previously seized via, e.g., the Add command.
1143 6.2.2 TerminationIDs
1145 Terminations are referenced by a TerminationID, which is an arbitrary
1146 schema chosen by the MG.
1148 TerminationIDs of physical Terminations are provisioned in the Media
1149 Gateway. The TerminationIDs may be chosen to have structure. For
1150 instance, a TerminationID may consist of trunk group and a trunk
1153 A wildcarding mechanism using two types of wildcards can be used with
1154 TerminationIDs. The two wildcards are ALL and CHOOSE. The former is
1155 used to address multiple Terminations at once, while the latter is
1156 used to indicate to a media gateway that it must select a Termination
1157 satisfying the partially specified TerminationID. This allows, for
1158 instance, that a MGC instructs a MG to choose a circuit within a
1161 When ALL is used in the TerminationID of a command, the effect is
1162 identical to repeating the command with each of the matching
1163 TerminationIDs. The use of ALL does not address the ROOT
1164 termination. Since each of these commands may generate a response,
1165 the size of the entire response may be large. If individual
1166 responses are not required, a wildcard response may be requested. In
1167 such a case, a single response is generated, which contains the UNION
1168 of all of the individual responses which otherwise would have been
1169 generated, with duplicate values suppressed. For instance, given a
1170 Termination Ta with properties p1=a, p2=b and Termination Tb with
1178 Groves, et al. Standards Track [Page 21]
1180 RFC 3525 Gateway Control Protocol June 2003
1183 properties p2=c, p3=d, a UNION response would consist of a wildcarded
1184 TerminationId and the sequence of properties p1=a, p2=b,c and p3=d.
1185 Wildcard response may be particularly useful in the Audit commands.
1187 The encoding of the wildcarding mechanism is detailed in Annexes A
1192 Different types of gateways may implement Terminations that have
1193 widely differing characteristics. Variations in Terminations are
1194 accommodated in the protocol by allowing Terminations to have
1195 optional Properties, Events, Signals and Statistics implemented by
1198 In order to achieve MG/MGC interoperability, such options are grouped
1199 into Packages, and typically a Termination realizes a set of such
1200 Packages. More information on definition of packages can be found in
1201 clause 12. An MGC can audit a Termination to determine which
1202 Packages it realizes.
1204 Properties, Events, Signals and Statistics defined in Packages, as
1205 well as parameters to them, are referenced by identifiers (Ids).
1206 Identifiers are scoped. For each package, PropertyIds, EventIds,
1207 SignalIds, StatisticsIds and ParameterIds have unique name spaces and
1208 the same identifier may be used in each of them. Two PropertyIds in
1209 different packages may also have the same identifier, etc.
1211 To support a particular package the MG must support all properties,
1212 signals, events and statistics defined in a package. It must also
1213 support all Signal and Event parameters. The MG may support a subset
1214 of the values listed in a package for a particular Property or
1217 When packages are extended, the properties, events, signals and
1218 statistics defined in the base package can be referred to using
1219 either the extended package name or the base package name. For
1220 example, if Package A defines event e1, and Package B extends Package
1221 A, then B/e1 is an event for a termination implementing Package B. By
1222 definition, the MG MUST also implement the base Package, but it is
1223 optional to publish the base package as an allowed interface. If it
1224 does publish A, then A would be reported on the Package Descriptor
1225 in AuditValue as well as B, and event A/e1 would be available on a
1226 termination. If the MG does not publish A, then only B/e1 would be
1227 available. If published through AuditValue, A/e1 and B/e1 are the
1234 Groves, et al. Standards Track [Page 22]
1236 RFC 3525 Gateway Control Protocol June 2003
1239 For improved interoperability and backward compatibility, an MG MAY
1240 publish all Packages supported by its Terminations, including base
1241 Packages from which extended Packages are derived. An exception to
1242 this is in cases where the base packages are expressly "Designed to
1245 6.2.4 Termination properties and descriptors
1247 Terminations have properties. The properties have unique
1248 PropertyIDs. Most properties have default values, which are
1249 explicitly defined in this protocol specification or in a package
1250 (see clause 12) or set by provisioning. If not provisioned
1251 otherwise, the properties in all descriptors except TerminationState
1252 and LocalControl default to empty/"no value" when a Termination is
1253 first created or returned to the null Context. The default contents
1254 of the two exceptions are described in 7.1.5 and 7.1.7.
1256 The provisioning of a property value in the MG will override any
1257 default value, be it supplied in this protocol specification or in a
1258 package. Therefore if it is essential for the MGC to have full
1259 control over the property values of a Termination, it should supply
1260 explicit values when ADDing the Termination to a Context.
1261 Alternatively, for a physical Termination the MGC can determine any
1262 provisioned property values by auditing the Termination while it is
1263 in the NULL Context.
1265 There are a number of common properties for Terminations and
1266 properties specific to media streams. The common properties are also
1267 called the Termination state properties. For each media stream,
1268 there are local properties and properties of the received and
1271 Properties not included in the base protocol are defined in Packages.
1272 These properties are referred to by a name consisting of the
1273 PackageName and a PropertyId. Most properties have default values
1274 described in the Package description. Properties may be read-only or
1275 read/write. The possible values of a property may be audited, as can
1276 their current values. For properties that are read/write, the MGC
1277 can set their values. A property may be declared as "Global" which
1278 has a single value shared by all Terminations realizing the package.
1279 Related properties are grouped into descriptors for convenience.
1281 When a Termination is added to a Context, the value of its read/write
1282 properties can be set by including the appropriate descriptors as
1283 parameters to the Add command. Similarly, a property of a
1284 Termination in a Context may have its value changed by the Modify
1290 Groves, et al. Standards Track [Page 23]
1292 RFC 3525 Gateway Control Protocol June 2003
1295 Properties may also have their values changed when a Termination is
1296 moved from one Context to another as a result of a Move command. In
1297 some cases, descriptors are returned as output from a command.
1299 In general, if a Descriptor is completely omitted from one of the
1300 aforementioned Commands, the properties in that Descriptor retain
1301 their prior values for the Termination(s) upon which the Command
1302 acts. On the other hand, if some read/write properties are omitted
1303 from a Descriptor in a Command (i.e., the Descriptor is only
1304 partially specified), those properties will be reset to their default
1305 values for the Termination(s) upon which the Command acts, unless the
1306 package specifies other behavior. For more details, see clause 7.1
1307 dealing with the individual Descriptors.
1309 The following table lists all of the possible descriptors and their
1310 use. Not all descriptors are legal as input or output parameters to
1313 Descriptor name Description
1315 Modem Identifies modem type and properties when
1318 Mux Describes multiplex type for multimedia
1319 Terminations (e.g., H.221, H.223, H.225.0) and
1320 Terminations forming the input mux
1322 Media A list of media stream specifications (see 7.1.4)
1324 TerminationState Properties of a Termination (which can be defined
1325 in Packages) that are not stream specific
1327 Stream A list of remote/local/localControl descriptors for
1330 Local Contains properties that specify the media flows
1331 that the MG receives from the remote entity.
1333 Remote Contains properties that specify the media flows
1334 that the MG sends to the remote entity.
1336 LocalControl Contains properties (which can be defined in
1337 packages) that are of interest between the MG and
1340 Events Describes events to be detected by the MG and what
1341 to do when an event is detected.
1346 Groves, et al. Standards Track [Page 24]
1348 RFC 3525 Gateway Control Protocol June 2003
1351 EventBuffer Describes events to be detected by the MG when
1352 Event Buffering is active.
1354 Signals Describes signals (see 7.1.11) applied to
1357 Audit In Audit commands, identifies which information is
1360 Packages In AuditValue, returns a list of Packages realized
1363 DigitMap Defines patterns against which sequences of a
1364 specified set of events are to be matched so they
1365 can be reported as a group rather than singly.
1367 ServiceChange In ServiceChange, what, why service change
1370 ObservedEvents In Notify or AuditValue, report of events observed.
1372 Statistics In Subtract and Audit, report of Statistics kept on
1375 Topology Specifies flow directions between Terminations in a
1378 Error Contains an error code and optionally error text;
1379 it may occur in command replies and in Notify
1382 6.2.5 Root Termination
1384 Occasionally, a command must refer to the entire gateway, rather than
1385 a Termination within it. A special TerminationID, "Root" is reserved
1386 for this purpose. Packages may be defined on Root. Root thus may
1387 have properties, events and statistics (signals are not appropriate
1388 for root). Accordingly, the root TerminationID may appear in:
1390 - a Modify command - to change a property or set an event
1392 - a Notify command - to report an event
1394 - an AuditValue return - to examine the values of properties and
1395 statistics implemented on root
1397 - an AuditCapability - to determine what properties of root are
1402 Groves, et al. Standards Track [Page 25]
1404 RFC 3525 Gateway Control Protocol June 2003
1407 - a ServiceChange - to declare the gateway in or out of service.
1409 Any other use of the root TerminationID is an error. Error code
1410 410 - Incorrect identifier shall be returned in these cases.
1414 The protocol provides commands for manipulating the logical entities
1415 of the protocol connection model, Contexts and Terminations.
1416 Commands provide control at the finest level of granularity supported
1417 by the protocol. For example, Commands exist to add Terminations to
1418 a Context, modify Terminations, subtract Terminations from a Context,
1419 and audit properties of Contexts or Terminations. Commands provide
1420 for complete control of the properties of Contexts and Terminations.
1421 This includes specifying which events a Termination is to report,
1422 which signals/actions are to be applied to a Termination and
1423 specifying the topology of a Context (who hears/sees whom).
1425 Most commands are for the specific use of the Media Gateway
1426 Controller as command initiator in controlling Media Gateways as
1427 command responders. The exceptions are the Notify and ServiceChange
1428 commands: Notify is sent from Media Gateway to Media Gateway
1429 Controller, and ServiceChange may be sent by either entity. Below is
1430 an overview of the commands; they are explained in more detail in
1433 1) Add - The Add command adds a Termination to a Context. The Add
1434 command on the first Termination in a Context is used to create a
1437 2) Modify - The Modify command modifies the properties, events and
1438 signals of a Termination.
1440 3) Subtract - The Subtract command disconnects a Termination from its
1441 Context and returns statistics on the Termination's participation
1442 in the Context. The Subtract command on the last Termination in a
1443 Context deletes the Context.
1445 4) Move - The Move command atomically moves a Termination to another
1448 5) AuditValue - The AuditValue command returns the current state of
1449 properties, events, signals and statistics of Terminations.
1451 6) AuditCapabilities - The AuditCapabilities command returns all the
1452 possible values for Termination properties, events and signals
1453 allowed by the Media Gateway.
1458 Groves, et al. Standards Track [Page 26]
1460 RFC 3525 Gateway Control Protocol June 2003
1463 7) Notify - The Notify command allows the Media Gateway to inform the
1464 Media Gateway Controller of the occurrence of events in the Media
1467 8) ServiceChange - The ServiceChange command allows the Media Gateway
1468 to notify the Media Gateway Controller that a Termination or group
1469 of Terminations is about to be taken out of service or has just
1470 been returned to service. ServiceChange is also used by the MG to
1471 announce its availability to a MGC (registration), and to notify
1472 the MGC of impending or completed restart of the MG. The MGC may
1473 announce a handover to the MG by sending it a ServiceChange
1474 command. The MGC may also use ServiceChange to instruct the MG to
1475 take a Termination or group of Terminations in or out of service.
1477 These commands are detailed in 7.2.1 through 7.2.8.
1481 The parameters to a command are termed Descriptors. A descriptor
1482 consists of a name and a list of items. Some items may have values.
1483 Many Commands share common descriptors. This subclause enumerates
1484 these descriptors. Descriptors may be returned as output from a
1485 command. In any such return of descriptor contents, an empty
1486 descriptor is represented by its name unaccompanied by any list.
1487 Parameters and parameter usage specific to a given Command type are
1488 described in the subclause that describes the Command.
1490 7.1.1 Specifying parameters
1492 Command parameters are structured into a number of descriptors. In
1493 general, the text format of descriptors is
1494 DescriptorName=<someID>{parm=value, parm=value, ...}.
1496 Parameters may be fully specified, overspecified or underspecified:
1498 1) Fully specified parameters have a single, unambiguous value that
1499 the command initiator is instructing the command responder to use
1500 for the specified parameter.
1502 2) Underspecified parameters, using the CHOOSE value, allow the
1503 command responder to choose any value it can support.
1505 3) Overspecified parameters have a list of potential values. The
1506 list order specifies the command initiator's order of preference
1507 of selection. The command responder chooses one value from
1508 the offered list and returns that value to the command initiator.
1514 Groves, et al. Standards Track [Page 27]
1516 RFC 3525 Gateway Control Protocol June 2003
1519 If a required descriptor other than the Audit descriptor is
1520 unspecified (i.e., entirely absent) from a command, the previous
1521 values set in that descriptor for that Termination, if any, are
1522 retained. In commands other than Subtract, a missing Audit
1523 descriptor is equivalent to an empty Audit descriptor. The Behaviour
1524 of the MG with respect to unspecified parameters within a descriptor
1525 varies with the descriptor concerned, as indicated in succeeding
1526 subclauses. Whenever a parameter is underspecified or overspecified,
1527 the descriptor containing the value chosen by the responder is
1528 included as output from the command.
1530 Each command specifies the TerminationId the command operates on.
1531 This TerminationId may be "wildcarded". When the TerminationId of a
1532 command is wildcarded, the effect shall be as if the command was
1533 repeated with each of the TerminationIds matched.
1535 7.1.2 Modem descriptor
1537 The Modem descriptor specifies the modem type and parameters, if any,
1538 required for use in e.g., H.324 and text conversation. The
1539 descriptor includes the following modem types: V.18, V.22, V.22 bis,
1540 V.32, V.32 bis, V.34, V.90, V.91, Synchronous ISDN, and allows for
1541 extensions. By default, no Modem descriptor is present in a
1544 7.1.3 Multiplex descriptor
1546 In multimedia calls, a number of media streams are carried on a
1547 (possibly different) number of bearers. The multiplex descriptor
1548 associates the media and the bearers. The descriptor includes the
1559 - possible extensions,
1561 and a set of TerminationIDs representing the multiplexed bearers, in
1564 Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}
1570 Groves, et al. Standards Track [Page 28]
1572 RFC 3525 Gateway Control Protocol June 2003
1575 7.1.4 Media descriptor
1577 The Media descriptor specifies the parameters for all the media
1578 streams. These parameters are structured into two descriptors: a
1579 TerminationState descriptor, which specifies the properties of a
1580 Termination that are not stream dependent, and one or more Stream
1581 descriptors each of which describes a single media stream.
1583 A stream is identified by a StreamID. The StreamID is used to link
1584 the streams in a Context that belong together. Multiple streams
1585 exiting a Termination shall be synchronized with each other. Within
1586 the Stream descriptor, there are up to three subsidiary descriptors:
1587 LocalControl, Local, and Remote. The relationship between these
1588 descriptors is thus:
1591 TerminationState Descriptor
1593 LocalControl descriptor
1597 As a convenience, LocalControl, Local, or Remote descriptors may be
1598 included in the Media descriptor without an enclosing Stream
1599 descriptor. In this case, the StreamID is assumed to be 1.
1601 7.1.5 TerminationState descriptor
1603 The TerminationState descriptor contains the ServiceStates property,
1604 the EventBufferControl property and properties of a Termination
1605 (defined in Packages) that are not stream specific.
1607 The ServiceStates property describes the overall state of the
1608 Termination (not stream specific). A Termination can be in one of
1609 the following states: "test", "out of service", or "in service". The
1610 "test" state indicates that the Termination is being tested. The
1611 state "out of service" indicates that the Termination cannot be used
1612 for traffic. The state "in service" indicates that a Termination can
1613 be used or is being used for normal traffic. "in service" is the
1626 Groves, et al. Standards Track [Page 29]
1628 RFC 3525 Gateway Control Protocol June 2003
1631 Values assigned to Properties may be simple values
1632 (integer/string/enumeration) or may be underspecified, where more
1633 than one value is supplied and the MG may make a choice:
1635 - Alternative Values - multiple values in a list, one of which must
1638 - Ranges - minimum and maximum values, any value between min and max
1639 must be selected, boundary values included
1641 - Greater Than/Less Than - value must be greater/less than specified
1644 - CHOOSE Wildcard - the MG chooses from the allowed values for the
1647 The EventBufferControl property specifies whether events are buffered
1648 following detection of an event in the Events descriptor, or
1649 processed immediately. See 7.1.9 for details.
1651 7.1.6 Stream descriptor
1653 A Stream descriptor specifies the parameters of a single
1654 bidirectional stream. These parameters are structured into three
1655 descriptors: one that contains Termination properties specific to a
1656 stream and one each for local and remote flows. The Stream
1657 Descriptor includes a StreamID which identifies the stream. Streams
1658 are created by specifying a new StreamID on one of the Terminations
1659 in a Context. A stream is deleted by setting empty Local and Remote
1660 descriptors for the stream with ReserveGroup and ReserveValue in
1661 LocalControl set to "false" on all Terminations in the Context that
1662 previously supported that stream.
1664 StreamIDs are of local significance between MGC and MG and they are
1665 assigned by the MGC. Within a Context, StreamID is a means by which
1666 to indicate which media flows are interconnected: streams with the
1667 same StreamID are connected.
1669 If a Termination is moved from one Context to another, the effect on
1670 the Context to which the Termination is moved is the same as in the
1671 case that a new Termination were added with the same StreamIDs as the
1682 Groves, et al. Standards Track [Page 30]
1684 RFC 3525 Gateway Control Protocol June 2003
1687 7.1.7 LocalControl descriptor
1689 The LocalControl descriptor contains the Mode property, the
1690 ReserveGroup and ReserveValue properties and properties of a
1691 Termination (defined in Packages) that are stream specific, and are
1692 of interest between the MG and the MGC. Values of properties may be
1693 underspecified as in 7.1.1.
1695 The allowed values for the mode property are send-only, receive-only,
1696 send/receive, inactive and loop-back. "Send" and "receive" are with
1697 respect to the exterior of the Context, so that, for example, a
1698 stream set to mode=sendOnly does not pass received media into the
1699 Context. The default value for the mode property is "Inactive".
1700 Signals and Events are not affected by mode.
1702 The boolean-valued Reserve properties, ReserveValue and ReserveGroup,
1703 of a Termination indicate what the MG is expected to do when it
1704 receives a Local and/or Remote descriptor.
1706 If the value of a Reserve property is True, the MG SHALL reserve
1707 resources for all alternatives specified in the Local and/or Remote
1708 descriptors for which it currently has resources available. It SHALL
1709 respond with the alternatives for which it reserves resources. If it
1710 cannot not support any of the alternatives, it SHALL respond with a
1711 reply to the MGC that contains empty Local and/or Remote descriptors.
1712 If media begins to flow while more than a single alternative is
1713 reserved, media packets may be sent/received on any of the
1714 alternatives and must be processed, although only a single
1715 alternative may be active at any given time.
1717 If the value of a Reserve property is False, the MG SHALL choose one
1718 of the alternatives specified in the Local descriptor (if present)
1719 and one of the alternatives specified in the Remote descriptor (if
1720 present). If the MG has not yet reserved resources to support the
1721 selected alternative, it SHALL reserve the resources. If, on the
1722 other hand, it already reserved resources for the Termination
1723 addressed (because of a prior exchange with ReserveValue and/or
1724 ReserveGroup equal to True), it SHALL release any excess resources it
1725 reserved previously. Finally, the MG shall send a reply to the MGC
1726 containing the alternatives for the Local and/or Remote descriptor
1727 that it selected. If the MG does not have sufficient resources to
1728 support any of the alternatives specified, it SHALL respond with
1729 error 510 (insufficient resources).
1731 The default value of ReserveValue and ReserveGroup is False. More
1732 information on the use of the two Reserve properties is provided in
1738 Groves, et al. Standards Track [Page 31]
1740 RFC 3525 Gateway Control Protocol June 2003
1743 A new setting of the LocalControl Descriptor completely replaces the
1744 previous setting of that descriptor in the MG. Thus, to retain
1745 information from the previous setting, the MGC must include that
1746 information in the new setting. If the MGC wishes to delete some
1747 information from the existing descriptor, it merely resends the
1748 descriptor (in a Modify command) with the unwanted information
1751 7.1.8 Local and Remote descriptors
1753 The MGC uses Local and Remote descriptors to reserve and commit MG
1754 resources for media decoding and encoding for the given Stream(s) and
1755 Termination to which they apply. The MG includes these descriptors
1756 in its response to indicate what it is actually prepared to support.
1757 The MG SHALL include additional properties and their values in its
1758 response if these properties are mandatory yet not present in the
1759 requests made by the MGC (e.g., by specifying detailed video encoding
1760 parameters where the MGC only specified the payload type).
1762 Local refers to the media received by the MG and Remote refers to the
1763 media sent by the MG.
1765 When text encoding the protocol, the descriptors consist of session
1766 descriptions as defined in SDP (RFC 2327). In session descriptions
1767 sent from the MGC to the MG, the following exceptions to the syntax
1768 of RFC 2327 are allowed:
1770 - the "s=", "t=" and "o=" lines are optional;
1772 - the use of CHOOSE is allowed in place of a single parameter value;
1775 - the use of alternatives is allowed in place of a single parameter
1778 A Stream Descriptor specifies a single bi-directional media stream
1779 and so a single session description MUST NOT include more than one
1780 media description ("m=" line). A Stream Descriptor may contain
1781 additional session descriptions as alternatives. Each media stream
1782 for a termination must appear in distinct Stream Descriptors. When
1783 multiple session descriptions are provided in one descriptor, the
1784 "v=" lines are required as delimiters; otherwise they are optional in
1785 session descriptions sent to the MG. Implementations shall accept
1786 session descriptions that are fully conformant to RFC 2327. When
1787 binary encoding the protocol the descriptor consists of groups of
1788 properties (tag-value pairs) as specified in Annex C. Each such
1789 group may contain the parameters of a session description.
1794 Groves, et al. Standards Track [Page 32]
1796 RFC 3525 Gateway Control Protocol June 2003
1799 Below, the semantics of the Local and Remote descriptors are
1800 specified in detail. The specification consists of two parts. The
1801 first part specifies the interpretation of the contents of the
1802 descriptor. The second part specifies the actions the MG must take
1803 upon receiving the Local and Remote descriptors. The actions to be
1804 taken by the MG depend on the values of the ReserveValue and
1805 ReserveGroup properties of the LocalControl descriptor.
1807 Either the Local or the Remote descriptor or both may be:
1809 1) unspecified (i.e., absent);
1813 3) underspecified through use of CHOOSE in a property value;
1815 4) fully specified; or
1817 5) overspecified through presentation of multiple groups of
1818 properties and possibly multiple property values in one or more of
1821 Where the descriptors have been passed from the MGC to the MG, they
1822 are interpreted according to the rules given in 7.1.1, with the
1823 following additional comments for clarification:
1825 a) An unspecified Local or Remote descriptor is considered to be a
1826 missing mandatory parameter. It requires the MG to use whatever
1827 was last specified for that descriptor. It is possible that there
1828 was no previously specified value, in which case the descriptor
1829 concerned is ignored in further processing of the command.
1831 b) An empty Local (Remote) descriptor in a message from the MGC
1832 signifies a request to release any resources reserved for the
1833 media flow received (sent).
1835 c) If multiple groups of properties are present in a Local or Remote
1836 descriptor or multiple values within a group, the order of
1837 preference is descending.
1839 d) Underspecified or overspecified properties within a group of
1840 properties sent by the MGC are requests for the MG to choose one
1841 or more values which it can support for each of those properties.
1842 In case of an overspecified property, the list of values is in
1843 descending order of preference.
1845 Subject to the above rules, subsequent action depends on the values
1846 of the ReserveValue and ReserveGroup properties in LocalControl.
1850 Groves, et al. Standards Track [Page 33]
1852 RFC 3525 Gateway Control Protocol June 2003
1855 If ReserveGroup is True, the MG reserves the resources required to
1856 support any of the requested property group alternatives that it can
1857 currently support. If ReserveValue is True, the MG reserves the
1858 resources required to support any of the requested property value
1859 alternatives that it can currently support.
1861 NOTE - If a Local or Remote descriptor contains multiple groups of
1862 properties, and ReserveGroup is True, then the MG is requested to
1863 reserve resources so that it can decode or encode the media stream
1864 according to any of the alternatives. For instance, if the Local
1865 descriptor contains two groups of properties, one specifying
1866 packetized G.711 A-law audio and the other G.723.1 audio, the MG
1867 reserves resources so that it can decode one audio stream encoded in
1868 either G.711 A-law format or G.723.1 format. The MG does not have to
1869 reserve resources to decode two audio streams simultaneously, one
1870 encoded in G.711 A-law and one in G.723.1. The intention for the use
1871 of ReserveValue is analogous.
1873 If ReserveGroup is true or ReserveValue is True, then the following
1876 - If the MG has insufficient resources to support all alternatives
1877 requested by the MGC and the MGC requested resources in both Local
1878 and Remote, the MG should reserve resources to support at least
1879 one alternative each within Local and Remote.
1881 - If the MG has insufficient resources to support at least one
1882 alternative within a Local (Remote) descriptor received from the
1883 MGC, it shall return an empty Local (Remote) in response.
1885 - In its response to the MGC, when the MGC included Local and Remote
1886 descriptors, the MG SHALL include Local and Remote descriptors for
1887 all groups of properties and property values it reserved resources
1888 for. If the MG is incapable of supporting at least one of the
1889 alternatives within the Local (Remote) descriptor received from
1890 the MGC, it SHALL return an empty Local (Remote) descriptor.
1892 - If the Mode property of the LocalControl descriptor is RecvOnly,
1893 SendRecv, or LoopBack, the MG must be prepared to receive media
1894 encoded according to any of the alternatives included in its
1895 response to the MGC.
1897 If ReserveGroup is False and ReserveValue is False, then the MG
1898 SHOULD apply the following rules to resolve Local and Remote to a
1899 single alternative each:
1901 - The MG chooses the first alternative in Local for which it is able
1902 to support at least one alternative in Remote.
1906 Groves, et al. Standards Track [Page 34]
1908 RFC 3525 Gateway Control Protocol June 2003
1911 - If the MG is unable to support at least one Local and one Remote
1912 alternative, it returns Error 510 (Insufficient Resources).
1914 - The MG returns its selected alternative in each of Local and
1917 A new setting of a Local or Remote descriptor completely replaces the
1918 previous setting of that descriptor in the MG. Thus, to retain
1919 information from the previous setting, the MGC must include that
1920 information in the new setting. If the MGC wishes to delete some
1921 information from the existing descriptor, it merely resends the
1922 descriptor (in a Modify command) with the unwanted information
1925 7.1.9 Events descriptor
1927 The EventsDescriptor parameter contains a RequestIdentifier and a
1928 list of events that the Media Gateway is requested to detect and
1929 report. The RequestIdentifier is used to correlate the request with
1930 the notifications that it may trigger. Requested events include, for
1931 example, fax tones, continuity test results, and on-hook and off-hook
1932 transitions. The RequestIdentifier is omitted if the
1933 EventsDescriptor is empty (i.e., no events are specified).
1935 Each event in the descriptor contains the Event name, an optional
1936 streamID, an optional KeepActive flag, and optional parameters. The
1937 Event name consists of a Package Name (where the event is defined)
1938 and an EventID. The ALL wildcard may be used for the EventID,
1939 indicating that all events from the specified package have to be
1940 detected. The default streamID is 0, indicating that the event to be
1941 detected is not related to a particular media stream. Events can
1942 have parameters. This allows a single event description to have some
1943 variation in meaning without creating large numbers of individual
1944 events. Further event parameters are defined in the package.
1946 If a digit map completion event is present or implied in the
1947 EventsDescriptor, the EventDM parameter is used to carry either the
1948 name or the value of the associated digit map. See 7.1.14 for
1951 When an event is processed against the contents of an active Events
1952 Descriptor and found to be present in that descriptor ("recognized"),
1953 the default action of the MG is to send a Notify command to the MGC.
1954 Notification may be deferred if the event is absorbed into the
1955 current dial string of an active digit map (see 7.1.14). Any other
1956 action is for further study. Moreover, event recognition may cause
1957 currently active signals to stop, or may cause the current Events
1958 and/or Signals descriptor to be replaced, as described at the end of
1962 Groves, et al. Standards Track [Page 35]
1964 RFC 3525 Gateway Control Protocol June 2003
1967 this subclause. Unless the Events Descriptor is replaced by another
1968 Events Descriptor, it remains active after an event has been
1971 If the value of the EventBufferControl property equals LockStep,
1972 following detection of such an event, normal handling of events is
1973 suspended. Any event which is subsequently detected and occurs in
1974 the EventBuffer descriptor is added to the end of the EventBuffer (a
1975 FIFO queue), along with the time that it was detected. The MG SHALL
1976 wait for a new EventsDescriptor to be loaded. A new EventsDescriptor
1977 can be loaded either as the result of receiving a command with a new
1978 EventsDescriptor, or by activating an embedded EventsDescriptor.
1980 If EventBufferControl equals Off, the MG continues processing based
1981 on the active EventsDescriptor.
1983 In the case of an embedded EventsDescriptor being activated, the MG
1984 continues event processing based on the newly activated
1987 NOTE 1 - For purposes of EventBuffer handling, activation of an
1988 embedded EventsDescriptor is equivalent to receipt of a new
1991 When the MG receives a command with a new EventsDescriptor, one or
1992 more events may have been buffered in the EventBuffer in the MG. The
1993 value of EventBufferControl then determines how the MG treats such
1998 If EventBufferControl equals LockStep and the MG receives a new
1999 EventsDescriptor, it will check the FIFO EventBuffer and take the
2002 1) If the EventBuffer is empty, the MG waits for detection of events
2003 based on the new EventsDescriptor.
2005 2) If the EventBuffer is non-empty, the MG processes the FIFO queue
2006 starting with the first event:
2008 a) If the event in the queue is in the events listed in the new
2009 EventsDescriptor, the MG acts on the event and removes the
2010 event from the EventBuffer. The time stamp of the Notify shall
2011 be the time the event was actually detected. The MG then waits
2012 for a new EventsDescriptor. While waiting for a new
2013 EventsDescriptor, any events detected that appear in the
2018 Groves, et al. Standards Track [Page 36]
2020 RFC 3525 Gateway Control Protocol June 2003
2023 EventsBufferDescriptor will be placed in the EventBuffer. When
2024 a new EventsDescriptor is received, the event processing will
2027 b) If the event is not in the new EventsDescriptor, the MG SHALL
2028 discard the event and repeat from step 1.
2032 If EventBufferControl equals Off and the MG receives a new
2033 EventsDescriptor, it processes new events with the new
2036 If the MG receives a command instructing it to set the value of
2037 EventBufferControl to Off, all events in the EventBuffer SHALL be
2040 The MG may report several events in a single Transaction as long as
2041 this does not unnecessarily delay the reporting of individual events.
2043 For procedures regarding transmitting the Notify command, refer to
2044 the appropriate annex or Recommendation of the H.248 sub-series for
2045 specific transport considerations.
2047 The default value of EventBufferControl is Off.
2049 NOTE 2 - Since the EventBufferControl property is in the
2050 TerminationStateDescriptor, the MG might receive a command that
2051 changes the EventBufferControl property and does not include an
2054 Normally, recognition of an event shall cause any active signals to
2055 stop. When KeepActive is specified in the event, the MG shall not
2056 interrupt any signals active on the Termination on which the event is
2059 An event can include an Embedded Signals descriptor and/or an
2060 Embedded Events descriptor which, if present, replaces the current
2061 Signals/Events descriptor when the event is recognized. It is
2062 possible, for example, to specify that the dial-tone Signal be
2063 generated when an off-hook Event is recognized, or that the dial-tone
2064 Signal be stopped when a digit is recognized. A media gateway
2065 controller shall not send EventsDescriptors with an event both marked
2066 KeepActive and containing an embedded SignalsDescriptor.
2074 Groves, et al. Standards Track [Page 37]
2076 RFC 3525 Gateway Control Protocol June 2003
2079 Only one level of embedding is permitted. An embedded
2080 EventsDescriptor SHALL NOT contain another embedded EventsDescriptor;
2081 an embedded EventsDescriptor MAY contain an embedded
2084 An EventsDescriptor received by a media gateway replaces any previous
2085 Events descriptor. Event notification in process shall complete, and
2086 events detected after the command containing the new EventsDescriptor
2087 executes, shall be processed according to the new EventsDescriptor.
2089 An empty Events Descriptor disables all event recognition and
2090 reporting. An empty EventBuffer Descriptor clears the EventBuffer
2091 and disables all event accumulation in LockStep mode: the only events
2092 reported will be those occurring while an Events Descriptor is
2093 active. If an empty Events Descriptor is activated while the
2094 Termination is operating in LockStep mode, the events buffer is
2095 immediately cleared.
2097 7.1.10 EventBuffer descriptor
2099 The EventBuffer descriptor contains a list of events, with their
2100 parameters if any, that the MG is requested to detect and buffer when
2101 EventBufferControl equals LockStep (see 7.1.9).
2103 7.1.11 Signals descriptor
2105 Signals are MG generated media such as tones and announcements as
2106 well as bearer-related signals such as hookswitch. More complex
2107 signals may include a sequence of such simple signals interspersed
2108 with and conditioned upon the receipt and analysis of media or
2109 bearer-related signals. Examples include echoing of received data as
2110 in Continuity Test package. Signals may also request preparation of
2111 media content for future signals.
2113 A SignalsDescriptor is a parameter that contains the set of signals
2114 that the Media Gateway is asked to apply to a Termination. A
2115 SignalsDescriptor contains a number of signals and/or sequential
2116 signal lists. A SignalsDescriptor may contain zero signals and
2117 sequential signal lists. Support of sequential signal lists is
2120 Signals are defined in packages. Signals shall be named with a
2121 Package name (in which the signal is defined) and a SignalID. No
2122 wildcard shall be used in the SignalID. Signals that occur in a
2123 SignalsDescriptor have an optional StreamID parameter (default is 0,
2124 to indicate that the signal is not related to a particular media
2125 stream), an optional signal type (see below), an optional duration
2126 and possibly parameters defined in the package that defines the
2130 Groves, et al. Standards Track [Page 38]
2132 RFC 3525 Gateway Control Protocol June 2003
2135 signal. This allows a single signal to have some variation in
2136 meaning, obviating the need to create large numbers of individual
2139 Finally, the optional parameter "notifyCompletion" allows a MGC to
2140 indicate that it wishes to be notified when the signal finishes
2141 playout. The possible cases are that the signal timed out (or
2142 otherwise completed on its own), that it was interrupted by an event,
2143 that it was halted when a Signals descriptor was replaced, or that it
2144 stopped or never started for other reasons. If the notifyCompletion
2145 parameter is not included in a Signals descriptor, notification is
2146 generated only if the signal stopped or was never started for other
2147 reasons. For reporting to occur, the signal completion event (see
2148 E.1.2) must be enabled in the currently active Events descriptor.
2150 The duration is an integer value that is expressed in hundredths of a
2153 There are three types of signals:
2155 - on/off - the signal lasts until it is turned off;
2157 - timeout - the signal lasts until it is turned off or a specific
2158 period of time elapses;
2160 - brief - the signal will stop on its own unless a new Signals
2161 descriptor is applied that causes it to stop; no timeout value is
2164 If a signal of default type other than TO has its type overridden to
2165 type TO in the Signals descriptor, the duration parameter must be
2168 If the signal type is specified in a SignalsDescriptor, it overrides
2169 the default signal type (see 12.1.4). If duration is specified for
2170 an on/off signal, it SHALL be ignored.
2172 A sequential signal list consists of a signal list identifier and a
2173 sequence of signals to be played sequentially. Only the trailing
2174 element of the sequence of signals in a sequential signal list may be
2175 an on/off signal. The duration of a sequential signal list is the
2176 sum of the durations of the signals it contains.
2178 Multiple signals and sequential signal lists in the same
2179 SignalsDescriptor shall be played simultaneously.
2181 Signals are defined as proceeding from the Termination towards the
2182 exterior of the Context unless otherwise specified in a package.
2186 Groves, et al. Standards Track [Page 39]
2188 RFC 3525 Gateway Control Protocol June 2003
2191 When the same Signal is applied to multiple Terminations within one
2192 Transaction, the MG should consider using the same resource to
2193 generate these Signals.
2195 Production of a Signal on a Termination is stopped by application of
2196 a new SignalsDescriptor, or detection of an Event on the Termination
2199 A new SignalsDescriptor replaces any existing SignalsDescriptor. Any
2200 signals applied to the Termination not in the replacement descriptor
2201 shall be stopped, and new signals are applied, except as follows.
2202 Signals present in the replacement descriptor and containing the
2203 KeepActive flag shall be continued if they are currently playing and
2204 have not already completed. If a replacement signal descriptor
2205 contains a signal that is not currently playing and contains the
2206 KeepActive flag, that signal SHALL be ignored. If the replacement
2207 descriptor contains a sequential signal list with the same identifier
2208 as the existing descriptor, then
2210 - the signal type and sequence of signals in the sequential signal
2211 list in the replacement descriptor shall be ignored; and
2213 - the playing of the signals in the sequential signal list in the
2214 existing descriptor shall not be interrupted.
2216 7.1.12 Audit descriptor
2218 The Audit descriptor specifies what information is to be audited.
2219 The Audit descriptor specifies the list of descriptors to be
2220 returned. Audit may be used in any command to force the return of
2221 any descriptor containing the current values of its properties,
2222 events, signals and statistics even if that descriptor was not
2223 present in the command, or had no underspecified parameters.
2224 Possible items in the Audit descriptor are:
2242 Groves, et al. Standards Track [Page 40]
2244 RFC 3525 Gateway Control Protocol June 2003
2247 Audit may be empty, in which case, no descriptors are returned. This
2248 is useful in Subtract, to inhibit return of statistics, especially
2249 when using wildcard.
2251 7.1.13 ServiceChange descriptor
2253 The ServiceChangeDescriptor contains the following parameters:
2255 . ServiceChangeMethod
2256 . ServiceChangeReason
2257 . ServiceChangeAddress
2258 . ServiceChangeDelay
2259 . ServiceChangeProfile
2260 . ServiceChangeVersion
2261 . ServiceChangeMGCId
2267 7.1.14 DigitMap descriptor
2269 7.1.14.1 DigitMap definition, creation, modification and deletion
2271 A DigitMap is a dialing plan resident in the Media Gateway used for
2272 detecting and reporting digit events received on a Termination. The
2273 DigitMap descriptor contains a DigitMap name and the DigitMap to be
2274 assigned. A digit map may be preloaded into the MG by management
2275 action and referenced by name in an EventsDescriptor, may be defined
2276 dynamically and subsequently referenced by name, or the actual
2277 digitmap itself may be specified in the EventsDescriptor. It is
2278 permissible for a digit map completion event within an Events
2279 descriptor to refer by name to a DigitMap which is defined by a
2280 DigitMap descriptor within the same command, regardless of the
2281 transmitted order of the respective descriptors.
2283 DigitMaps defined in a DigitMapDescriptor can occur in any of the
2284 standard Termination manipulation Commands of the protocol. A
2285 DigitMap, once defined, can be used on all Terminations specified by
2286 the (possibly wildcarded) TerminationID in such a command. DigitMaps
2287 defined on the root Termination are global and can be used on every
2288 Termination in the MG, provided that a DigitMap with the same name
2289 has not been defined on the given Termination. When a DigitMap is
2290 defined dynamically in a DigitMap descriptor:
2292 - A new DigitMap is created by specifying a name that is not yet
2293 defined. The value shall be present.
2298 Groves, et al. Standards Track [Page 41]
2300 RFC 3525 Gateway Control Protocol June 2003
2303 - A DigitMap value is updated by supplying a new value for a name
2304 that is already defined. Terminations presently using the
2305 digitmap shall continue to use the old definition; subsequent
2306 EventsDescriptors specifying the name, including any
2307 EventsDescriptor in the command containing the DigitMap
2308 descriptor, shall use the new one.
2310 - A DigitMap is deleted by supplying an empty value for a name that
2311 is already defined. Terminations presently using the digitmap
2312 shall continue to use the old definition.
2314 7.1.14.2 DigitMap Timers
2316 The collection of digits according to a DigitMap may be protected by
2317 three timers, viz. a start timer (T), short timer (S), and long timer
2320 1) The start timer (T) is used prior to any digits having been
2321 dialed. If the start timer is overridden with the value set to
2322 zero (T=0), then the start timer shall be disabled. This implies
2323 that the MG will wait indefinitely for digits.
2325 2) If the Media Gateway can determine that at least one more digit is
2326 needed for a digit string to match any of the allowed patterns in
2327 the digit map, then the interdigit timer value should be set to a
2328 long (L) duration (e.g., 16 seconds).
2330 3) If the digit string has matched one of the patterns in a digit
2331 map, but it is possible that more digits could be received which
2332 would cause a match with a different pattern, then instead of
2333 reporting the match immediately, the MG must apply the short timer
2334 (S) and wait for more digits.
2336 The timers are configurable parameters to a DigitMap. Default values
2337 of these timers should be provisioned on the MG, but can be
2338 overridden by values specified within the DigitMap.
2340 7.1.14.3 DigitMap Syntax
2342 The formal syntax of the digit map is described by the DigitMap rule
2343 in the formal syntax description of the protocol (see Annex A and
2344 Annex B). A DigitMap, according to this syntax, is defined either by
2345 a string or by a list of strings. Each string in the list is an
2346 alternative event sequence, specified either as a sequence of digit
2347 map symbols or as a regular expression of digit map symbols. These
2348 digit map symbols, the digits "0" through "9" and letters "A" through
2349 a maximum value depending on the signalling system concerned, but
2350 never exceeding "K", correspond to specified events within a package
2354 Groves, et al. Standards Track [Page 42]
2356 RFC 3525 Gateway Control Protocol June 2003
2359 which has been designated in the Events descriptor on the Termination
2360 to which the digit map is being applied. (The mapping between events
2361 and digit map symbols is defined in the documentation for packages
2362 associated with channel-associated signalling systems such as DTMF,
2363 MF, or R2. Digits "0" through "9" MUST be mapped to the
2364 corresponding digit events within the signalling system concerned.
2365 Letters should be allocated in logical fashion, facilitating the use
2366 of range notation for alternative events.)
2368 The letter "x" is used as a wildcard, designating any event
2369 corresponding to symbols in the range "0"-"9". The string may also
2370 contain explicit ranges and, more generally, explicit sets of
2371 symbols, designating alternative events any one of which satisfies
2372 that position of the digit map. Finally, the dot symbol "." stands
2373 for zero or more repetitions of the event selector (event, range of
2374 events, set of alternative events, or wildcard) that precedes it. As
2375 a consequence of the third timing rule above, inter-event timing
2376 while matching a terminal dot symbol uses the short timer by default.
2378 In addition to these event symbols, the string may contain "S" and
2379 "L" inter-event timing specifiers and the "Z" duration modifier. "S"
2380 and "L" respectively indicate that the MG should use the short (S)
2381 timer or the long (L) timer for subsequent events, overriding the
2382 timing rules described above. If an explicit timing specifier is in
2383 effect in one alternative event sequence, but none is given in any
2384 other candidate alternative, the timer value set by the explicit
2385 timing specifier must be used. If all sequences with explicit timing
2386 controls are dropped from the candidate set, timing reverts to the
2387 default rules given above. Finally, if conflicting timing specifiers
2388 are in effect in different alternative sequences, the long timer
2391 A "Z" designates a long duration event: placed in front of the
2392 symbol(s) designating the event(s) which satisfy a given digit
2393 position, it indicates that that position is satisfied only if the
2394 duration of the event exceeds the long-duration threshold. The value
2395 of this threshold is assumed to be provisioned in the MG.
2397 7.1.14.4 DigitMap Completion Event
2399 A digit map is active while the Events descriptor which invoked it is
2400 active and it has not completed. A digit map completes when:
2402 - a timer has expired; or
2404 - an alternative event sequence has been matched and no other
2405 alternative event sequence in the digit map could be matched
2406 through detection of an additional event (unambiguous match); or
2410 Groves, et al. Standards Track [Page 43]
2412 RFC 3525 Gateway Control Protocol June 2003
2415 - an event has been detected such that a match to a complete
2416 alternative event sequence of the digit map will be impossible no
2417 matter what additional events are received.
2419 Upon completion, a digit map completion event as defined in the
2420 package providing the events being mapped into the digit map shall be
2421 generated. At that point the digit map is deactivated. Subsequent
2422 events in the package are processed as per the currently active event
2423 processing mechanisms.
2425 7.1.14.5 DigitMap Procedures
2427 Pending completion, successive events shall be processed according to
2428 the following rules:
2430 1) The "current dial string", an internal variable, is initially
2431 empty. The set of candidate alternative event sequences includes
2432 all of the alternatives specified in the digit map.
2434 2) At each step, a timer is set to wait for the next event, based
2435 either on the default timing rules given above or on explicit
2436 timing specified in one or more alternative event sequences. If
2437 the timer expires and a member of the candidate set of
2438 alternatives is fully satisfied, a timeout completion with full
2439 match is reported. If the timer expires and part or none of any
2440 candidate alternative is satisfied, a timeout completion with
2441 partial match is reported.
2443 3) If an event is detected before the timer expires, it is mapped to
2444 a digit string symbol and provisionally added to the end of the
2445 current dial string. The duration of the event (long or not long)
2446 is noted if and only if this is relevant in the current symbol
2447 position (because at least one of the candidate alternative event
2448 sequences includes the "Z" modifier at this position in the
2451 4) The current dial string is compared to the candidate alternative
2452 event sequences. If and only if a sequence expecting a
2453 long-duration event at this position is matched (i.e., the event
2454 had long duration and met the specification for this position),
2455 then any alternative event sequences not specifying a long
2456 duration event at this position are discarded, and the current
2457 dial string is modified by inserting a "Z" in front of the symbol
2458 representing the latest event. Any sequence expecting a long-
2459 duration event at this position but not matching the observed
2460 event is discarded from the candidate set. If alternative event
2461 sequences not specifying a long duration event in the given
2466 Groves, et al. Standards Track [Page 44]
2468 RFC 3525 Gateway Control Protocol June 2003
2471 position remain in the candidate set after application of the
2472 above rules, the observed event duration is treated as irrelevant
2473 in assessing matches to them.
2475 5) If exactly one candidate remains and it has been fully matched, a
2476 completion event is generated indicating an unambiguous match. If
2477 no candidates remain, the latest event is removed from the current
2478 dial string and a completion event is generated indicating full
2479 match if one of the candidates from the previous step was fully
2480 satisfied before the latest event was detected, or partial match
2481 otherwise. The event removed from the current dial string will
2482 then be reported as per the currently active event processing
2485 6) If no completion event is reported out of step 5, processing
2488 7.1.14.6 DigitMap Activation
2490 A digit map is activated whenever a new Event descriptor is applied
2491 to the Termination or embedded Event descriptor is activated, and
2492 that Event descriptor contains a digit map completion event. The
2493 digit map completion event contains an eventDM field in the requested
2494 actions field. Each new activation of a digit map begins at step 1
2495 of the above procedure, with a clear current dial string. Any
2496 previous contents of the current dial string from an earlier
2497 activation are lost.
2499 A digit map completion event that does not contain an eventDM field
2500 in its requested actions field is considered an error. Upon receipt
2501 of such an event in an EventsDescriptor, a MG shall respond with an
2502 error response, including Error 457 - Missing parameter in signal or
2505 7.1.14.7 Interaction Of DigitMap and Event Processing
2507 While the digit map is activated, detection is enabled for all events
2508 defined in the package containing the specified digit map completion
2509 event. Normal event behaviour (e.g., stopping of signals unless the
2510 digit completion event has the KeepActive flag enabled) continues to
2511 apply for each such event detected, except that:
2513 - the events in the package containing the specified digit map
2514 completion event other than the completion event itself are not
2515 individually notified and have no side-effects unless separately
2522 Groves, et al. Standards Track [Page 45]
2524 RFC 3525 Gateway Control Protocol June 2003
2527 - an event that triggers a partial match completion event is not
2528 recognized and therefore has no side effects until reprocessed
2529 following the recognition of the digit map completion event.
2533 Note that if a package contains a digit map completion event, then an
2534 event specification consisting of the package name with a wildcarded
2535 ItemID (Property Name) will activate a digit map; to that end, the
2536 event specification must include an eventDM field according to
2537 section 7.1.14.6. If the package also contains the digit events
2538 themselves, this form of event specification will cause the
2539 individual events to be reported to the MGC as they are detected.
2543 As an example, consider the following dial plan:
2547 00 Long-distance operator
2549 xxxx Local extension number (starts with 1-7)
2551 8xxxxxxx Local number
2553 #xxxxxxx Off-site extension
2557 91xxxxxxxxxx Long-distance number
2559 9011 + up to 15 digits International number
2563 If the DTMF detection package described in E.6 is used to collect the
2564 dialed digits, then the dialing plan shown above results in the
2565 following digit map:
2567 (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)
2569 7.1.15 Statistics descriptor
2571 The Statistics Descriptor provides information describing the status
2572 and usage of a Termination during its existence within a specific
2573 Context. There is a set of standard statistics kept for each
2574 Termination where appropriate (number of octets sent and received for
2578 Groves, et al. Standards Track [Page 46]
2580 RFC 3525 Gateway Control Protocol June 2003
2583 example). The particular statistical properties that are reported
2584 for a given Termination are determined by the Packages realized by
2585 the Termination. By default, statistics are reported when the
2586 Termination is Subtracted from the Context. This behaviour can be
2587 overridden by including an empty AuditDescriptor in the Subtract
2588 command. Statistics may also be returned from the AuditValue
2589 command, or any Add/Move/Modify command using the Audit descriptor.
2591 Statistics are cumulative; reporting Statistics does not reset them.
2592 Statistics are reset when a Termination is Subtracted from a Context.
2594 7.1.16 Packages descriptor
2596 Used only with the AuditValue command, the PackageDescriptor returns
2597 a list of Packages realized by the Termination.
2599 7.1.17 ObservedEvents descriptor
2601 ObservedEvents is supplied with the Notify command to inform the MGC
2602 of which event(s) were detected. Used with the AuditValue command,
2603 the ObservedEventsDescriptor returns events in the event buffer which
2604 have not been Notified. ObservedEvents contains the
2605 RequestIdentifier of the EventsDescriptor that triggered the
2606 notification, the event(s) detected, optionally the detection time(s)
2607 and any parameters of the observed event. Detection times are
2608 reported with a precision of hundredths of a second.
2610 7.1.18 Topology descriptor
2612 A Topology descriptor is used to specify flow directions between
2613 Terminations in a Context. Contrary to the descriptors in previous
2614 subclauses, the Topology descriptor applies to a Context instead of a
2615 Termination. The default topology of a Context is that each
2616 Termination's transmission is received by all other Terminations.
2617 The Topology descriptor is optional to implement. An MG that does
2618 not support Topology descriptors, but receives a command containing
2619 one, returns Error 444 Unsupported or unknown descriptor, and
2620 optionally includes a string containing the name of the unsupported
2621 Descriptor ("Topology") in the error text in the error descriptor.
2623 The Topology descriptor occurs before the commands in an action. It
2624 is possible to have an action containing only a Topology descriptor,
2625 provided that the Context to which the action applies already exists.
2634 Groves, et al. Standards Track [Page 47]
2636 RFC 3525 Gateway Control Protocol June 2003
2639 A Topology descriptor consists of a sequence of triples of the form
2640 (T1, T2, association). T1 and T2 specify Terminations within the
2641 Context, possibly using the ALL or CHOOSE wildcard. The association
2642 specifies how media flows between these two Terminations as follows.
2644 - (T1, T2, isolate) means that the Terminations matching T2 do not
2645 receive media from the Terminations matching T1, nor vice versa.
2647 - (T1, T2, oneway) means that the Terminations that match T2 receive
2648 media from the Terminations matching T1, but not vice versa. In
2649 this case use of the ALL wildcard such that there are Terminations
2650 that match both T1 and T2 is not allowed.
2652 - (T1, T2, bothway) means that the Terminations matching T2 receive
2653 media from the Terminations matching T1, and vice versa. In this
2654 case it is allowed to use wildcards such that there are
2655 Terminations that match both T1 and T2. However, if there is a
2656 Termination that matches both, no loopback is introduced.
2658 CHOOSE wildcards may be used in T1 and T2 as well, under the
2659 following restrictions:
2661 - the action (see clause 8) of which the topology descriptor is part
2662 contains an Add command in which a CHOOSE wildcard is used;
2664 - if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL
2667 The CHOOSE wildcard in a Topology descriptor matches the
2668 TerminationID that the MG assigns in the first Add command that uses
2669 a CHOOSE wildcard in the same action. An existing Termination that
2670 matches T1 or T2 in the Context to which a Termination is added, is
2671 connected to the newly added Termination as specified by the Topology
2674 If a termination is not mentioned within a Topology Descriptor, any
2675 topology associated with it remains unchanged. If, however, a new
2676 termination is added into a context its association with the other
2677 terminations within the context defaults to bothway, unless a
2678 Topology Descriptor is given to change this (e.g., if T3 is added to
2679 a context with T1 and T2 with topology (T3, T1, oneway) it will be
2680 connected bothway to T2).
2682 Figure 7 and the table following it show some examples of the effect
2683 of including topology descriptors in actions. In these examples it
2684 is assumed that the topology descriptors are applied in sequence.
2690 Groves, et al. Standards Track [Page 48]
2692 RFC 3525 Gateway Control Protocol June 2003
2695 +------------------+ +------------------+ +------------------+
2696 | +----+ | | +----+ | | +----+ |
2697 | | T2 | | | | T2 | | | | T2 | |
2698 | +----+ | | +----+ | | +----+ |
2701 | +--+ +--+ | | +---+ | | +--+ |
2704 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
2705 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
2706 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
2707 +------------------+ +------------------+ +------------------+
2708 1. No Topology Desc. 2. T1, T2, Isolate 3. T3, T2, Oneway
2710 +------------------+ +------------------+ +------------------+
2711 | +----+ | | +----+ | | +----+ |
2712 | | T2 | | | | T2 | | | | T2 | |
2713 | +----+ | | +----+ | | +----+ |
2716 | +--+ | | +---+ | | +--+ +--+ |
2719 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
2720 | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
2721 | +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
2722 +------------------+ +------------------+ +------------------+
2723 4. T2, T3 oneway 5. T2, T3 bothway 6. T1, T2 bothway
2725 Note: the direction of the arrow indicates the direction of flow.
2727 Figure 7: Example topologies
2729 Topology Description
2731 1 No topology descriptors When no topology descriptors are
2732 included, all Terminations have a
2733 bothway connection to all other
2736 2 T1, T2 Isolate Removes the connection between T1 and
2737 T2. T3 has a bothway connection with
2738 both T1 and T2. T1 and T2 have bothway
2746 Groves, et al. Standards Track [Page 49]
2748 RFC 3525 Gateway Control Protocol June 2003
2751 3 T3, T2 oneway A oneway connection from T3 to T2 (i.e.,
2752 T2 receives media flow from T3). A
2753 bothway connection between T1 and T3.
2755 4 T2, T3 oneway A oneway connection between T2 to T3.
2756 T1 and T3 remain bothway connected.
2758 5 T2, T3 bothway T2 is bothway connected to T3. This
2759 results in the same as 2.
2761 6 T1, T2 bothway (T2, T3 All Terminations have a bothway
2762 bothway and T1, T3 connection to all other Terminations.
2763 bothway may be implied or
2766 A oneway connection must be implemented in such a way that the other
2767 Terminations in the Context are not aware of the change in topology.
2769 7.1.19 Error Descriptor
2771 If a responder encounters an error when processing a transaction
2772 request, it must include an error descriptor in its response. A
2773 Notify request may contain an error descriptor as well.
2775 An error descriptor consists of an IANA-registered error code,
2776 optionally accompanied by an error text. H.248.8 contains a list of
2777 valid error codes and error descriptions.
2779 An error descriptor shall be specified at the "deepest level" that is
2780 semantically appropriate for the error being described and that is
2781 possible given any parsing problems with the original request. An
2782 error descriptor may refer to a syntactical construct other than
2783 where it appears. For example, Error descriptor 422 - Syntax Error
2784 in Action, could appear within a command even though it refers to the
2785 larger construct - the action - and not the particular command within
2788 7.2 Command Application Programming Interface
2790 Following is an Application Programming Interface (API) describing
2791 the Commands of the protocol. This API is shown to illustrate the
2792 Commands and their parameters and is not intended to specify
2793 implementation (e.g., via use of blocking function calls). It
2794 describes the input parameters in parentheses after the command name
2795 and the return values in front of the Command. This is only for
2796 descriptive purposes; the actual Command syntax and encoding are
2802 Groves, et al. Standards Track [Page 50]
2804 RFC 3525 Gateway Control Protocol June 2003
2807 specified in later subclauses. The order of parameters to commands
2808 is not fixed. Descriptors may appear as parameters to commands in
2809 any order. The descriptors SHALL be processed in the order in which
2812 Any reply to a command may contain an error descriptor; the API does
2813 not specifically show this.
2815 All parameters enclosed by square brackets ([. . .]) are considered
2820 The Add Command adds a Termination to a Context.
2827 [,SignalsDescriptor]
2828 [,DigitMapDescriptor]
2829 [,ObservedEventsDescriptor]
2830 [,EventBufferDescriptor]
2831 [,StatisticsDescriptor]
2832 [,PackagesDescriptor]
2837 [, EventsDescriptor]
2838 [, EventBufferDescriptor]
2839 [, SignalsDescriptor]
2840 [, DigitMapDescriptor]
2844 The TerminationID specifies the Termination to be added to the
2845 Context. The Termination is either created, or taken from the null
2846 Context. If a CHOOSE wildcard is used in the TerminationID, the
2847 selected TerminationID will be returned. Wildcards may be used in an
2848 Add, but such usage would be unusual. If the wildcard matches more
2849 than one TerminationID, all possible matches are attempted, with
2850 results reported for each one. The order of attempts when multiple
2851 TerminationIDs match is not specified.
2853 The optional MediaDescriptor describes all media streams.
2858 Groves, et al. Standards Track [Page 51]
2860 RFC 3525 Gateway Control Protocol June 2003
2863 The optional ModemDescriptor and MuxDescriptor specify a modem and
2864 multiplexer if applicable. For convenience, if a Multiplex
2865 descriptor is present in an Add command and lists any Terminations
2866 that are not currently in the Context, such Terminations are added to
2867 the Context as if individual Add commands listing the Terminations
2868 were invoked. If an error occurs on such an implied Add, error 471 -
2869 Implied Add for Multiplex failure shall be returned and further
2870 processing of the command shall cease.
2872 The EventsDescriptor parameter is optional. If present, it provides
2873 the list of events that should be detected on the Termination.
2875 The EventBufferDescriptor parameter is optional. If present, it
2876 provides the list of events that the MG is requested to detect and
2877 buffer when EventBufferControl equals LockStep.
2879 The SignalsDescriptor parameter is optional. If present, it provides
2880 the list of signals that should be applied to the Termination.
2882 The DigitMapDescriptor parameter is optional. If present, it defines
2883 a DigitMap definition that may be used in an EventsDescriptor.
2885 The AuditDescriptor is optional. If present, the command will return
2886 descriptors as specified in the AuditDescriptor.
2888 All descriptors that can be modified could be returned by MG if a
2889 parameter was underspecified or overspecified. ObservedEvents,
2890 Statistics, and Packages, and the EventBuffer descriptors are
2891 returned only if requested in the AuditDescriptor.
2893 Add SHALL NOT be used on a Termination with a serviceState of
2898 The Modify Command modifies the properties of a Termination.
2905 [,SignalsDescriptor]
2906 [,DigitMapDescriptor]
2907 [,ObservedEventsDescriptor]
2908 [,EventBufferDescriptor]
2909 [,StatisticsDescriptor]
2910 [,PackagesDescriptor]
2914 Groves, et al. Standards Track [Page 52]
2916 RFC 3525 Gateway Control Protocol June 2003
2919 Modify( TerminationID
2923 [, EventsDescriptor]
2924 [, EventBufferDescriptor]
2925 [, SignalsDescriptor]
2926 [, DigitMapDescriptor]
2930 The TerminationID may be specific if a single Termination in the
2931 Context is to be modified. Use of wildcards in the TerminationID may
2932 be appropriate for some operations. If the wildcard matches more
2933 than one TerminationID, all possible matches are attempted, with
2934 results reported for each one. The order of attempts when multiple
2935 TerminationIDs match is not specified. The CHOOSE option is an
2936 error, as the Modify command may only be used on existing
2939 For convenience, if a Multiplex Descriptor is present in a Modify
2942 - if the new Multiplex Descriptor lists any Terminations that are
2943 not currently in the Context, such Terminations are added to the
2944 context as if individual commands listing the Terminations were
2947 - if any Terminations listed previously in the Multiplex Descriptor
2948 are no longer present in the new Multiplex Descriptor, they are
2949 subtracted from the context as if individual Subtract commands
2950 listing the Terminations were invoked.
2952 The remaining parameters to Modify are the same as those to Add.
2953 Possible return values are the same as those to Add.
2957 The Subtract Command disconnects a Termination from its Context and
2958 returns statistics on the Termination's participation in the Context.
2965 [,SignalsDescriptor]
2966 [,DigitMapDescriptor]
2970 Groves, et al. Standards Track [Page 53]
2972 RFC 3525 Gateway Control Protocol June 2003
2975 [,ObservedEventsDescriptor]
2976 [,EventBufferDescriptor]
2977 [,StatisticsDescriptor]
2978 [,PackagesDescriptor]
2979 Subtract(TerminationID
2983 TerminationID in the input parameters represents the Termination that
2984 is being subtracted. The TerminationID may be specific or may be a
2985 wildcard value indicating that all (or a set of related) Terminations
2986 in the Context of the Subtract Command are to be subtracted. If the
2987 wildcard matches more than one TerminationID, all possible matches
2988 are attempted, with results reported for each one. The order of
2989 attempts when multiple TerminationIDs match is not specified.
2991 The use of CHOOSE in the TerminationID is an error, as the Subtract
2992 command may only be used on existing Terminations.
2994 ALL may be used as the ContextID as well as the TerminationId in a
2995 Subtract, which would have the effect of deleting all Contexts,
2996 deleting all ephemeral Terminations, and returning all physical
2997 Terminations to Null Context. Subtract of a termination from the
2998 Null Context is not allowed.
3000 For convenience, if a multiplexing Termination is the object of a
3001 Subtract command, then any bearer Terminations listed in its
3002 Multiplex Descriptor are subtracted from the context as if individual
3003 Subtract commands listing the Terminations were invoked.
3005 By default, the Statistics parameter is returned to report
3006 information collected on the Termination or Terminations specified in
3007 the Command. The information reported applies to the Termination's
3008 or Terminations' existence in the Context from which it or they are
3011 The AuditDescriptor is optional. If present, the command will return
3012 only those descriptors as specified in the AuditDescriptor, which may
3013 be empty. If omitted, the Statistics descriptor is returned, by
3014 default. Possible return values are the same as those to Add.
3016 When a provisioned Termination is Subtracted from a Context, its
3017 property values shall revert to:
3019 - the default value, if specified for the property and not
3020 overridden by provisioning;
3022 - otherwise, the provisioned value.
3026 Groves, et al. Standards Track [Page 54]
3028 RFC 3525 Gateway Control Protocol June 2003
3033 The Move Command moves a Termination to another Context from its
3034 current Context in one atomic operation. The Move command is the
3035 only command that refers to a Termination in a Context different from
3036 that to which the command is applied. The Move command shall not be
3037 used to move Terminations to or from the null Context.
3044 [,SignalsDescriptor]
3045 [,DigitMapDescriptor]
3046 [,ObservedEventsDescriptor]
3047 [,EventBufferDescriptor]
3048 [,StatisticsDescriptor]
3049 [,PackagesDescriptor]
3054 [, EventsDescriptor]
3055 [, EventBufferDescriptor]
3056 [, SignalsDescriptor]
3057 [, DigitMapDescriptor]
3061 The TerminationID specifies the Termination to be moved. It may be
3062 wildcarded, but CHOOSE shall not be used in the TerminationID. If
3063 the wildcard matches more than one TerminationID, all possible
3064 matches are attempted, with results reported for each one. The order
3065 of attempts when multiple TerminationIDs match is not specified. The
3066 Context to which the Termination is moved is indicated by the target
3067 ContextId in the Action. If the last remaining Termination is moved
3068 out of a Context, the Context is deleted.
3070 The Move command does not affect the properties of the Termination on
3071 which it operates, except those properties explicitly modified by
3072 descriptors included in the Move command. The AuditDescriptor with
3073 the Statistics option, for example, would return statistics on the
3074 Termination just prior to the Move. Possible descriptors returned
3075 from Move are the same as for Add.
3082 Groves, et al. Standards Track [Page 55]
3084 RFC 3525 Gateway Control Protocol June 2003
3087 For convenience, if a multiplexing Termination is the object of a
3088 Move command, then any bearer Terminations listed in its Multiplex
3089 Descriptor are also moved as if individual Move commands listing the
3090 Terminations were invoked.
3092 Move SHALL NOT be used on a Termination with a serviceState of
3097 The AuditValue Command returns the current values of properties,
3098 events, signals and statistics associated with Terminations.
3105 [,SignalsDescriptor]
3106 [,DigitMapDescriptor]
3107 [,ObservedEventsDescriptor]
3108 [,EventBufferDescriptor]
3109 [,StatisticsDescriptor]
3110 [,PackagesDescriptor]
3111 AuditValue(TerminationID,
3115 TerminationID may be specific or wildcarded. If the wildcard matches
3116 more than one TerminationID, all possible matches are attempted, with
3117 results reported for each one. The order of attempts when multiple
3118 TerminationIDs match is not specified. If a wildcarded response is
3119 requested, only one command return is generated, with the contents
3120 containing the union of the values of all Terminations matching the
3121 wildcard. This convention may reduce the volume of data required to
3122 audit a group of Terminations. Use of CHOOSE is an error.
3124 The appropriate descriptors, with the current values for the
3125 Termination, are returned from AuditValue. Values appearing in
3126 multiple instances of a descriptor are defined to be alternate values
3127 supported, with each parameter in a descriptor considered
3130 ObservedEvents returns a list of events in the EventBuffer. If the
3131 ObservedEventsDescriptor is audited while a DigitMap is active, the
3132 returned ObservedEvents descriptor also includes a digit map
3133 completion event that shows the current dial string but does not show
3134 a Termination method.
3138 Groves, et al. Standards Track [Page 56]
3140 RFC 3525 Gateway Control Protocol June 2003
3143 EventBuffer returns the set of events and associated parameter values
3144 currently enabled in the EventBufferDescriptor. PackagesDescriptor
3145 returns a list of packages realized by the Termination.
3146 DigitMapDescriptor returns the name or value of the current DigitMap
3147 for the Termination. DigitMap requested in an AuditValue command
3148 with TerminationID ALL returns all DigitMaps in the gateway.
3149 Statistics returns the current values of all statistics being kept on
3150 the Termination. Specifying an empty Audit descriptor results in
3151 only the TerminationID being returned. This may be useful to get a
3152 list of TerminationIDs when used with wildcard. Annexes A and B
3153 provide a special syntax for presenting such a list in condensed
3154 form, such that the AuditValue command tag does not have to be
3155 repeated for each TerminationID.
3157 AuditValue results depend on the Context, viz. specific, null, or
3158 wildcarded. (Note that ContextID ALL does not include the null
3159 Context.) The TerminationID may be specific, or wildcarded.
3161 The following are examples of what is returned in case the context
3162 and/or the termination is wildcarded and a wildcarded response has
3165 Assume that the gateway has 4 terminations: t1/1, t1/2, t2/1 and
3166 t2/2. Assume that terminations t1/* have implemented packages aaa
3167 and bbb and that terminations t2/* have implemented packages ccc and
3168 ddd. Assume that Context 1 has t1/1 and t2/1 in it and that Context
3169 2 has t1/2 and t2/2 in it.
3173 Context=1{AuditValue=t1/1{Audit{Packages}}}
3177 Context=1{AuditValue=t1/1{Packages{aaa,bbb}}}
3181 Context=*{AuditValue=t2/*{Audit{Packages}}}
3185 Context=1{AuditValue=t2/1{Packages{ccc,ddd}}},
3186 Context=2{AuditValue=t2/2{Packages{ccc,ddd}}}
3190 Context=*{W-AuditValue=t1/*{Audit{Packages}}}
3194 Groves, et al. Standards Track [Page 57]
3196 RFC 3525 Gateway Control Protocol June 2003
3201 Context=*{W-AuditValue=t1/*{Packages{aaa,bbb}}}
3203 Note: A wildcard response may also be used for other commands such as
3206 The following illustrates other information that can be obtained with
3207 the AuditValue Command:
3209 ContextID TerminationID Information Obtained
3211 Specific wildcard Audit of matching Terminations in a Context
3213 Specific specific Audit of a single Termination in a Context
3215 Null Root Audit of Media Gateway state and events
3217 Null wildcard Audit of all matching Terminations in the
3220 Null specific Audit of a single Termination outside of any
3223 All wildcard Audit of all matching Terminations and the
3224 Context to which they are associated
3226 All Root List of all ContextIds (the ContextID list
3227 should be returned by using multiple action
3228 replies, each containing a ContextID from
3231 All Specific (Non-null) ContextID in which the
3232 Termination currently exists
3250 Groves, et al. Standards Track [Page 58]
3252 RFC 3525 Gateway Control Protocol June 2003
3255 7.2.6 AuditCapabilities
3257 The AuditCapabilities Command returns the possible values of
3258 properties, events, signals and statistics associated with
3266 [,SignalsDescriptor]
3267 [,ObservedEventsDescriptor]
3268 [,EventBufferDescriptor]
3269 [,StatisticsDescriptor]
3270 AuditCapabilities(TerminationID,
3274 The appropriate descriptors, with the possible values for the
3275 Termination are returned from AuditCapabilities. Descriptors may be
3276 repeated where there are multiple possible values. If a wildcarded
3277 response is requested, only one command return is generated, with the
3278 contents containing the union of the values of all Terminations
3279 matching the wildcard. This convention may reduce the volume of data
3280 required to audit a group of Terminations.
3282 Interpretation of what capabilities are requested for various values
3283 of ContextID and TerminationID is the same as in AuditValue.
3285 The EventsDescriptor returns the list of possible events on the
3286 Termination together with the list of all possible values for the
3287 EventsDescriptor Parameters. EventBufferDescriptor returns the same
3288 information as EventsDescriptor. The SignalsDescriptor returns the
3289 list of possible signals that could be applied to the Termination
3290 together with the list of all possible values for the Signals
3291 Parameters. StatisticsDescriptor returns the names of the statistics
3292 being kept on the termination. ObservedEventsDescriptor returns the
3293 names of active events on the Termination. DigitMap and Packages are
3294 not legal in AuditCapability.
3306 Groves, et al. Standards Track [Page 59]
3308 RFC 3525 Gateway Control Protocol June 2003
3311 The following illustrates other information that can be obtained with
3312 the AuditCapabilties Command:
3314 ContextID TerminationID Information Obtained
3316 Specific wildcard Audit of matching Terminations in a Context
3318 Specific specific Audit of a single Termination in a Context
3320 Null Root Audit of MG state and events
3322 Null wildcard Audit of all matching Terminations in the
3325 Null specific Audit of a single Termination outside of any
3328 All wildcard Audit of all matching Terminations and the
3329 Context to which they are associated
3331 All Root Same as for AuditValue
3333 All Specific Same as for AuditValue
3337 The Notify Command allows the Media Gateway to notify the Media
3338 Gateway Controller of events occurring within the Media Gateway.
3341 Notify(TerminationID,
3342 ObservedEventsDescriptor,
3346 The TerminationID parameter specifies the Termination issuing the
3347 Notify Command. The TerminationID shall be a fully qualified name.
3349 The ObservedEventsDescriptor contains the RequestID and a list of
3350 events that the Media Gateway detected in the order that they were
3351 detected. Each event in the list is accompanied by parameters
3352 associated with the event and optionally an indication of the time
3353 that the event was detected. Procedures for sending Notify commands
3354 with RequestID equal to 0 are for further study.
3356 Notify Commands with RequestID not equal to 0 shall occur only as the
3357 result of detection of an event specified by an Events descriptor
3358 which is active on the Termination concerned.
3362 Groves, et al. Standards Track [Page 60]
3364 RFC 3525 Gateway Control Protocol June 2003
3367 The RequestID returns the RequestID parameter of the EventsDescriptor
3368 that triggered the Notify Command. It is used to correlate the
3369 notification with the request that triggered it. The events in the
3370 list must have been requested via the triggering EventsDescriptor or
3371 embedded events descriptor unless the RequestID is 0 (which is for
3374 The ErrorDescriptor may be sent in the Notify Command as a result of
3375 Error 518 - Event buffer full.
3379 The ServiceChange Command allows the Media Gateway to notify the
3380 Media Gateway Controller that a Termination or group of Terminations
3381 is about to be taken out of service or has just been returned to
3382 service. The Media Gateway Controller may indicate that
3383 Termination(s) shall be taken out of or returned to service. The
3384 Media Gateway may notify the MGC that the capability of a Termination
3385 has changed. It also allows a MGC to hand over control of a MG to
3390 [ServiceChangeDescriptor]
3391 ServiceChange ( TerminationID,
3392 ServiceChangeDescriptor
3395 The TerminationID parameter specifies the Termination(s) that are
3396 taken out of or returned to service. Wildcarding of Termination
3397 names is permitted, with the exception that the CHOOSE mechanism
3398 shall not be used. Use of the "Root" TerminationID indicates a
3399 ServiceChange affecting the entire Media Gateway.
3401 The ServiceChangeDescriptor contains the following parameters as
3404 - ServiceChangeMethod
3405 - ServiceChangeReason
3406 - ServiceChangeDelay
3407 - ServiceChangeAddress
3408 - ServiceChangeProfile
3409 - ServiceChangeVersion
3410 - ServiceChangeMgcId
3418 Groves, et al. Standards Track [Page 61]
3420 RFC 3525 Gateway Control Protocol June 2003
3423 The ServiceChangeMethod parameter specifies the type of ServiceChange
3424 that will or has occurred:
3426 1) Graceful - indicates that the specified Terminations will be taken
3427 out of service after the specified ServiceChangeDelay; established
3428 connections are not yet affected, but the Media Gateway Controller
3429 should refrain from establishing new connections and should
3430 attempt to gracefully tear down existing connections on the
3431 Termination(s) affected by the serviceChange command. The MG
3432 should set Termination serviceState at the expiry of
3433 ServiceChangeDelay or the removal of the Termination from an
3434 active Context (whichever is first), to "out of service".
3436 2) Forced - indicates that the specified Terminations were taken
3437 abruptly out of service and any established connections associated
3438 with them may be lost. For non-Root terminations, the MGC is
3439 responsible for cleaning up the Context (if any) with which the
3440 failed Termination is associated. At a minimum the Termination
3441 shall be subtracted from the Context. The Termination
3442 serviceState should be "out of service". For the root
3443 termination, the MGC can assume that all connections are lost on
3444 the MG and thus can consider that all the terminations have been
3447 3) Restart - indicates that service will be restored on the specified
3448 Terminations after expiration of the ServiceChangeDelay. The
3449 serviceState should be set to "inService" upon expiry of
3452 4) Disconnected - always applied with the Root TerminationID,
3453 indicates that the MG lost communication with the MGC, but it was
3454 subsequently restored to the same MGC (possibly after trying other
3455 MGCs on a pre-provisioned list). Since MG state may have changed,
3456 the MGC may wish to use the Audit command to resynchronize its
3457 state with the MG's.
3459 5) Handoff - sent from the MGC to the MG, this reason indicates that
3460 the MGC is going out of service and a new MGC association must be
3461 established. Sent from the MG to the MGC, this indicates that the
3462 MG is attempting to establish a new association in accordance with
3463 a Handoff received from the MGC with which it was previously
3466 6) Failover - sent from MG to MGC to indicate the primary MG is out
3467 of service and a secondary MG is taking over. This serviceChange
3468 method is also sent from the MG to the MGC when the MG detects
3469 that MGC has failed.
3474 Groves, et al. Standards Track [Page 62]
3476 RFC 3525 Gateway Control Protocol June 2003
3479 7) Another value whose meaning is mutually understood between the MG
3482 The ServiceChangeReason parameter specifies the reason why the
3483 ServiceChange has or will occur. It consists of an alphanumeric
3484 token (IANA registered) and, optionally, an explanatory string.
3486 The optional ServiceChangeAddress parameter specifies the address
3487 (e.g., IP port number for IP networks) to be used for subsequent
3488 communications. It can be specified in the input parameter
3489 descriptor or the returned result descriptor. ServiceChangeAddress
3490 and ServiceChangeMgcId parameters must not both be present in the
3491 ServiceChangeDescriptor or the ServiceChangeResultDescriptor. The
3492 ServiceChangeAddress provides an address to be used within the
3493 Context of the association currently being negotiated, while the
3494 ServiceChangeMgcId provides an alternate address where the MG should
3495 seek to establish another association. Note that the use of
3496 ServiceChangeAddress is not encouraged. MGCs and MGs must be able to
3497 cope with the ServiceChangeAddress being either a full address or
3498 just a port number in the case of TCP transports.
3500 The optional ServiceChangeDelay parameter is expressed in seconds.
3501 If the delay is absent or set to zero, the delay value should be
3502 considered to be null. In the case of a "graceful"
3503 ServiceChangeMethod, a null delay indicates that the Media Gateway
3504 Controller should wait for the natural removal of existing
3505 connections and should not establish new connections. For "graceful"
3506 only, a null delay means the MG must not set serviceState "out of
3507 service" until the Termination is in the null Context.
3509 The optional ServiceChangeProfile parameter specifies the Profile (if
3510 any) of the protocol supported. The ServiceChangeProfile includes
3511 the version of the profile supported.
3513 The optional ServiceChangeVersion parameter contains the protocol
3514 version and is used if protocol version negotiation occurs (see
3517 The optional TimeStamp parameter specifies the actual time as kept by
3518 the sender. As such, it is not necessarily absolute time according
3519 to, for example, a local time zone - it merely establishes an
3520 arbitrary starting time against which all future timestamps
3521 transmitted by a sender during this association shall be compared.
3522 It can be used by the responder to determine how its notion of time
3523 differs from that of its correspondent. TimeStamp is sent with a
3524 precision of hundredths of a second.
3530 Groves, et al. Standards Track [Page 63]
3532 RFC 3525 Gateway Control Protocol June 2003
3535 The optional Extension parameter may contain any value whose meaning
3536 is mutually understood by the MG and MGC.
3538 A ServiceChange Command specifying the "Root" for the TerminationID
3539 and ServiceChangeMethod equal to Restart is a registration command by
3540 which a Media Gateway announces its existence to the Media Gateway
3541 Controller. The Media Gateway may also announce a registration
3542 command by specifying the "Root" for the TerminationID and
3543 ServiceChangeMethod equal to Failover when the MG detects MGC
3544 failures. The Media Gateway is expected to be provisioned with the
3545 name of one primary and optionally some number of alternate Media
3546 Gateway Controllers. Acknowledgement of the ServiceChange Command
3547 completes the registration process, except when the MGC has returned
3548 an alternative ServiceChangeMgcId as described in the following
3549 paragraph. The MG may specify the transport ServiceChangeAddress to
3550 be used by the MGC for sending messages in the ServiceChangeAddress
3551 parameter in the input ServiceChangeDescriptor. The MG may specify
3552 an address in the ServiceChangeAddress parameter of the ServiceChange
3553 request, and the MGC may also do so in the ServiceChange reply. In
3554 either case, the recipient must use the supplied address as the
3555 destination for all subsequent transaction requests within the
3556 association. At the same time, as indicated in clause 9, transaction
3557 replies and pending indications must be sent to the address from
3558 which the corresponding requests originated. This must be done even
3559 if it implies extra messaging because commands and responses cannot
3560 be packed together. The TimeStamp parameter shall be sent with a
3561 registration command and its response.
3563 The Media Gateway Controller may return a ServiceChangeMgcId
3564 parameter that describes the Media Gateway Controller that should
3565 preferably be contacted for further service by the Media Gateway. In
3566 this case the Media Gateway shall reissue the ServiceChange command
3567 to the new Media Gateway Controller. The MGC specified in a
3568 ServiceChangeMgcId, if provided, shall be contacted before any
3569 further alternate MGCs. On a HandOff message from MGC to MG, the
3570 ServiceChangeMgcId is the new MGC that will take over from the
3573 The return from ServiceChange is empty except when the Root
3574 terminationID is used. In that case it includes the following
3575 parameters as required:
3577 - ServiceChangeAddress, if the responding MGC wishes to specify a
3578 new destination for messages from the MG for the remainder of the
3581 - ServiceChangeMgcId, if the responding MGC does not wish to sustain
3582 an association with the MG;
3586 Groves, et al. Standards Track [Page 64]
3588 RFC 3525 Gateway Control Protocol June 2003
3591 - ServiceChangeProfile, if the responder wishes to negotiate the
3592 profile to be used for the association;
3594 - ServiceChangeVersion, if the responder wishes to negotiate the
3595 version of the protocol to be used for the association.
3597 The following ServiceChangeReasons are defined. This list may be
3598 extended by an IANA registration as outlined in 13.3.
3600 900 Service Restored
3603 903 MGC Directed Change
3604 904 Termination malfunctioning
3605 905 Termination taken out of service
3606 906 Loss of lower layer connectivity (e.g., downstream sync)
3607 907 Transmission Failure
3608 908 MG Impending Failure
3609 909 MGC Impending Failure
3610 910 Media Capability Failure
3611 911 Modem Capability Failure
3612 912 Mux Capability Failure
3613 913 Signal Capability Failure
3614 914 Event Capability Failure
3617 7.2.9 Manipulating and Auditing Context Attributes
3619 The commands of the protocol as discussed in the preceding subclauses
3620 apply to Terminations. This subclause specifies how Contexts are
3621 manipulated and audited.
3623 Commands are grouped into actions (see clause 8). An action applies
3624 to one Context. In addition to commands, an action may contain
3625 Context manipulation and auditing instructions.
3627 An action request sent to a MG may include a request to audit
3628 attributes of a Context. An action may also include a request to
3629 change the attributes of a Context.
3631 The Context properties that may be included in an action reply are
3632 used to return information to a MGC. This can be information
3633 requested by an audit of Context attributes or details of the effect
3634 of manipulation of a Context.
3642 Groves, et al. Standards Track [Page 65]
3644 RFC 3525 Gateway Control Protocol June 2003
3647 If a MG receives an action which contains both a request to audit
3648 context attributes and a request to manipulate those attributes, the
3649 response SHALL include the values of the attributes after processing
3650 the manipulation request.
3652 7.2.10 Generic Command Syntax
3654 The protocol can be encoded in a binary format or in a text format.
3655 MGCs should support both encoding formats. MGs may support both
3658 The protocol syntax for the binary format of the protocol is defined
3659 in Annex A. Annex C specifies the encoding of the Local and Remote
3660 descriptors for use with the binary format.
3662 A complete ABNF of the text encoding of the protocol per RFC 2234 is
3663 given in Annex B. SDP is used as the encoding of the Local and
3664 Remote descriptors for use with the text encoding as modified in
3667 7.3 Command Error Codes
3669 Errors consist of an IANA registered error code and an explanatory
3670 string. Sending the explanatory string is optional. Implementations
3671 are encouraged to append diagnostic information to the end of the
3674 When a MG reports an error to a MGC, it does so in an error
3675 descriptor. An error descriptor consists of an error code and
3676 optionally the associated explanatory string.
3678 H.248.8 contains the error codes supported by Recommendations in the
3683 Commands between the Media Gateway Controller and the Media Gateway
3684 are grouped into Transactions, each of which is identified by a
3685 TransactionID. Transactions consist of one or more Actions. An
3686 Action consists of a non-empty series of Commands, Context property
3687 modifications, or Context property audits that are limited to
3688 operating within a single Context. Consequently, each Action
3689 typically specifies a ContextID. However, there are two
3690 circumstances where a specific ContextID is not provided with an
3691 Action. One is the case of modification of a Termination outside of
3692 a Context. The other is where the controller requests the gateway to
3693 create a new Context. Figure 8 is a graphic representation of the
3694 Transaction, Action and Command relationships.
3698 Groves, et al. Standards Track [Page 66]
3700 RFC 3525 Gateway Control Protocol June 2003
3703 +----------------------------------------------------------+
3705 | +----------------------------------------------------+ |
3707 | | +---------+ +---------+ +---------+ +---------+ | |
3708 | | | Command | | Command | | Command | | Command | | |
3709 | | | 1 | | 2 | | 3 | | 4 | | |
3710 | | +---------+ +---------+ +---------+ +---------+ | |
3711 | +----------------------------------------------------+ |
3713 | +----------------------------------------------------+ |
3719 | +----------------------------------------------------+ |
3721 | +----------------------------------------------------+ |
3723 | | +---------+ +---------+ +---------+ | |
3724 | | | Command | | Command | | Command | | |
3725 | | | 1 | | 2 | | 3 | | |
3726 | | +---------+ +---------+ +---------+ | |
3727 | +----------------------------------------------------+ |
3728 +----------------------------------------------------------+
3730 Figure 8: Transactions, Actions and Commands
3732 Transactions are presented as TransactionRequests. Corresponding
3733 responses to a TransactionRequest are received in a single reply,
3734 possibly preceded by a number of TransactionPending messages (see
3737 Transactions guarantee ordered Command processing. That is, Commands
3738 within a Transaction are executed sequentially. Ordering of
3739 Transactions is NOT guaranteed - transactions may be executed in any
3740 order, or simultaneously.
3742 At the first failing Command in a Transaction, processing of the
3743 remaining Commands in that Transaction stops. If a command contains
3744 a wildcarded TerminationID, the command is attempted with each of the
3745 actual TerminationIDs matching the wildcard. A response within the
3746 TransactionReply is included for each matching TerminationID, even if
3747 one or more instances generated an error. If any TerminationID
3748 matching a wildcard results in an error when executed, any commands
3749 following the wildcarded command are not attempted.
3754 Groves, et al. Standards Track [Page 67]
3756 RFC 3525 Gateway Control Protocol June 2003
3759 Commands may be marked as "Optional" which can override this
3760 behaviour - if a command marked as Optional results in an error,
3761 subsequent commands in the Transaction will be executed. If a
3762 command fails, the MG shall as far as possible restore the state that
3763 existed prior to the attempted execution of the command before
3764 continuing with command processing.
3766 A TransactionReply includes the results for all of the Commands in
3767 the corresponding TransactionRequest. The TransactionReply includes
3768 the return values for the Commands that were executed successfully,
3769 and the Command and error descriptor for any Command that failed.
3771 TransactionPending is used to periodically notify the receiver that a
3772 Transaction has not completed yet, but is actively being processed.
3774 Applications SHOULD implement an application level timer per
3775 transaction. Expiration of the timer should cause a retransmission
3776 of the request. Receipt of a Reply should cancel the timer. Receipt
3777 of Pending should restart the timer.
3779 8.1 Common parameters
3781 8.1.1 Transaction Identifiers
3783 Transactions are identified by a TransactionID, which is assigned by
3784 sender and is unique within the scope of the sender. A response
3785 containing an error descriptor to indicate that the TransactionID is
3786 missing in a request shall use TransactionID 0 in the corresponding
3789 8.1.2 Context Identifiers
3791 Contexts are identified by a ContextID, which is assigned by the
3792 Media Gateway and is unique within the scope of the Media Gateway.
3793 The Media Gateway Controller shall use the ContextID supplied by the
3794 Media Gateway in all subsequent Transactions relating to that
3795 Context. The protocol makes reference to a distinguished value that
3796 may be used by the Media Gateway Controller when referring to a
3797 Termination that is currently not associated with a Context, namely
3800 The CHOOSE wildcard is used to request that the Media Gateway create
3803 The MGC may use the ALL wildcard to address all Contexts on the MG.
3804 The null Context is not included when the ALL wildcard is used.
3810 Groves, et al. Standards Track [Page 68]
3812 RFC 3525 Gateway Control Protocol June 2003
3815 The MGC shall not use partially specified ContextIDs containing the
3816 CHOOSE or ALL wildcards.
3818 8.2 Transaction Application Programming Interface
3820 Following is an Application Programming Interface (API) describing
3821 the Transactions of the protocol. This API is shown to illustrate
3822 the Transactions and their parameters and is not intended to specify
3823 implementation (e.g., via use of blocking function calls). It will
3824 describe the input parameters and return values expected to be used
3825 by the various Transactions of the protocol from a very high level.
3826 Transaction syntax and encodings are specified in later subclauses.
3828 8.2.1 TransactionRequest
3830 The TransactionRequest is invoked by the sender. There is one
3831 Transaction per request invocation. A request contains one or more
3832 Actions, each of which specifies its target Context and one or more
3833 Commands per Context.
3835 TransactionRequest(TransactionId {
3836 ContextID {Command ... Command},
3838 ContextID {Command ... Command } })
3840 The TransactionID parameter must specify a value for later
3841 correlation with the TransactionReply or TransactionPending response
3844 The ContextID parameter must specify a value to pertain to all
3845 Commands that follow up to either the next specification of a
3846 ContextID parameter or the end of the TransactionRequest, whichever
3849 The Command parameter represents one of the Commands mentioned in 7.2
3850 (Command Application Programming Interface).
3852 8.2.2 TransactionReply
3854 The TransactionReply is invoked by the receiver. There is one reply
3855 invocation per transaction. A reply contains one or more Actions,
3856 each of which must specify its target Context and one or more
3857 Responses per Context. The TransactionReply is invoked by the
3858 responder when it has processed the TransactionRequest.
3866 Groves, et al. Standards Track [Page 69]
3868 RFC 3525 Gateway Control Protocol June 2003
3871 A TransactionRequest has been processed:
3873 - when all actions in that TransactionRequest have been processed;
3876 - when an error is encountered in processing that
3877 TransactionRequest, except when the error is in an optional
3880 A command has been processed when all descriptors in that command
3881 have been processed.
3883 A SignalsDescriptor is considered to have been processed when it has
3884 been established that the descriptor is syntactically valid, the
3885 requested signals are supported and they have been queued to be
3888 An EventsDescriptor or EventBufferDescriptor is considered to have
3889 been processed when it has been established that the descriptor is
3890 syntactically valid, the requested events can be observed, any
3891 embedded signals can be generated, any embedded events can be
3892 detected, and the MG has been brought into a state in which the
3893 events will be detected.
3895 TransactionReply(TransactionID {
3896 ContextID { Response ... Response },
3898 ContextID { Response ... Response } })
3900 The TransactionID parameter must be the same as that of the
3901 corresponding TransactionRequest.
3903 The ContextID parameter must specify a value to pertain to all
3904 Responses for the action. The ContextID may be specific, all or
3907 Each of the Response parameters represents a return value as
3908 mentioned in 7.2, or an error descriptor if the command execution
3909 encountered an error. Commands after the point of failure are not
3910 processed and, therefore, Responses are not issued for them.
3912 An exception to this occurs if a command has been marked as optional
3913 in the Transaction request. If the optional command generates an
3914 error, the transaction still continues to execute, so the Reply
3915 would, in this case, have Responses after an Error.
3917 Section 7.1.19 Error Descriptor specifies the generation of error
3918 descriptors. The text below discusses several individual cases.
3922 Groves, et al. Standards Track [Page 70]
3924 RFC 3525 Gateway Control Protocol June 2003
3927 If the receiver encounters an error in processing a ContextID, the
3928 requested Action response will consist of the Context ID and a single
3929 error descriptor, 422 - Syntax Error in Action.
3931 If the receiver encounters an error such that it cannot determine a
3932 legal Action, it will return a TransactionReply consisting of the
3933 TransactionID and a single error descriptor, 422 - Syntax Error in
3934 Action. If the end of an action cannot be reliably determined but
3935 one or more commands can be parsed, it will process them and then
3936 send 422 - Syntax Error in Action as the last action for the
3937 transaction. If the receiver encounters an error such that is cannot
3938 determine a legal Transaction, it will return a TransactionReply with
3939 a null TransactionID and a single error descriptor (403 - Syntax
3940 Error in TransactionRequest).
3942 If the end of a transaction cannot be reliably determined and one or
3943 more Actions can be parsed, it will process them and then return 403
3944 - Syntax Error in Transaction as the last action reply for the
3945 transaction. If no Actions can be parsed, it will return 403 -
3946 Syntax Error in TransactionRequest as the only reply.
3948 If the terminationID cannot be reliably determined, it will send 442
3949 - Syntax Error in Command as the action reply.
3951 If the end of a command cannot be reliably determined, it will return
3952 442 - Syntax Error in Command as the reply to the last action it can
3955 8.2.3 TransactionPending
3957 The receiver invokes the TransactionPending. A TransactionPending
3958 indicates that the Transaction is actively being processed, but has
3959 not been completed. It is used to prevent the sender from assuming
3960 the TransactionRequest was lost where the Transaction will take some
3963 TransactionPending(TransactionID { } )
3965 The TransactionID parameter must be the same as that of the
3966 corresponding TransactionRequest. A property of root
3967 (normalMGExecutionTime) is settable by the MGC to indicate the
3968 interval within which the MGC expects a response to any transaction
3969 from the MG. Another property (normalMGCExecutionTime) is settable
3970 by the MGC to indicate the interval within which the MG should expect
3971 a response to any transaction from the MGC. Senders may receive more
3972 than one TransactionPending for a command. If a duplicate request is
3978 Groves, et al. Standards Track [Page 71]
3980 RFC 3525 Gateway Control Protocol June 2003
3983 received when pending, the responder may send a duplicate pending
3984 immediately, or continue waiting for its timer to trigger another
3989 Multiple Transactions can be concatenated into a Message. Messages
3990 have a header, which includes the identity of the sender. The
3991 Message Identifier (MID) of a message is set to a provisioned name
3992 (e.g., domain address/domain name/device name) of the entity
3993 transmitting the message. Domain name is a suggested default. An
3994 H.248.1 entity (MG/MGC) must consistently use the same MID in all
3995 messages it originates for the duration of control association with
3998 Every Message contains a Version Number identifying the version of
3999 the protocol the message conforms to. Versions consist of one or two
4000 digits, beginning with version 1 for the present version of the
4003 The transactions in a message are treated independently. There is no
4004 order implied; there is no application or protocol acknowledgement of
4005 a message. A message is essentially a transport mechanism. For
4006 example, message X containing transaction requests A, B, and C may be
4007 responded to with message Y containing replies to A and C and message
4008 Z containing the reply to B. Likewise, message L containing request
4009 D and message M containing request E may be responded to with message
4010 N containing replies to both D and E.
4014 The transport mechanism for the protocol should allow the reliable
4015 transport of transactions between a MGC and MG. The transport shall
4016 remain independent of what particular commands are being sent and
4017 shall be applicable to all application states. There are several
4018 transports defined for the protocol, which are defined in Annexes to
4019 this RFC and other Recommendations of the H.248
4020 sub-series. Additional Transports may be defined as additional
4022 Recommendations of the H.248 sub-series. For transport of the
4023 protocol over IP, MGCs shall implement both TCP and UDP/ALF, a MG
4024 shall implement TCP or UDP/ALF or both.
4026 The MG is provisioned with a name or address (such as DNS name or IP
4027 address) of a primary and zero or more secondary MGCs (see 7.2.8)
4028 that is the address the MG uses to send messages to the MGC. If TCP
4029 or UDP is used as the protocol transport and the port to which the
4030 initial ServiceChange request is to be sent is not otherwise known,
4034 Groves, et al. Standards Track [Page 72]
4036 RFC 3525 Gateway Control Protocol June 2003
4039 that request should be sent to the default port number for the
4040 protocol. This port number is 2944 for text-encoded operation or
4041 2945 for binary-encoded operation, for either UDP or TCP. The MGC
4042 receives the message containing the ServiceChange request from the MG
4043 and can determine the MG's address from it. As described in 7.2.8,
4044 either the MG or the MGC may supply an address in the
4045 ServiceChangeAddress parameter to which subsequent transaction
4046 requests must be addressed, but responses (including the response to
4047 the initial ServiceChange request) must always be sent back to the
4048 address which was the source of the corresponding request. For
4049 example, in IP networks, this is the source address in the IP header
4050 and the source port number in the TCP/UDP/SCTP header.
4052 9.1 Ordering of Commands
4054 This RFC does not mandate that the underlying transport protocol
4055 guarantees the sequencing of transactions sent to an entity. This
4056 property tends to maximize the timeliness of actions, but it has a
4057 few drawbacks. For example:
4059 - Notify commands may be delayed and arrive at the MGC after the
4060 transmission of a new command changing the EventsDescriptor.
4062 - If a new command is transmitted before a previous one is
4063 acknowledged, there is no guarantee that prior command will be
4064 executed before the new one.
4066 Media Gateway Controllers that want to guarantee consistent operation
4067 of the Media Gateway may use the following rules. These rules are
4068 with respect to commands that are in different transactions.
4069 Commands that are in the same transaction are executed in order (see
4072 1) When a Media Gateway handles several Terminations, commands
4073 pertaining to the different Terminations may be sent in parallel,
4074 for example following a model where each Termination (or group of
4075 Terminations) is controlled by its own process or its own thread.
4077 2) On a Termination, there should normally be at most one outstanding
4078 command (Add or Modify or Move), unless the outstanding commands
4079 are in the same transaction. However, a Subtract command may be
4080 issued at any time. In consequence, a Media Gateway may sometimes
4081 receive a Modify command that applies to a previously subtracted
4082 Termination. Such commands should be ignored, and an error code
4090 Groves, et al. Standards Track [Page 73]
4092 RFC 3525 Gateway Control Protocol June 2003
4095 3) For transports that do not guarantee in-sequence delivery of
4096 messages (i.e., UDP), there should normally be on a given
4097 Termination at most one outstanding Notify command at any time.
4099 4) In some cases, an implicitly or explicitly wildcarded Subtract
4100 command that applies to a group of Terminations may step in front
4101 of a pending Add command. The Media Gateway Controller should
4102 individually delete all Terminations for which an Add command was
4103 pending at the time of the global Subtract command. Also, new Add
4104 commands for Terminations named by the wildcarding (or implied in
4105 a Multiplex descriptor) should not be sent until the wildcarded
4106 Subtract command is acknowledged.
4108 5) AuditValue and AuditCapability are not subject to any sequencing.
4110 6) ServiceChange shall always be the first command sent by a MG as
4111 defined by the restart procedure. Any other command or response
4112 must be delivered after this ServiceChange command.
4114 These rules do not affect the command responder, which should always
4115 respond to commands.
4117 9.2 Protection against Restart Avalanche
4119 In the event that a large number of Media Gateways are powered on
4120 simultaneously and they were to all initiate a ServiceChange
4121 transaction, the Media Gateway Controller would very likely be
4122 swamped, leading to message losses and network congestion during the
4123 critical period of service restoration. In order to prevent such
4124 avalanches, the following behaviour is suggested:
4126 1) When a Media Gateway is powered on, it should initiate a restart
4127 timer to a random value, uniformly distributed between 0 and a
4128 maximum waiting delay (MWD). Care should be taken to avoid
4129 synchronicity of the random number generation between multiple
4130 Media Gateways that would use the same algorithm.
4132 2) The Media Gateway should then wait for either the end of this
4133 timer or the detection of a local user activity, such as for
4134 example an off-hook transition on a residential Media Gateway.
4136 3) When the timer elapses, or when an activity is detected, the Media
4137 Gateway should initiate the restart procedure.
4139 The restart procedure simply requires the MG to guarantee that the
4140 first message that the Media Gateway Controller sees from this MG is
4141 a ServiceChange message informing the Media Gateway Controller about
4146 Groves, et al. Standards Track [Page 74]
4148 RFC 3525 Gateway Control Protocol June 2003
4151 NOTE - The value of MWD is a configuration parameter that depends
4152 on the type of the Media Gateway. The following reasoning may be
4153 used to determine the value of this delay on residential gateways.
4155 Media Gateway Controllers are typically dimensioned to handle the
4156 peak hour traffic load, during which, in average, 10% of the lines
4157 will be busy, placing calls whose average duration is typically 3
4158 minutes. The processing of a call typically involves 5 to 6 Media
4159 Gateway Controller transactions between each Media Gateway and the
4160 Media Gateway Controller. This simple calculation shows that the
4161 Media Gateway Controller is expected to handle 5 to 6 transactions
4162 for each Termination, every 30 minutes on average, or, to put it
4163 otherwise, about one transaction per Termination every 5 to 6 minutes
4164 on average. This suggests that a reasonable value of MWD for a
4165 residential gateway would be 10 to 12 minutes. In the absence of
4166 explicit configuration, residential gateways should adopt a value of
4167 600 seconds for MWD.
4169 The same reasoning suggests that the value of MWD should be much
4170 shorter for trunking gateways or for business gateways, because they
4171 handle a large number of Terminations, and also because the usage
4172 rate of these Terminations is much higher than 10% during the peak
4173 busy hour, a typical value being 60%. These Terminations, during the
4174 peak hour, are this expected to contribute about one transaction per
4175 minute to the Media Gateway Controller load. A reasonable algorithm
4176 is to make the value of MWD per "trunk" Termination six times shorter
4177 than the MWD per residential gateway, and also inversely proportional
4178 to the number of Terminations that are being restarted. For example
4179 MWD should be set to 2.5 seconds for a gateway that handles a T1
4180 line, or to 60 milliseconds for a gateway that handles a T3 line.
4182 10 Security Considerations
4184 This clause covers security when using the protocol in an IP
4187 10.1 Protection of Protocol Connections
4189 A security mechanism is clearly needed to prevent unauthorized
4190 entities from using the protocol defined in this RFC for setting up
4191 unauthorized calls or interfering with authorized calls. The
4192 security mechanism for the protocol when transported over IP networks
4193 is IPsec [RFC 2401 to RFC 2411].
4195 The AH header [RFC 2402] affords data origin authentication,
4196 connectionless integrity and optional anti-replay protection of
4197 messages passed between the MG and the MGC. The ESP header [RFC
4198 2406] provides confidentiality of messages, if desired. For
4202 Groves, et al. Standards Track [Page 75]
4204 RFC 3525 Gateway Control Protocol June 2003
4207 instance, the ESP encryption service should be requested if the
4208 session descriptions are used to carry session keys, as defined in
4211 Implementations of the protocol defined in this RFC employing the ESP
4212 header SHALL comply with section 5 of [RFC 2406], which defines a
4213 minimum set of algorithms for integrity checking and encryption.
4214 Similarly, implementations employing the AH header SHALL comply with
4215 section 5 of [RFC 2402], which defines a minimum set of algorithms
4216 for integrity checking using manual keys.
4218 Implementations SHOULD use IKE [RFC 2409] to permit more robust
4219 keying options. Implementations employing IKE SHOULD support
4220 authentication with RSA signatures and RSA public key encryption.
4222 10.2 Interim AH scheme
4224 Implementation of IPsec requires that the AH or ESP header be
4225 inserted immediately after the IP header. This cannot be easily done
4226 at the application level. Therefore, this presents a deployment
4227 problem for the protocol defined in this RFC where the underlying
4228 network implementation does not support IPsec.
4230 As an interim solution, an optional AH header is defined within the
4231 H.248.1 protocol header. The header fields are exactly those of the
4232 SPI, SEQUENCE NUMBER and DATA fields as defined in [RFC 2402]. The
4233 semantics of the header fields are the same as the "transport mode"
4234 of [RFC 2402], except for the calculation of the Integrity Check
4235 Value (ICV). In IPsec, the ICV is calculated over the entire IP
4236 packet including the IP header. This prevents spoofing of the IP
4237 addresses. To retain the same functionality, the ICV calculation
4238 should be performed across all the transactions (concatenated) in the
4239 message prepended by a synthesized IP header consisting of a 32-bit
4240 source IP address, a 32-bit destination address and a 16-bit UDP
4241 destination port encoded as 20 hex digits. When the interim AH
4242 mechanism is employed when TCP is the transport Layer, the UDP Port
4243 above becomes the TCP port, and all other operations are the same.
4245 Implementations of the H.248.1 protocol SHALL implement IPsec where
4246 the underlying operating system and the transport network supports
4247 IPsec. Implementations of the protocol using IPv4 SHALL implement
4248 the interim AH scheme. However, this interim scheme SHALL NOT be
4249 used when the underlying network layer supports IPsec. IPv6
4250 implementations are assumed to support IPsec and SHALL NOT use the
4258 Groves, et al. Standards Track [Page 76]
4260 RFC 3525 Gateway Control Protocol June 2003
4263 All implementations of the interim AH mechanism SHALL comply with
4264 section 5 of RFC 2402 which defines a minimum set of algorithms for
4265 integrity checking using manual keys.
4267 The interim AH interim scheme does not provide protection against
4268 eavesdropping, thus forbidding third parties from monitoring the
4269 connections set up by a given Termination. Also, it does not provide
4270 protection against replay attacks. These procedures do not
4271 necessarily protect against denial of service attacks by misbehaving
4272 MGs or misbehaving MGCs. However, they will provide an
4273 identification of these misbehaving entities, which should then be
4274 deprived of their authorization through maintenance procedures.
4276 10.3 Protection of Media Connections
4278 The protocol allows the MGC to provide MGs with "session keys" that
4279 can be used to encrypt the audio messages, protecting against
4282 A specific problem of packet networks is "uncontrolled barge-in".
4283 This attack can be performed by directing media packets to the IP
4284 address and UDP port used by a connection. If no protection is
4285 implemented, the packets must be decompressed and the signals must be
4286 played on the "line side".
4288 A basic protection against this attack is to only accept packets from
4289 known sources, checking for example that the IP source address and
4290 UDP source port match the values announced in the Remote descriptor.
4291 This has two inconveniences: it slows down connection establishment
4292 and it can be fooled by source spoofing:
4294 - To enable the address-based protection, the MGC must obtain the
4295 remote session description of the egress MG and pass it to the
4296 ingress MG. This requires at least one network round trip, and
4297 leaves us with a dilemma: either allow the call to proceed without
4298 waiting for the round trip to complete, and risk for example,
4299 "clipping" a remote announcement, or wait for the full round trip
4300 and settle for slower call-set up procedures.
4302 - Source spoofing is only effective if the attacker can obtain valid
4303 pairs of source destination addresses and ports, for example by
4304 listening to a fraction of the traffic. To fight source spoofing,
4305 one could try to control all access points to the network. But
4306 this is in practice very hard to achieve.
4314 Groves, et al. Standards Track [Page 77]
4316 RFC 3525 Gateway Control Protocol June 2003
4319 An alternative to checking the source address is to encrypt and
4320 authenticate the packets, using a secret key that is conveyed during
4321 the call set-up procedure. This will not slow down the call set-up,
4322 and provides strong protection against address spoofing.
4324 11 MG-MGC Control Interface
4326 The control association between MG and MGC is initiated at MG cold
4327 start, and announced by a ServiceChange message, but can be changed
4328 by subsequent events, such as failures or manual service events.
4329 While the protocol does not have an explicit mechanism to support
4330 multiple MGCs controlling a physical MG, it has been designed to
4331 support the multiple logical MG (within a single physical MG) that
4332 can be associated with different MGCs.
4334 11.1 Multiple Virtual MGs
4336 A physical Media Gateway may be partitioned into one or more Virtual
4337 MGs. A virtual MG consists of a set of statically partitioned
4338 physical Terminations and/or sets of ephemeral Terminations. A
4339 physical Termination is controlled by one MGC. The model does not
4340 require that other resources be statically allocated, just
4341 Terminations. The mechanism for allocating Terminations to virtual
4342 MGs is a management method outside the scope of the protocol. Each
4343 of the virtual MGs appears to the MGC as a complete MG client.
4345 A physical MG may have only one network interface, which must be
4346 shared across virtual MGs. In such a case, the packet/cell side
4347 Termination is shared. It should be noted however, that in use, such
4348 interfaces require an ephemeral instance of the Termination to be
4349 created per flow, and thus sharing the Termination is
4350 straightforward. This mechanism does lead to a complication, namely
4351 that the MG must always know which of its controlling MGCs should be
4352 notified if an event occurs on the interface.
4354 In normal operation, the Virtual MG will be instructed by the MGC to
4355 create network flows (if it is the originating side), or to expect
4356 flow requests (if it is the terminating side), and no confusion will
4357 arise. However, if an unexpected event occurs, the Virtual MG must
4358 know what to do with respect to the physical resources it is
4361 If recovering from the event requires manipulation of a physical
4362 interface's state, only one MGC should do so. These issues are
4363 resolved by allowing any of the MGCs to create EventsDescriptors to
4364 be notified of such events, but only one MGC can have read/write
4370 Groves, et al. Standards Track [Page 78]
4372 RFC 3525 Gateway Control Protocol June 2003
4375 access to the physical interface properties; all other MGCs have
4376 read-only access. The management mechanism is used to designate
4377 which MGC has read/write capability, and is designated the Master
4380 Each virtual MG has its own Root Termination. In most cases the
4381 values for the properties of the Root Termination are independently
4382 settable by each MGC. Where there can only be one value, the
4383 parameter is read-only to all but the Master MGC.
4385 ServiceChange may only be applied to a Termination or set of
4386 Terminations partitioned to the Virtual MG or created (in the case of
4387 ephemeral Terminations) by that Virtual MG.
4391 A MG is pre-provisioned by a management mechanism outside the scope
4392 of this protocol with a primary and (optionally) an ordered list of
4393 secondary MGCs. Upon a cold start of the MG, it will issue a
4394 ServiceChange command with a "Restart" method, on the Root
4395 Termination to its primary MGC. If the MGC accepts the MG, it sends
4396 a Transaction Reply not including a ServiceChangeMgcId parameter. If
4397 the MGC does not accept the MG's registration, it sends a Transaction
4398 Reply, providing the address of an alternate MGC to be contacted by
4399 including a ServiceChangeMgcId parameter.
4401 If the MG receives a Transaction Reply that includes a
4402 ServiceChangeMgcId parameter, it sends a ServiceChange to the MGC
4403 specified in the ServiceChangeMgcId. It continues this process until
4404 it gets a controlling MGC to accept its registration, or it fails to
4405 get a reply. Upon failure to obtain a reply, either from the primary
4406 MGC, or a designated successor, the MG tries its pre-provisioned
4407 secondary MGCs, in order. If the MG is unable to establish a control
4408 relationship with any MGC, it shall wait a random amount of time as
4409 described in 9.2 and then start contacting its primary, and if
4410 necessary, its secondary MGCs again.
4412 It is possible that the reply to a ServiceChange with Restart will be
4413 lost, and a command will be received by the MG prior to the receipt
4414 of the ServiceChange response. The MG shall issue Error 505 -
4415 Command Received before a ServiceChange Reply has been received.
4417 11.3 Negotiation of protocol version
4419 The first ServiceChange command from a MG shall contain the version
4420 number of the protocol supported by the MG in the
4421 ServiceChangeVersion parameter. Upon receiving such a message, if
4422 the MGC supports only a lower version, then the MGC shall send a
4426 Groves, et al. Standards Track [Page 79]
4428 RFC 3525 Gateway Control Protocol June 2003
4431 ServiceChangeReply with the lower version and thereafter all the
4432 messages between MG and MGC shall conform to the lower version of the
4433 protocol. If the MG is unable to comply and it has established a
4434 transport connection to the MGC, it should close that connection. In
4435 any event, it should reject all subsequent requests from the MGC with
4436 error 406 - Version Not Supported.
4438 If the MGC supports a higher version than the MG but is able to
4439 support the lower version proposed by the MG, it shall send a
4440 ServiceChangeReply with the lower version and thereafter all the
4441 messages between MG and MGC shall conform to the lower version of the
4442 protocol. If the MGC is unable to comply, it shall reject the
4443 association, with error 406 - Version Not Supported.
4445 Protocol version negotiation may also occur at "handoff" and
4446 "failover" ServiceChanges.
4448 When extending the protocol with new versions, the following rules
4451 1) Existing protocol elements, i.e., procedures, parameters,
4452 descriptor, property, values, should not be changed unless a
4453 protocol error needs to be corrected or it becomes necessary to
4454 change the operation of the service that is being supported by the
4457 2) The semantics of a command, a parameter, a descriptor, a property,
4458 or a value should not be changed.
4460 3) Established rules for formatting and encoding messages and
4461 parameters should not be modified.
4463 4) When information elements are found to be obsolete they can be
4464 marked as not used. However, the identifier for that information
4465 element will be marked as reserved. In that way it can not be
4466 used in future versions.
4468 11.4 Failure of a MG
4470 If a MG fails, but is capable of sending a message to the MGC, it
4471 sends a ServiceChange with an appropriate method (graceful or forced)
4472 and specifies the Root TerminationID. When it returns to service, it
4473 sends a ServiceChange with a "Restart" method.
4475 Allowing the MGC to send duplicate messages to both MGs accommodates
4476 pairs of MGs that are capable of redundant failover of one of the
4477 MGs. Only the Working MG shall accept or reject transactions. Upon
4478 failover, the primary MG sends a ServiceChange command with a
4482 Groves, et al. Standards Track [Page 80]
4484 RFC 3525 Gateway Control Protocol June 2003
4487 "Failover" method and a "MG Impending Failure" reason. The MGC then
4488 uses the secondary MG as the active MG. When the error condition is
4489 repaired, the Working MG can send a "ServiceChange" with a "Restart"
4492 Note: Redundant failover MGs require a reliable transport, because
4493 the protocol provides no means for a secondary MG running ALF to
4494 acknowledge messages sent from the MGC.
4496 11.5 Failure of an MGC
4498 If the MG detects a failure of its controlling MGC, it attempts to
4499 contact the next MGC on its pre-provisioned list. It starts its
4500 attempts at the beginning (primary MGC), unless that was the MGC that
4501 failed, in which case it starts at its first secondary MGC. It sends
4502 a ServiceChange message with a "Failover" method and a "MGC Impending
4503 Failure" reason. If the MG is unable to establish a control
4504 relationship with any MGC, it shall wait a random amount of time as
4505 described in section 9.2 and then start again contacting its primary,
4506 and (if necessary) its secondary MGCs. When contacting its
4507 previously controlling MGC, the MG sends the ServiceChange message
4508 with "Disconnected" method.
4510 In partial failure, or for manual maintenance reasons, an MGC may
4511 wish to direct its controlled MGs to use a different MGC. To do so,
4512 it sends a ServiceChange method to the MG with a "HandOff" method,
4513 and its designated replacement in ServiceChangeMgcId. If "HandOff"
4514 is supported, the MG shall send a ServiceChange message with a
4515 "Handoff" method and a "MGC directed change" reason to the designated
4516 MGC. If it fails to get a reply from the designated MGC, the MG
4517 shall behave as if its MGC failed, and start contacting secondary
4518 MGCs as specified in the previous paragraph. If the MG is unable to
4519 establish a control relationship with any MGC, it shall wait a random
4520 amount of time as described in 9.2 and then start contacting its
4521 primary, and if necessary, its secondary MGCs again.
4523 No recommendation is made on how the MGCs involved in the Handoff
4524 maintain state information; this is considered to be out of scope of
4525 this RFC. The MGC and MG may take the following steps when Handoff
4526 occurs. When the MGC initiates a HandOff, the handover should be
4527 transparent to Operations on the Media Gateway. Transactions can be
4528 executed in any order, and could be in progress when the
4529 ServiceChange is executed. Accordingly, commands in progress
4530 continue and replies to all commands from the original MGC must be
4531 sent to the transport address from which they were sent. If the
4532 service relationship with the sending MGC has ended, the replies
4533 should be discarded. The MG may receive outstanding transaction
4534 replies from the new MGC. No new messages shall be sent to the new
4538 Groves, et al. Standards Track [Page 81]
4540 RFC 3525 Gateway Control Protocol June 2003
4543 MGC until the control association is established. Repeated
4544 transaction requests shall be directed to the new MGC. The MG shall
4545 maintain state on all Terminations and Contexts.
4547 It is possible that the MGC could be implemented in such a way that a
4548 failed MGC is replaced by a working MGC where the identity of the new
4549 MGC is the same as the failed one. In such a case,
4550 ServiceChangeMgcId would be specified with the previous value and the
4551 MG shall behave as if the value was changed, and send a ServiceChange
4554 Pairs of MGCs that are capable of redundant failover can notify the
4555 controlled MGs of the failover by the above mechanism.
4557 12 Package definition
4559 The primary mechanism for extension is by means of Packages.
4560 Packages define additional Properties, Events, Signals and Statistics
4561 that may occur on Terminations.
4563 Packages defined by IETF will appear in separate RFCs.
4565 Packages defined by ITU-T may appear in the relevant Recommendations
4566 (e.g., as Recommendations of the H.248 sub-series).
4568 1) A public document or a standard forum document, which can be
4569 referenced as the document that describes the package following
4570 the guideline above, should be specified.
4572 2) The document shall specify the version of the Package that it
4575 3) The document should be available on a public web server and should
4576 have a stable URL. The site should provide a mechanism to provide
4577 comments and appropriate responses should be returned.
4579 12.1 Guidelines for defining packages
4581 Packages define Properties, Events, Signals, and Statistics.
4583 Packages may also define new error codes according to the guidelines
4584 given in 13.2. This is a matter of documentary convenience: the
4585 package documentation is submitted to IANA in support of the error
4586 code registration. If a package is modified, it is unnecessary to
4587 provide IANA with a new document reference in support of the error
4588 code unless the description of the error code itself is modified.
4594 Groves, et al. Standards Track [Page 82]
4596 RFC 3525 Gateway Control Protocol June 2003
4599 Names of all such defined constructs shall consist of the PackageID
4600 (which uniquely identifies the package) and the ID of the item (which
4601 uniquely identifies the item in that package). In the text encoding
4602 the two shall be separated by a forward slash ("/") character.
4603 Example: togen/playtone is the text encoding to refer to the play
4604 tone signal in the tone generation package.
4606 A Package will contain the following sections:
4610 Overall description of the package, specifying:
4612 Package Name: only descriptive
4614 PackageID: is an identifier
4620 A new version of a package can only add additional Properties,
4621 Events, Signals, Statistics and new possible values for an
4622 existing parameter described in the original package. No
4623 deletions or modifications shall be allowed. A version is an
4624 integer in the range from 1 to 99.
4626 Designed to be extended only (Optional):
4628 This indicates that the package has been expressly designed to
4629 be extended by others, not to be directly referenced. For
4630 example, the package may not have any function on its own or be
4631 nonsensical on its own. The MG SHOULD NOT publish this
4632 PackageID when reporting packages.
4634 Extends (Optional): existing package Descriptor
4636 A package may extend an existing package. The version of the
4637 original package must be specified. When a package extends
4638 another package it shall only add additional Properties,
4639 Events, Signals, Statistics and new possible values for an
4640 existing parameter described in the original package. An
4641 extended package shall not redefine or overload an identifier
4642 defined in the original package and packages it may have
4643 extended (multiple levels of extension). Hence, if package B
4644 version 1 extends package A version 1, version 2 of B will not
4645 be able to extend the A version 2 if A version 2 defines a name
4646 already in B version 1.
4650 Groves, et al. Standards Track [Page 83]
4652 RFC 3525 Gateway Control Protocol June 2003
4657 Properties defined by the package, specifying:
4659 Property Name: only descriptive
4661 PropertyID: is an identifier
4669 String: UTF-8 string
4671 Octet String: A number of octets. See Annex A and Annex B.3
4674 Integer: 4 byte signed integer
4676 Double: 8 byte signed integer
4678 Character: unicode UTF-8 encoding of a single letter. Could be
4679 more than one octet.
4681 Enumeration: one of a list of possible unique values (see 12.3)
4683 Sub-list: a list of several values from a list. The type of
4684 sub-list SHALL also be specified. The type shall be chosen
4685 from the types specified in this section (with the exception of
4686 sub-list). For example, Type: sub-list of enumeration. The
4687 encoding of sub-lists is specified in Annexes A and B.3.
4691 A package MUST specify either a specific set of values or a
4692 description of how values are determined. A package MUST also
4693 specify a default value or the default behaviour when the value
4694 is omitted from its descriptor. For example, a package may
4695 specify that procedures related to the property are suspended
4696 when its value is omitted. A default value (but not
4698 may be specified as provisionable.
4702 Which H.248.1 descriptor the property is defined in.
4706 Groves, et al. Standards Track [Page 84]
4708 RFC 3525 Gateway Control Protocol June 2003
4711 LocalControl is for stream dependent properties.
4712 TerminationState is for stream independent properties. These
4713 are expected to be the most common cases, but it is possible
4714 for properties to be defined in other descriptors.
4716 Characteristics: Read/Write or both, and (optionally), global:
4718 Indicates whether a property is read-only, or read-write, and
4719 if it is global. If Global is omitted, the property is not
4720 global. If a property is declared as global, the value of the
4721 property is shared by all Terminations realizing the package.
4725 Events defined by the package, specifying:
4727 Event name: only descriptive
4729 EventID: is an identifier
4733 EventsDescriptor Parameters:
4735 Parameters used by the MGC to configure the event, and found in
4736 the EventsDescriptor. See 12.2.
4738 ObservedEventsDescriptor Parameters:
4740 Parameters returned to the MGC in Notify requests and in
4741 replies to command requests from the MGC that audit
4742 ObservedEventsDescriptor, and found in the
4743 ObservedEventsDescriptor. See 12.2.
4747 Signals defined by the package, specifying:
4749 Signal Name: only descriptive
4751 SignalID: is an identifier. SignalID is used in a
4762 Groves, et al. Standards Track [Page 85]
4764 RFC 3525 Gateway Control Protocol June 2003
4771 NOTE - SignalType may be defined such that it is dependent on the
4772 value of one or more parameters. The package MUST specify a
4773 default signal type. If the default type is TO, the package MUST
4774 specify a default duration which may be provisioned. A default
4775 duration is meaningless for BR.
4777 Duration: in hundredths of seconds
4779 Additional Parameters: see 12.2
4783 Statistics defined by the package, specifying:
4785 Statistic name: only descriptive
4787 StatisticID: is an identifier
4789 StatisticID is used in a StatisticsDescriptor
4793 Units: unit of measure, e.g., milliseconds, packets
4797 Additional guidance on the use of the package.
4799 12.2 Guidelines to defining Parameters to Events and Signals
4801 Parameter Name: only descriptive
4803 ParameterID: is an identifier. The textual ParameterID of parameters
4804 to Events and Signals shall not start with "EPA" and "SPA",
4805 respectively. The textual ParameterID shall also not be "ST",
4806 "Stream", "SY", "SignalType", "DR", "Duration", "NC",
4807 "NotifyCompletion", "KA", "Keepactive", "EB", "Embed", "DM" or
4814 String: UTF-8 octet string
4818 Groves, et al. Standards Track [Page 86]
4820 RFC 3525 Gateway Control Protocol June 2003
4823 Octet String: A number of octets. See Annex A and Annex B.3 for
4826 Integer: 4-octet signed integer
4828 Double: 8-octet signed integer
4830 Character: unicode UTF-8 encoding of a single letter. Could be
4831 more than one octet.
4833 Enumeration: one of a list of possible unique values (see 12.3)
4835 Sub-list: a list of several values from a list (not supported for
4836 statistics). The type of sub-list SHALL also be specified. The
4837 type shall be chosen from the types specified in this section
4838 (with the exception of sub-list). For example, Type: sub-list of
4839 enumeration. The encoding of sub-lists is specified in Annexes A
4844 A package MUST specify either a specific set of values or a
4845 description of how values are determined. A package MUST also
4846 specify a default value or the default behavior when the value is
4847 omitted from its descriptor. For example, a package may specify
4848 that procedures related to the parameter are suspended when it
4849 value is omitted. A default value (but not procedures) may be
4850 specified as provisionable.
4856 Possible values for parameters include enumerations. Enumerations
4857 may be defined in a list. It is recommended that the list be IANA
4858 registered so that packages that extend the list can be defined
4859 without concern for conflicting names.
4863 Identifiers in text encoding shall be strings of up to 64 characters,
4864 containing no spaces, starting with an alphabetic character and
4865 consisting of alphanumeric characters and/or digits, and possibly
4866 including the special character underscore ("_").
4874 Groves, et al. Standards Track [Page 87]
4876 RFC 3525 Gateway Control Protocol June 2003
4879 Identifiers in binary encoding are 2 octets long.
4881 Both text and binary values shall be specified for each identifier,
4882 including identifiers used as values in enumerated types.
4884 12.5 Package registration
4886 A package can be registered with IANA for interoperability reasons.
4887 See clause 13 for IANA Considerations.
4889 13 IANA Considerations
4893 The following considerations SHALL be met to register a package with
4896 1) A unique string name, unique serial number and version number is
4897 registered for each package. The string name is used with text
4898 encoding. The serial number shall be used with binary encoding.
4899 Serial Numbers 0x8000 to 0xFFFF are reserved for private use.
4900 Serial number 0 is reserved.
4902 2) A contact name, email and postal addresses for that contact shall
4903 be specified. The contact information shall be updated by the
4904 defining organization as necessary.
4906 3) A reference to a document that describes the package, which should
4909 The document shall specify the version of the Package that it
4912 If the document is public, it should be located on a public web
4913 server and should have a stable URL. The site should provide a
4914 mechanism to provide comments and appropriate responses should be
4917 4) Packages registered by other than recognized standards bodies
4918 shall have a minimum package name length of 8 characters.
4920 5) All other package names are first come-first served if all other
4930 Groves, et al. Standards Track [Page 88]
4932 RFC 3525 Gateway Control Protocol June 2003
4937 The following considerations SHALL be met to register an error code
4940 1) An error number and a one-line (80-character maximum) string is
4941 registered for each error.
4943 2) A complete description of the conditions under which the error is
4944 detected shall be included in a publicly available document. The
4945 description shall be sufficiently clear to differentiate the error
4946 from all other existing error codes.
4948 3) The document should be available on a public web server and should
4951 4) Error numbers registered by recognized standards bodies shall have
4952 3- or 4-character error numbers.
4954 5) Error numbers registered by all other organizations or individuals
4955 shall have 4-character error numbers.
4957 6) An error number shall not be redefined nor modified except by the
4958 organization or individual that originally defined it, or their
4959 successors or assigns.
4961 13.3 ServiceChange reasons
4963 The following considerations SHALL be met to register service change
4966 1) A one-phrase, 80-character maximum, unique reason code is
4967 registered for each reason.
4969 2) A complete description of the conditions under which the reason is
4970 used is detected shall be included in a publicly available
4971 document. The description shall be sufficiently clear to
4972 differentiate the reason from all other existing reasons.
4974 3) The document should be available on a public web server and should
4986 Groves, et al. Standards Track [Page 89]
4988 RFC 3525 Gateway Control Protocol June 2003
4991 ANNEX A - Binary encoding of the protocol
4993 This annex specifies the syntax of messages using the notation
4994 defined in Recommendation X.680; Information technology - Abstract
4995 Syntax Notation One (ASN.1): Specification of basic notation.
4996 Messages shall be encoded for transmission by applying the basic
4997 encoding rules specified in Recommendation X.690, Information
4998 Technology - ASN.1 Encoding Rules: Specification of Basic Encoding
4999 Rules (BER), Canonical Encoding Rules (CER) and Distinguished
5002 A.1 Coding of wildcards
5004 The use of wildcards ALL and CHOOSE is allowed in the protocol. This
5005 allows a MGC to partially specify Termination IDs and to let the MG
5006 choose from the values that conform to the partial specification.
5007 Termination IDs may encode a hierarchy of names. This hierarchy is
5008 provisioned. For instance, a TerminationID may consist of a trunk
5009 group, a trunk within the group and a circuit. Wildcarding must be
5010 possible at all levels. The following paragraphs explain how this is
5013 The ASN.1 description uses octet strings of up to 8 octets in length
5014 for Termination IDs. This means that Termination IDs consist of at
5015 most 64 bits. A fully specified Termination ID may be preceded by a
5016 sequence of wildcarding fields. A wildcarding field is one octet in
5017 length. Bit 7 (the most significant bit) of this octet specifies
5018 what type of wildcarding is invoked: if the bit value equals 1, then
5019 the ALL wildcard is used; if the bit value if 0, then the CHOOSE
5020 wildcard is used. Bit 6 of the wildcarding field specifies whether
5021 the wildcarding pertains to one level in the hierarchical naming
5022 scheme (bit value 0) or to the level of the hierarchy specified in
5023 the wildcarding field plus all lower levels (bit value 1). Bits 0
5024 through 5 of the wildcarding field specify the bit position in the
5025 Termination ID at which the wildcarding starts.
5027 We illustrate this scheme with some examples. In these examples, the
5028 most significant bit in a string of bits appears on the left hand
5031 Assume that Termination IDs are three octets long and that each octet
5032 represents a level in a hierarchical naming scheme. A valid
5035 00000001 00011110 01010101.
5042 Groves, et al. Standards Track [Page 90]
5044 RFC 3525 Gateway Control Protocol June 2003
5047 Addressing ALL names with prefix 00000001 00011110 is done as
5050 wildcarding field: 10000111
5052 Termination ID: 00000001 00011110 xxxxxxxx.
5054 The values of the bits labeled "x" is irrelevant and shall be ignored
5057 Indicating to the receiver that it must choose a name with 00011110
5058 as the second octet is done as follows:
5060 wildcarding fields: 00010111 followed by 00000111
5062 Termination ID: xxxxxxxx 00011110 xxxxxxxx.
5064 The first wildcard field indicates a CHOOSE wildcard for the level in
5065 the naming hierarchy starting at bit 23, the highest level in our
5066 assumed naming scheme. The second wildcard field indicates a CHOOSE
5067 wildcard for the level in the naming hierarchy starting at bit 7, the
5068 lowest level in our assumed naming scheme.
5070 Finally, a CHOOSE-wildcarded name with the highest level of the name
5071 equal to 00000001 is specified as follows:
5073 wildcard field: 01001111
5075 Termination ID: 0000001 xxxxxxxx xxxxxxxx .
5077 Bit value 1 at bit position 6 of the first octet of the wildcard
5078 field indicates that the wildcarding pertains to the specified level
5079 in the naming hierarchy and all lower levels.
5081 Context IDs may also be wildcarded. In the case of Context IDs,
5082 however, specifying partial names is not allowed. Context ID 0x0
5083 SHALL be used to indicate the NULL Context, Context ID 0xFFFFFFFE
5084 SHALL be used to indicate a CHOOSE wildcard, and Context ID
5085 0xFFFFFFFF SHALL be used to indicate an ALL wildcard.
5087 TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
5098 Groves, et al. Standards Track [Page 91]
5100 RFC 3525 Gateway Control Protocol June 2003
5103 A.2 ASN.1 syntax specification
5105 This subclause contains the ASN.1 specification of the H.248.1
5108 NOTE 1 - In case a transport mechanism is used that employs
5109 application level framing, the definition of Transaction below
5110 changes. Refer to the annex or to the Recommendation of the H.248
5111 sub-series defining the transport mechanism for the definition that
5112 applies in that case.
5114 NOTE 2 - The ASN.1 specification below contains a clause defining
5115 TerminationIDList as a sequence of TerminationIDs. The length of
5116 this sequence SHALL be one, except possibly when used in
5119 NOTE 3 - This syntax specification does not enforce all
5120 restrictions on element inclusions and values. Some additional
5121 restrictions are stated in comments and other restrictions appear
5122 in the text of this RFC. These additional restrictions
5123 are part of the protocol even though not enforced by this
5126 NOTE 4 - The ASN.1 module in this Annex uses octet string types to
5127 encode values for property parameter, signal parameter and event
5128 parameter values and statistics. The actual types of these values
5129 vary and are specified in Annex C or the relevant package
5132 A value is first BER-encoded based on its type using the table below.
5133 The result of this BER-encoding is then encoded as an ASN.1 octet
5134 string, "double wrapping" the value. The format specified in Annex C
5135 or the package relates to BER encoding according to the following
5138 Type Specified in Package ASN.1 BER Type
5140 String IA5String or UTF8String (Note 4)
5142 Integer (4 Octet) INTEGER
5144 Double (8 octet signed int) INTEGER (Note 3)
5146 Character (UTF-8, Note 1) IA5String
5148 Enumeration ENUMERATED
5154 Groves, et al. Standards Track [Page 92]
5156 RFC 3525 Gateway Control Protocol June 2003
5159 Unsigned Integer (Note 2) INTEGER (Note 3)
5161 Octet (String) OCTET STRING
5163 Note 1: Can be more than one byte
5165 Note 2: Unsigned integer is referenced in Annex C
5167 Note 3: The BER encoding of INTEGER does not imply the use of 4
5170 Note 4: String should be encoded as IA5String when the contents
5171 are all ASCII characters, but as UTF8String if it contains any
5172 Non-ASCII characters.
5174 See ITU-T Rec. X.690, 8.7, for the definition of the encoding of an
5177 MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=
5180 MegacoMessage ::= SEQUENCE
5182 authHeader AuthenticationHeader OPTIONAL,
5186 AuthenticationHeader ::= SEQUENCE
5188 secParmIndex SecurityParmIndex,
5193 SecurityParmIndex ::= OCTET STRING(SIZE(4))
5195 SequenceNum ::= OCTET STRING(SIZE(4))
5197 AuthData ::= OCTET STRING (SIZE (12..32))
5199 Message ::= SEQUENCE
5201 version INTEGER(0..99),
5202 -- The version of the protocol defined here is equal to 1.
5203 mId MId, -- Name/address of message originator
5206 messageError ErrorDescriptor,
5210 Groves, et al. Standards Track [Page 93]
5212 RFC 3525 Gateway Control Protocol June 2003
5215 transactions SEQUENCE OF Transaction
5222 ip4Address IP4Address,
5223 ip6Address IP6Address,
5224 domainName DomainName,
5225 deviceName PathName,
5226 mtpAddress OCTET STRING(SIZE(2..4)),
5227 -- Addressing structure of mtpAddress:
5230 -- 24 - 14 bits 2 bits
5231 -- Note: 14 bits are defined for international use.
5232 -- Two national options exist where the point code is 16 or 24
5234 -- To octet align the mtpAddress, the MSBs shall be encoded as 0s.
5238 DomainName ::= SEQUENCE
5241 -- The name starts with an alphanumeric digit followed by a
5242 -- sequence of alphanumeric digits, hyphens and dots. No two
5243 -- dots shall occur consecutively.
5244 portNumber INTEGER(0..65535) OPTIONAL
5247 IP4Address ::= SEQUENCE
5249 address OCTET STRING (SIZE(4)),
5250 portNumber INTEGER(0..65535) OPTIONAL
5253 IP6Address ::= SEQUENCE
5255 address OCTET STRING (SIZE(16)),
5256 portNumber INTEGER(0..65535) OPTIONAL
5259 PathName ::= IA5String(SIZE (1..64))
5262 Transaction ::= CHOICE
5266 Groves, et al. Standards Track [Page 94]
5268 RFC 3525 Gateway Control Protocol June 2003
5272 transactionRequest TransactionRequest,
5273 transactionPending TransactionPending,
5274 transactionReply TransactionReply,
5275 transactionResponseAck TransactionResponseAck,
5276 -- use of response acks is dependent on underlying transport
5280 TransactionId ::= INTEGER(0..4294967295) -- 32-bit unsigned integer
5282 TransactionRequest ::= SEQUENCE
5284 transactionId TransactionId,
5285 actions SEQUENCE OF ActionRequest,
5289 TransactionPending ::= SEQUENCE
5291 transactionId TransactionId,
5295 TransactionReply ::= SEQUENCE
5297 transactionId TransactionId,
5298 immAckRequired NULL OPTIONAL,
5299 transactionResult CHOICE
5301 transactionError ErrorDescriptor,
5302 actionReplies SEQUENCE OF ActionReply
5307 TransactionResponseAck ::= SEQUENCE OF TransactionAck
5308 TransactionAck ::= SEQUENCE
5310 firstAck TransactionId,
5311 lastAck TransactionId OPTIONAL
5314 ErrorDescriptor ::= SEQUENCE
5316 errorCode ErrorCode,
5317 errorText ErrorText OPTIONAL
5322 Groves, et al. Standards Track [Page 95]
5324 RFC 3525 Gateway Control Protocol June 2003
5328 ErrorCode ::= INTEGER(0..65535)
5329 -- See clause 13 for IANA Considerations with respect to error codes
5331 ErrorText ::= IA5String
5333 ContextID ::= INTEGER(0..4294967295)
5335 -- Context NULL Value: 0
5336 -- Context CHOOSE Value: 4294967294 (0xFFFFFFFE)
5337 -- Context ALL Value: 4294967295 (0xFFFFFFFF)
5340 ActionRequest ::= SEQUENCE
5342 contextId ContextID,
5343 contextRequest ContextRequest OPTIONAL,
5344 contextAttrAuditReq ContextAttrAuditRequest OPTIONAL,
5345 commandRequests SEQUENCE OF CommandRequest
5348 ActionReply ::= SEQUENCE
5350 contextId ContextID,
5351 errorDescriptor ErrorDescriptor OPTIONAL,
5352 contextReply ContextRequest OPTIONAL,
5353 commandReply SEQUENCE OF CommandReply
5356 ContextRequest ::= SEQUENCE
5358 priority INTEGER(0..15) OPTIONAL,
5359 emergency BOOLEAN OPTIONAL,
5360 topologyReq SEQUENCE OF TopologyRequest OPTIONAL,
5364 ContextAttrAuditRequest ::= SEQUENCE
5366 topology NULL OPTIONAL,
5367 emergency NULL OPTIONAL,
5368 priority NULL OPTIONAL,
5372 CommandRequest ::= SEQUENCE
5378 Groves, et al. Standards Track [Page 96]
5380 RFC 3525 Gateway Control Protocol June 2003
5383 optional NULL OPTIONAL,
5384 wildcardReturn NULL OPTIONAL,
5393 -- Add, Move, Modify requests have the same parameters
5394 subtractReq SubtractRequest,
5395 auditCapRequest AuditRequest,
5396 auditValueRequest AuditRequest,
5397 notifyReq NotifyRequest,
5398 serviceChangeReq ServiceChangeRequest,
5402 CommandReply ::= CHOICE
5405 moveReply AmmsReply,
5407 subtractReply AmmsReply,
5408 -- Add, Move, Modify, Subtract replies have the same parameters
5409 auditCapReply AuditReply,
5410 auditValueReply AuditReply,
5411 notifyReply NotifyReply,
5412 serviceChangeReply ServiceChangeReply,
5416 TopologyRequest ::= SEQUENCE
5418 terminationFrom TerminationID,
5419 terminationTo TerminationID,
5420 topologyDirection ENUMERATED
5429 AmmRequest ::= SEQUENCE
5434 Groves, et al. Standards Track [Page 97]
5436 RFC 3525 Gateway Control Protocol June 2003
5439 terminationID TerminationIDList,
5440 descriptors SEQUENCE OF AmmDescriptor,
5441 -- At most one descriptor of each type (see AmmDescriptor)
5442 -- allowed in the sequence.
5446 AmmDescriptor ::= CHOICE
5448 mediaDescriptor MediaDescriptor,
5449 modemDescriptor ModemDescriptor,
5450 muxDescriptor MuxDescriptor,
5451 eventsDescriptor EventsDescriptor,
5452 eventBufferDescriptor EventBufferDescriptor,
5453 signalsDescriptor SignalsDescriptor,
5454 digitMapDescriptor DigitMapDescriptor,
5455 auditDescriptor AuditDescriptor,
5459 AmmsReply ::= SEQUENCE
5461 terminationID TerminationIDList,
5462 terminationAudit TerminationAudit OPTIONAL,
5466 SubtractRequest ::= SEQUENCE
5468 terminationID TerminationIDList,
5469 auditDescriptor AuditDescriptor OPTIONAL,
5473 AuditRequest ::= SEQUENCE
5475 terminationID TerminationID,
5476 auditDescriptor AuditDescriptor,
5480 AuditReply ::= CHOICE
5482 contextAuditResult TerminationIDList,
5483 error ErrorDescriptor,
5484 auditResult AuditResult,
5490 Groves, et al. Standards Track [Page 98]
5492 RFC 3525 Gateway Control Protocol June 2003
5496 AuditResult ::= SEQUENCE
5499 terminationID TerminationID,
5500 terminationAuditResult TerminationAudit
5503 TerminationAudit ::= SEQUENCE OF AuditReturnParameter
5505 AuditReturnParameter ::= CHOICE
5507 errorDescriptor ErrorDescriptor,
5508 mediaDescriptor MediaDescriptor,
5509 modemDescriptor ModemDescriptor,
5510 muxDescriptor MuxDescriptor,
5511 eventsDescriptor EventsDescriptor,
5512 eventBufferDescriptor EventBufferDescriptor,
5513 signalsDescriptor SignalsDescriptor,
5514 digitMapDescriptor DigitMapDescriptor,
5515 observedEventsDescriptor ObservedEventsDescriptor,
5516 statisticsDescriptor StatisticsDescriptor,
5517 packagesDescriptor PackagesDescriptor,
5518 emptyDescriptors AuditDescriptor,
5522 AuditDescriptor ::= SEQUENCE
5524 auditToken BIT STRING
5526 muxToken(0), modemToken(1), mediaToken(2),
5527 eventsToken(3), signalsToken(4),
5528 digitMapToken(5), statsToken(6),
5529 observedEventsToken(7),
5530 packagesToken(8), eventBufferToken(9)
5535 NotifyRequest ::= SEQUENCE
5537 terminationID TerminationIDList,
5538 observedEventsDescriptor ObservedEventsDescriptor,
5539 errorDescriptor ErrorDescriptor OPTIONAL,
5546 Groves, et al. Standards Track [Page 99]
5548 RFC 3525 Gateway Control Protocol June 2003
5551 NotifyReply ::= SEQUENCE
5553 terminationID TerminationIDList,
5554 errorDescriptor ErrorDescriptor OPTIONAL,
5558 ObservedEventsDescriptor ::= SEQUENCE
5560 requestId RequestID,
5561 observedEventLst SEQUENCE OF ObservedEvent
5564 ObservedEvent ::= SEQUENCE
5566 eventName EventName,
5567 streamID StreamID OPTIONAL,
5568 eventParList SEQUENCE OF EventParameter,
5569 timeNotation TimeNotation OPTIONAL,
5573 EventName ::= PkgdName
5575 EventParameter ::= SEQUENCE
5577 eventParameterName Name,
5579 -- For use of extraInfo see the comment related to PropertyParm
5589 ServiceChangeRequest ::= SEQUENCE
5591 terminationID TerminationIDList,
5592 serviceChangeParms ServiceChangeParm,
5596 ServiceChangeReply ::= SEQUENCE
5598 terminationID TerminationIDList,
5602 Groves, et al. Standards Track [Page 100]
5604 RFC 3525 Gateway Control Protocol June 2003
5607 serviceChangeResult ServiceChangeResult,
5611 -- For ServiceChangeResult, no parameters are mandatory. Hence the
5612 -- distinction between ServiceChangeParm and ServiceChangeResParm.
5614 ServiceChangeResult ::= CHOICE
5616 errorDescriptor ErrorDescriptor,
5617 serviceChangeResParms ServiceChangeResParm
5620 WildcardField ::= OCTET STRING(SIZE(1))
5622 TerminationID ::= SEQUENCE
5624 wildcard SEQUENCE OF WildcardField,
5625 id OCTET STRING(SIZE(1..8)),
5628 -- See A.1 for explanation of wildcarding mechanism.
5629 -- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination.
5631 TerminationIDList ::= SEQUENCE OF TerminationID
5633 MediaDescriptor ::= SEQUENCE
5636 termStateDescr TerminationStateDescriptor OPTIONAL,
5639 oneStream StreamParms,
5640 multiStream SEQUENCE OF StreamDescriptor
5645 StreamDescriptor ::= SEQUENCE
5648 streamParms StreamParms
5651 StreamParms ::= SEQUENCE
5653 localControlDescriptor LocalControlDescriptor OPTIONAL,
5654 localDescriptor LocalRemoteDescriptor OPTIONAL,
5658 Groves, et al. Standards Track [Page 101]
5660 RFC 3525 Gateway Control Protocol June 2003
5663 remoteDescriptor LocalRemoteDescriptor OPTIONAL,
5667 LocalControlDescriptor ::= SEQUENCE
5670 streamMode StreamMode OPTIONAL,
5671 reserveValue BOOLEAN OPTIONAL,
5672 reserveGroup BOOLEAN OPTIONAL,
5673 propertyParms SEQUENCE OF PropertyParm,
5677 StreamMode ::= ENUMERATED
5687 -- In PropertyParm, value is a SEQUENCE OF octet string. When sent
5688 -- by an MGC the interpretation is as follows:
5689 -- empty sequence means CHOOSE
5690 -- one element sequence specifies value
5691 -- If the sublist field is not selected, a longer sequence means
5692 -- "choose one of the values" (i.e., value1 OR value2 OR ...)
5693 -- If the sublist field is selected,
5694 -- a sequence with more than one element encodes the value of a
5695 -- list-valued property (i.e., value1 AND value2 AND ...).
5696 -- The relation field may only be selected if the value sequence
5697 -- has length 1. It indicates that the MG has to choose a value
5698 -- for the property. E.g., x > 3 (using the greaterThan
5699 -- value for relation) instructs the MG to choose any value larger
5700 -- than 3 for property x.
5701 -- The range field may only be selected if the value sequence
5702 -- has length 2. It indicates that the MG has to choose a value
5703 -- in the range between the first octet in the value sequence and
5704 -- the trailing octet in the value sequence, including the
5706 -- When sent by the MG, only responses to an AuditCapability request
5707 -- may contain multiple values, a range, or a relation field.
5709 PropertyParm ::= SEQUENCE
5714 Groves, et al. Standards Track [Page 102]
5716 RFC 3525 Gateway Control Protocol June 2003
5720 value SEQUENCE OF OCTET STRING,
5730 Name ::= OCTET STRING(SIZE(2))
5732 PkgdName ::= OCTET STRING(SIZE(4))
5733 -- represents Package Name (2 octets) plus Property, Event,
5734 -- Signal Names or Statistics ID. (2 octets)
5735 -- To wildcard a package use 0xFFFF for first two octets, choose
5736 -- is not allowed. To reference native property tag specified in
5737 -- Annex C, use 0x0000 as first two octets.
5738 -- To wildcard a Property, Event, Signal, or Statistics ID, use
5739 -- 0xFFFF for last two octets, choose is not allowed.
5740 -- Wildcarding of Package Name is permitted only if Property,
5741 -- Event, Signal, or Statistics ID are
5744 Relation ::= ENUMERATED
5752 LocalRemoteDescriptor ::= SEQUENCE
5754 propGrps SEQUENCE OF PropertyGroup,
5758 PropertyGroup ::= SEQUENCE OF PropertyParm
5760 TerminationStateDescriptor ::= SEQUENCE
5762 propertyParms SEQUENCE OF PropertyParm,
5763 eventBufferControl EventBufferControl OPTIONAL,
5764 serviceState ServiceState OPTIONAL,
5770 Groves, et al. Standards Track [Page 103]
5772 RFC 3525 Gateway Control Protocol June 2003
5776 EventBufferControl ::= ENUMERATED
5783 ServiceState ::= ENUMERATED
5792 MuxDescriptor ::= SEQUENCE
5795 termList SEQUENCE OF TerminationID,
5796 nonStandardData NonStandardData OPTIONAL,
5800 MuxType ::= ENUMERATED
5809 StreamID ::= INTEGER(0..65535) -- 16-bit unsigned integer
5811 EventsDescriptor ::= SEQUENCE
5813 requestID RequestID OPTIONAL,
5814 -- RequestID must be present if eventList
5816 eventList SEQUENCE OF RequestedEvent,
5820 RequestedEvent ::= SEQUENCE
5826 Groves, et al. Standards Track [Page 104]
5828 RFC 3525 Gateway Control Protocol June 2003
5831 streamID StreamID OPTIONAL,
5832 eventAction RequestedActions OPTIONAL,
5833 evParList SEQUENCE OF EventParameter,
5837 RequestedActions ::= SEQUENCE
5839 keepActive BOOLEAN OPTIONAL,
5840 eventDM EventDM OPTIONAL,
5841 secondEvent SecondEventsDescriptor OPTIONAL,
5842 signalsDescriptor SignalsDescriptor OPTIONAL,
5847 { digitMapName DigitMapName,
5848 digitMapValue DigitMapValue
5851 SecondEventsDescriptor ::= SEQUENCE
5853 requestID RequestID OPTIONAL,
5854 eventList SEQUENCE OF SecondRequestedEvent,
5858 SecondRequestedEvent ::= SEQUENCE
5861 streamID StreamID OPTIONAL,
5862 eventAction SecondRequestedActions OPTIONAL,
5863 evParList SEQUENCE OF EventParameter,
5867 SecondRequestedActions ::= SEQUENCE
5869 keepActive BOOLEAN OPTIONAL,
5870 eventDM EventDM OPTIONAL,
5871 signalsDescriptor SignalsDescriptor OPTIONAL,
5875 EventBufferDescriptor ::= SEQUENCE OF EventSpec
5877 EventSpec ::= SEQUENCE
5882 Groves, et al. Standards Track [Page 105]
5884 RFC 3525 Gateway Control Protocol June 2003
5887 eventName EventName,
5888 streamID StreamID OPTIONAL,
5889 eventParList SEQUENCE OF EventParameter,
5893 SignalsDescriptor ::= SEQUENCE OF SignalRequest
5895 SignalRequest ::=CHOICE
5898 seqSigList SeqSigList,
5902 SeqSigList ::= SEQUENCE
5904 id INTEGER(0..65535),
5905 signalList SEQUENCE OF Signal
5910 signalName SignalName,
5911 streamID StreamID OPTIONAL,
5912 sigType SignalType OPTIONAL,
5913 duration INTEGER (0..65535) OPTIONAL,
5914 notifyCompletion NotifyCompletion OPTIONAL,
5915 keepActive BOOLEAN OPTIONAL,
5916 sigParList SEQUENCE OF SigParameter,
5920 SignalType ::= ENUMERATED
5928 SignalName ::= PkgdName
5930 NotifyCompletion ::= BIT STRING
5932 onTimeOut(0), onInterruptByEvent(1),
5933 onInterruptByNewSignalDescr(2), otherReason(3)
5938 Groves, et al. Standards Track [Page 106]
5940 RFC 3525 Gateway Control Protocol June 2003
5944 SigParameter ::= SEQUENCE
5946 sigParameterName Name,
5948 -- For use of extraInfo see the comment related to PropertyParm
5959 -- For an AuditCapReply with all events, the RequestID SHALL be ALL.
5960 -- ALL is represented by 0xffffffff.
5962 RequestID ::= INTEGER(0..4294967295) -- 32-bit unsigned integer
5964 ModemDescriptor ::= SEQUENCE
5966 mtl SEQUENCE OF ModemType,
5967 mpl SEQUENCE OF PropertyParm,
5968 nonStandardData NonStandardData OPTIONAL
5971 ModemType ::= ENUMERATED
5985 DigitMapDescriptor ::= SEQUENCE
5987 digitMapName DigitMapName OPTIONAL,
5988 digitMapValue DigitMapValue OPTIONAL
5994 Groves, et al. Standards Track [Page 107]
5996 RFC 3525 Gateway Control Protocol June 2003
5999 DigitMapName ::= Name
6001 DigitMapValue ::= SEQUENCE
6003 startTimer INTEGER(0..99) OPTIONAL,
6004 shortTimer INTEGER(0..99) OPTIONAL,
6005 longTimer INTEGER(0..99) OPTIONAL,
6006 digitMapBody IA5String,
6007 -- Units are seconds for start, short and long timers, and
6008 -- hundreds of milliseconds for duration timer. Thus start,
6009 -- short, and long range from 1 to 99 seconds and duration
6010 -- from 100 ms to 9.9 s
6011 -- See A.3 for explanation of digit map syntax
6015 ServiceChangeParm ::= SEQUENCE
6017 serviceChangeMethod ServiceChangeMethod,
6018 serviceChangeAddress ServiceChangeAddress OPTIONAL,
6019 serviceChangeVersion INTEGER(0..99) OPTIONAL,
6020 serviceChangeProfile ServiceChangeProfile OPTIONAL,
6021 serviceChangeReason Value,
6022 -- A serviceChangeReason consists of a numeric reason code
6023 -- and an optional text description.
6024 -- The serviceChangeReason SHALL be a string consisting of
6025 -- a decimal reason code, optionally followed by a single
6026 -- space character and a textual description string.
6027 -- This string is first BER-encoded as an IA5String.
6028 -- The result of this BER-encoding is then encoded as
6029 -- an ASN.1 OCTET STRING type, "double wrapping" the
6030 -- value as was done for package elements.
6031 serviceChangeDelay INTEGER(0..4294967295) OPTIONAL,
6032 -- 32-bit unsigned integer
6033 serviceChangeMgcId MId OPTIONAL,
6034 timeStamp TimeNotation OPTIONAL,
6035 nonStandardData NonStandardData OPTIONAL,
6039 ServiceChangeAddress ::= CHOICE
6041 portNumber INTEGER(0..65535), -- TCP/UDP port number
6042 ip4Address IP4Address,
6043 ip6Address IP6Address,
6044 domainName DomainName,
6045 deviceName PathName,
6046 mtpAddress OCTET STRING(SIZE(2..4)),
6050 Groves, et al. Standards Track [Page 108]
6052 RFC 3525 Gateway Control Protocol June 2003
6058 ServiceChangeResParm ::= SEQUENCE
6060 serviceChangeMgcId MId OPTIONAL,
6061 serviceChangeAddress ServiceChangeAddress OPTIONAL,
6062 serviceChangeVersion INTEGER(0..99) OPTIONAL,
6063 serviceChangeProfile ServiceChangeProfile OPTIONAL,
6064 timestamp TimeNotation OPTIONAL,
6068 ServiceChangeMethod ::= ENUMERATED
6080 ServiceChangeProfile ::= SEQUENCE
6082 profileName IA5String(SIZE (1..67))
6083 -- 64 characters for name, 1 for "/", 2 for version to match ABNF
6086 PackagesDescriptor ::= SEQUENCE OF PackagesItem
6088 PackagesItem ::= SEQUENCE
6091 packageVersion INTEGER(0..99),
6095 StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter
6097 StatisticsParameter ::= SEQUENCE
6100 statValue Value OPTIONAL
6106 Groves, et al. Standards Track [Page 109]
6108 RFC 3525 Gateway Control Protocol June 2003
6111 NonStandardData ::= SEQUENCE
6113 nonStandardIdentifier NonStandardIdentifier,
6117 NonStandardIdentifier ::= CHOICE
6119 object OBJECT IDENTIFIER,
6120 h221NonStandard H221NonStandard,
6121 experimental IA5String(SIZE(8)),
6122 -- first two characters should be "X-" or "X+"
6126 H221NonStandard ::= SEQUENCE
6127 { t35CountryCode1 INTEGER(0..255),
6128 t35CountryCode2 INTEGER(0..255), -- country, as per T.35
6129 t35Extension INTEGER(0..255), -- assigned nationally
6130 manufacturerCode INTEGER(0..65535), -- assigned nationally
6134 TimeNotation ::= SEQUENCE
6136 date IA5String(SIZE(8)), -- yyyymmdd format
6137 time IA5String(SIZE(8)) -- hhmmssss format
6138 -- per ISO 8601:1988
6141 Value ::= SEQUENCE OF OCTET STRING
6162 Groves, et al. Standards Track [Page 110]
6164 RFC 3525 Gateway Control Protocol June 2003
6167 A.3 Digit maps and path names
6169 From a syntactic viewpoint, digit maps are strings with syntactic
6170 restrictions imposed upon them. The syntax of valid digit maps is
6171 specified in ABNF [RFC 2234]. The syntax for digit maps presented in
6172 this subclause is for illustrative purposes only. The definition of
6173 digitMap in Annex B takes precedence in the case of differences
6176 digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")"
6179 digitStringList = digitString *( LWSP "|" LWSP digitString )
6180 digitString = 1*(digitStringElement)
6181 digitStringElement = digitPosition [DOT]
6182 digitPosition = digitMapLetter / digitMapRange
6183 digitMapRange = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
6184 digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter)
6185 digitMapLetter = DIGIT ;digits 0-9
6186 / %x41-4B / %x61-6B ;a-k and A-K
6187 / "L"/ "S" ;Inter-event timers
6189 / "Z" ;Long duration event
6191 LWSP = *(WSP / COMMENT / EOL)
6193 COMMENT = ";" *(SafeChar / RestChar / WSP) EOL
6194 EOL = (CR [LF]) / LF
6199 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" /
6200 "'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "\" /
6201 "(" / ")" / "%" / "."
6202 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
6203 "<" / ">" / "=" / %x22
6204 DIGIT = %x30-39 ; digits 0 through 9
6205 ALPHA = %x41-5A / %x61-7A; A-Z, a-z
6207 A path name is also a string with syntactic restrictions imposed upon
6208 it. The ABNF production defining it is copied from Annex B.
6210 ; Total length of pathNAME must not exceed 64 chars.
6211 pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
6212 ["@" pathDomainName ]
6218 Groves, et al. Standards Track [Page 111]
6220 RFC 3525 Gateway Control Protocol June 2003
6223 ; ABNF allows two or more consecutive "." although it is
6224 ; meaningless in a path domain name.
6225 pathDomainName = (ALPHA / DIGIT / "*" )
6226 *63(ALPHA / DIGIT / "-"
6227 NAME = ALPHA *63(ALPHA / DIGIT / "_" )
6274 Groves, et al. Standards Track [Page 112]
6276 RFC 3525 Gateway Control Protocol June 2003
6279 ANNEX B - Text encoding of the protocol
6281 B.1 Coding of wildcards
6283 In a text encoding of the protocol, while TerminationIDs are
6284 arbitrary, by judicious choice of names, the wildcard character, "*"
6285 may be made more useful. When the wildcard character is encountered,
6286 it will "match" all TerminationIDs having the same previous and
6287 following characters (if appropriate). For example, if there were
6288 TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
6289 R13/3/* would match all of them. There are some circumstances where
6290 ALL Terminations must be referred to. The TerminationID "*"
6291 suffices, and is referred to as ALL. The CHOOSE TerminationID "$"
6292 may be used to signal to the MG that it has to create an ephemeral
6293 Termination or select an idle physical Termination.
6295 B.2 ABNF specification
6297 The protocol syntax is presented in ABNF according to RFC 2234.
6299 Note 1 - This syntax specification does not enforce all
6300 restrictions on element inclusions and values. Some additional
6301 restrictions are stated in comments and other restrictions appear
6302 in the text of this RFC. These additional restrictions are part
6303 of the protocol even though not enforced by this specification.
6305 Note 2 - The syntax is context-dependent. For example, "Add" can
6306 be the AddToken or a NAME depending on the context in which it
6309 Everything in the ABNF and text encoding is case insensitive. This
6310 includes TerminationIDs, digitmap Ids etc. SDP is case sensitive as
6313 ; NOTE -- The ABNF in this section uses the VALUE construct (or lists
6314 ; of VALUE constructs) to encode various package element values
6315 ; (properties, signal parameters, etc.). The types of these values
6316 ; vary and are specified the relevant package definition. Several
6317 ; such types are described in section 12.2.
6319 ; The ABNF specification for VALUE allows a quotedString form or a
6320 ; collection of SafeChars. The encoding of package element values
6321 ; into ABNF VALUES is specified below. If a type's encoding allows
6322 ; characters other than SafeChars, the quotedString form MUST be used
6323 ; for all values of that type, even for specific values that consist
6324 ; only of SafeChars.
6330 Groves, et al. Standards Track [Page 113]
6332 RFC 3525 Gateway Control Protocol June 2003
6335 ; String: A string MUST use the quotedString form of VALUE and can
6336 ; contain anything allowable in the quotedString form.
6338 ; Integer, Double, and Unsigned Integer: Decimal values can be
6339 ; encoded using characters 0-9. Hexadecimal values must be prefixed
6340 ; with '0x' and can use characters 0-9,a-f,A-F. An octal format is
6341 ; not supported. Negative integers start with '-' and MUST be
6342 ; Decimal. The SafeChar form of VALUE MUST be used.
6344 ; Character: A UTF-8 encoding of a single letter surrounded by
6347 ; Enumeration: An enumeration MUST use the SafeChar form of VALUE
6348 ; and can contain anything allowable in the SafeChar form.
6350 ; Boolean: Boolean values are encoded as "on" and "off" and are
6351 ; case insensitive. The SafeChar form of VALUE MUST be used.
6353 ; Future types: Any defined types MUST fit within
6354 ; the ABNF specification of VALUE. Specifically, if a type's
6355 ; encoding allows characters other than SafeChars, the quotedString
6356 ; form MUST be used for all values of that type, even for specific
6357 ; values that consist only of SafeChars.
6359 ; Note that there is no way to use the double quote character within
6362 ; Note that SDP disallows whitespace at the beginning of a line,
6363 ; Megaco ABNF allows whitespace before the beginning of the SDP in
6364 ; the Local/Remote descriptor. Parsers should accept whitespace
6365 ; between the LBRKT following the Local/Remote token and the
6366 ; beginning of the SDP.
6368 megacoMessage = LWSP [authenticationHeader SEP ] message
6370 authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
6371 SequenceNum COLON AuthData
6373 SecurityParmIndex = "0x" 8(HEXDIG)
6374 SequenceNum = "0x" 8(HEXDIG)
6375 AuthData = "0x" 24*64(HEXDIG)
6377 message = MegacopToken SLASH Version SEP mId SEP
6379 ; The version of the protocol defined here is equal to 1.
6381 messageBody = ( errorDescriptor / transactionList )
6386 Groves, et al. Standards Track [Page 114]
6388 RFC 3525 Gateway Control Protocol June 2003
6391 transactionList = 1*( transactionRequest / transactionReply /
6392 transactionPending / transactionResponseAck )
6393 ;Use of response acks is dependent on underlying transport
6396 transactionPending = PendingToken EQUAL TransactionID LBRKT
6399 transactionResponseAck = ResponseAckToken LBRKT transactionAck
6400 *(COMMA transactionAck) RBRKT
6401 transactionAck = transactionID / (transactionID "-" transactionID)
6403 transactionRequest = TransToken EQUAL TransactionID LBRKT
6404 actionRequest *(COMMA actionRequest) RBRKT
6406 actionRequest = CtxToken EQUAL ContextID LBRKT ((
6407 contextRequest [COMMA commandRequestList])
6408 / commandRequestList) RBRKT
6410 contextRequest = ((contextProperties [COMMA contextAudit])
6413 contextProperties = contextProperty *(COMMA contextProperty)
6416 contextProperty = (topologyDescriptor / priority / EmergencyToken)
6418 contextAudit = ContextAuditToken LBRKT contextAuditProperties
6419 *(COMMA contextAuditProperties) RBRKT
6422 contextAuditProperties = ( TopologyToken / EmergencyToken /
6425 ; "O-" indicates an optional command
6426 ; "W-" indicates a wildcarded response to a command
6427 commandRequestList = ["O-"] ["W-"] commandRequest
6428 *(COMMA ["O-"] ["W-"]commandRequest)
6430 commandRequest = ( ammRequest / subtractRequest / auditRequest /
6431 notifyRequest / serviceChangeRequest)
6433 transactionReply = ReplyToken EQUAL TransactionID LBRKT
6434 [ ImmAckRequiredToken COMMA]
6435 ( errorDescriptor / actionReplyList ) RBRKT
6437 actionReplyList = actionReply *(COMMA actionReply )
6442 Groves, et al. Standards Track [Page 115]
6444 RFC 3525 Gateway Control Protocol June 2003
6447 actionReply = CtxToken EQUAL ContextID LBRKT
6448 ( errorDescriptor / commandReply ) /
6449 (commandReply COMMA errorDescriptor) ) RBRKT
6451 commandReply = (( contextProperties [COMMA commandReplyList] ) /
6455 commandReplyList = commandReplys *(COMMA commandReplys )
6457 commandReplys = (serviceChangeReply / auditReply / ammsReply /
6460 ;Add Move and Modify have the same request parameters
6461 ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL
6462 TerminationID [LBRKT ammParameter *(COMMA
6463 ammParameter) RBRKT]
6466 ammParameter = (mediaDescriptor / modemDescriptor /
6467 muxDescriptor / eventsDescriptor /
6468 signalsDescriptor / digitMapDescriptor /
6469 eventBufferDescriptor / auditDescriptor)
6471 ammsReply = (AddToken / MoveToken / ModifyToken /
6472 SubtractToken ) EQUAL TerminationID [ LBRKT
6473 terminationAudit RBRKT ]
6475 subtractRequest = SubtractToken EQUAL TerminationID
6476 [ LBRKT auditDescriptor RBRKT]
6478 auditRequest = (AuditValueToken / AuditCapToken ) EQUAL
6479 TerminationID LBRKT auditDescriptor RBRKT
6481 auditReply = (AuditValueToken / AuditCapToken )
6482 ( contextTerminationAudit / auditOther)
6484 auditOther = EQUAL TerminationID [LBRKT
6485 terminationAudit RBRKT]
6487 terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)
6489 contextTerminationAudit = EQUAL CtxToken ( terminationIDList /
6490 LBRKT errorDescriptor RBRKT )
6492 auditReturnParameter = (mediaDescriptor / modemDescriptor /
6493 muxDescriptor / eventsDescriptor /
6494 signalsDescriptor / digitMapDescriptor /
6498 Groves, et al. Standards Track [Page 116]
6500 RFC 3525 Gateway Control Protocol June 2003
6503 observedEventsDescriptor / eventBufferDescriptor /
6504 statisticsDescriptor / packagesDescriptor /
6505 errorDescriptor / auditItem)
6507 auditDescriptor = AuditToken LBRKT [ auditItem
6508 *(COMMA auditItem) ] RBRKT
6510 notifyRequest = NotifyToken EQUAL TerminationID
6511 LBRKT ( observedEventsDescriptor
6512 [ COMMA errorDescriptor ] ) RBRKT
6514 notifyReply = NotifyToken EQUAL TerminationID
6515 [ LBRKT errorDescriptor RBRKT ]
6517 serviceChangeRequest = ServiceChangeToken EQUAL TerminationID
6518 LBRKT serviceChangeDescriptor RBRKT
6520 serviceChangeReply = ServiceChangeToken EQUAL TerminationID
6521 [LBRKT (errorDescriptor /
6522 serviceChangeReplyDescriptor) RBRKT]
6524 errorDescriptor = ErrorToken EQUAL ErrorCode
6525 LBRKT [quotedString] RBRKT
6527 ErrorCode = 1*4(DIGIT) ; could be extended
6529 TransactionID = UINT32
6531 mId = (( domainAddress / domainName )
6532 [":" portNumber]) / mtpAddress / deviceName
6534 ; ABNF allows two or more consecutive "." although it is meaningless
6536 domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" /
6538 deviceName = pathNAME
6540 ;The values 0x0, 0xFFFFFFFE and 0xFFFFFFFF are reserved.
6541 ContextID = (UINT32 / "*" / "-" / "$")
6543 domainAddress = "[" (IPv4address / IPv6address) "]"
6544 ;RFC2373 contains the definition of IP6Addresses.
6545 IPv6address = hexpart [ ":" IPv4address ]
6546 IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex
6547 V4hex = 1*3(DIGIT) ; "0".."255"
6548 ; this production, while occurring in RFC2373, is not referenced
6549 ; IPv6prefix = hexpart SLASH 1*2DIGIT
6550 hexpart = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
6554 Groves, et al. Standards Track [Page 117]
6556 RFC 3525 Gateway Control Protocol June 2003
6559 hexseq = hex4 *( ":" hex4)
6564 ; Addressing structure of mtpAddress:
6567 ; 24 - 14 bits 2 bits
6568 ; Note: 14 bits are defined for international use.
6569 ; Two national options exist where the point code is 16 or 24 bits.
6570 ; To octet align the mtpAddress the MSBs shall be encoded as 0s.
6571 ; An octet shall be represented by 2 hex digits.
6572 mtpAddress = MTPToken LBRKT 4*8 (HEXDIG) RBRKT
6574 terminationIDList = LBRKT TerminationID *(COMMA TerminationID) RBRKT
6576 ; Total length of pathNAME must not exceed 64 chars.
6577 pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
6578 ["@" pathDomainName ]
6580 ; ABNF allows two or more consecutive "." although it is meaningless
6581 ; in a path domain name.
6582 pathDomainName = (ALPHA / DIGIT / "*" )
6583 *63(ALPHA / DIGIT / "-" / "*" / ".")
6585 TerminationID = "ROOT" / pathNAME / "$" / "*"
6587 mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT
6589 ; at-most one terminationStateDescriptor
6590 ; and either streamParm(s) or streamDescriptor(s) but not both
6591 mediaParm = (streamParm / streamDescriptor /
6592 terminationStateDescriptor)
6594 ; at-most-once per item
6595 streamParm = ( localDescriptor / remoteDescriptor /
6596 localControlDescriptor )
6598 streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm
6599 *(COMMA streamParm) RBRKT
6601 localControlDescriptor = LocalControlToken LBRKT localParm
6602 *(COMMA localParm) RBRKT
6604 ; at-most-once per item except for propertyParm
6605 localParm = ( streamMode / propertyParm / reservedValueMode
6606 / reservedGroupMode )
6610 Groves, et al. Standards Track [Page 118]
6612 RFC 3525 Gateway Control Protocol June 2003
6616 reservedValueMode = ReservedValueToken EQUAL ( "ON" / "OFF" )
6617 reservedGroupMode = ReservedGroupToken EQUAL ( "ON" / "OFF" )
6619 streamMode = ModeToken EQUAL streamModes
6621 streamModes = (SendonlyToken / RecvonlyToken / SendrecvToken /
6622 InactiveToken / LoopbackToken )
6624 propertyParm = pkgdName parmValue
6625 parmValue = (EQUAL alternativeValue/ INEQUAL VALUE)
6626 alternativeValue = ( VALUE
6627 / LSBRKT VALUE *(COMMA VALUE) RSBRKT
6628 ; sublist (i.e., A AND B AND ...)
6629 / LBRKT VALUE *(COMMA VALUE) RBRKT
6630 ; alternatives (i.e., A OR B OR ...)
6631 / LSBRKT VALUE COLON VALUE RSBRKT )
6634 INEQUAL = LWSP (">" / "<" / "#" ) LWSP
6635 LSBRKT = LWSP "[" LWSP
6636 RSBRKT = LWSP "]" LWSP
6638 ; Note - The octet zero is not among the permitted characters in
6639 ; octet string. As the current definition is limited to SDP, and a
6640 ; zero octet would not be a legal character in SDP, this is not a
6643 localDescriptor = LocalToken LBRKT octetString RBRKT
6645 remoteDescriptor = RemoteToken LBRKT octetString RBRKT
6647 eventBufferDescriptor= EventBufferToken [ LBRKT eventSpec
6648 *( COMMA eventSpec) RBRKT ]
6650 eventSpec = pkgdName [ LBRKT eventSpecParameter
6651 *(COMMA eventSpecParameter) RBRKT ]
6652 eventSpecParameter = (eventStream / eventOther)
6654 eventBufferControl = BufferToken EQUAL ( "OFF" / LockStepToken )
6656 terminationStateDescriptor = TerminationStateToken LBRKT
6657 terminationStateParm *( COMMA terminationStateParm ) RBRKT
6659 ; at-most-once per item except for propertyParm
6660 terminationStateParm = (propertyParm / serviceStates /
6661 eventBufferControl )
6666 Groves, et al. Standards Track [Page 119]
6668 RFC 3525 Gateway Control Protocol June 2003
6671 serviceStates = ServiceStatesToken EQUAL ( TestToken /
6672 OutOfSvcToken / InSvcToken )
6674 muxDescriptor = MuxToken EQUAL MuxType terminationIDList
6676 MuxType = ( H221Token / H223Token / H226Token / V76Token
6677 / extensionParameter )
6680 pkgdName = (PackageName SLASH ItemID) ;specific item
6681 / (PackageName SLASH "*") ;all items in package
6682 / ("*" SLASH "*") ; all items supported by the MG
6686 eventsDescriptor = EventsToken [ EQUAL RequestID LBRKT
6687 requestedEvent *( COMMA requestedEvent ) RBRKT ]
6689 requestedEvent = pkgdName [ LBRKT eventParameter
6690 *( COMMA eventParameter ) RBRKT ]
6692 ; at-most-once each of KeepActiveToken , eventDM and eventStream
6693 ;at most one of either embedWithSig or embedNoSig but not both
6694 ;KeepActiveToken and embedWithSig must not both be present
6695 eventParameter = ( embedWithSig / embedNoSig / KeepActiveToken
6696 /eventDM / eventStream / eventOther )
6698 embedWithSig = EmbedToken LBRKT signalsDescriptor
6699 [COMMA embedFirst ] RBRKT
6700 embedNoSig = EmbedToken LBRKT embedFirst RBRKT
6702 ; at-most-once of each
6703 embedFirst = EventsToken [ EQUAL RequestID LBRKT
6704 secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT ]
6706 secondRequestedEvent = pkgdName [ LBRKT secondEventParameter
6707 *( COMMA secondEventParameter ) RBRKT ]
6709 ; at-most-once each of embedSig , KeepActiveToken, eventDM or
6711 ; KeepActiveToken and embedSig must not both be present
6712 secondEventParameter = ( embedSig / KeepActiveToken / eventDM /
6713 eventStream / eventOther )
6715 embedSig = EmbedToken LBRKT signalsDescriptor RBRKT
6717 eventStream = StreamToken EQUAL StreamID
6722 Groves, et al. Standards Track [Page 120]
6724 RFC 3525 Gateway Control Protocol June 2003
6727 eventOther = eventParameterName parmValue
6729 eventParameterName = NAME
6731 eventDM = DigitMapToken EQUAL(( digitMapName ) /
6732 (LBRKT digitMapValue RBRKT ))
6734 signalsDescriptor = SignalsToken LBRKT [ signalParm
6735 *(COMMA signalParm)] RBRKT
6737 signalParm = signalList / signalRequest
6739 signalRequest = signalName [ LBRKT sigParameter
6740 *(COMMA sigParameter) RBRKT ]
6742 signalList = SignalListToken EQUAL signalListId LBRKT
6743 signalListParm *(COMMA signalListParm) RBRKT
6745 signalListId = UINT16
6747 ;exactly once signalType, at most once duration and every signal
6749 signalListParm = signalRequest
6751 signalName = pkgdName
6752 ;at-most-once sigStream, at-most-once sigSignalType,
6753 ;at-most-once sigDuration, every signalParameterName at most once
6754 sigParameter = sigStream / sigSignalType / sigDuration / sigOther
6755 / notifyCompletion / KeepActiveToken
6756 sigStream = StreamToken EQUAL StreamID
6757 sigOther = sigParameterName parmValue
6758 sigParameterName = NAME
6759 sigSignalType = SignalTypeToken EQUAL signalType
6760 signalType = (OnOffToken / TimeOutToken / BriefToken)
6761 sigDuration = DurationToken EQUAL UINT16
6762 notifyCompletion = NotifyCompletionToken EQUAL (LBRKT
6763 notificationReason *(COMMA notificationReason) RBRKT)
6765 notificationReason = ( TimeOutToken / InterruptByEventToken
6766 / InterruptByNewSignalsDescrToken
6767 / OtherReasonToken )
6768 observedEventsDescriptor = ObservedEventsToken EQUAL RequestID
6769 LBRKT observedEvent *(COMMA observedEvent) RBRKT
6771 ;time per event, because it might be buffered
6772 observedEvent = [ TimeStamp LWSP COLON] LWSP
6773 pkgdName [ LBRKT observedEventParameter
6774 *(COMMA observedEventParameter) RBRKT ]
6778 Groves, et al. Standards Track [Page 121]
6780 RFC 3525 Gateway Control Protocol June 2003
6784 ;at-most-once eventStream, every eventParameterName at most once
6785 observedEventParameter = eventStream / eventOther
6787 ; For an AuditCapReply with all events, the RequestID should be ALL.
6788 RequestID = ( UINT32 / "*" )
6790 modemDescriptor = ModemToken (( EQUAL modemType) /
6791 (LSBRKT modemType *(COMMA modemType) RSBRKT))
6792 [ LBRKT propertyParm *(COMMA propertyParm) RBRKT ]
6795 ; at-most-once except for extensionParameter
6796 modemType = (V32bisToken / V22bisToken / V18Token /
6797 V22Token / V32Token / V34Token / V90Token /
6798 V91Token / SynchISDNToken / extensionParameter)
6800 digitMapDescriptor = DigitMapToken EQUAL
6801 ( ( LBRKT digitMapValue RBRKT ) /
6802 (digitMapName [ LBRKT digitMapValue RBRKT ]) )
6804 digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA]
6805 ["L" COLON Timer COMMA] digitMap
6807 ; Units are seconds for T, S, and L timers, and hundreds of
6808 ; milliseconds for Z timer. Thus T, S, and L range from 1 to 99
6809 ; seconds and Z from 100 ms to 9.9 s
6810 digitMap = (digitString /
6811 LWSP "(" LWSP digitStringList LWSP ")" LWSP)
6812 digitStringList = digitString *( LWSP "|" LWSP digitString )
6813 digitString = 1*(digitStringElement)
6814 digitStringElement = digitPosition [DOT]
6815 digitPosition = digitMapLetter / digitMapRange
6816 digitMapRange = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
6817 digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter)
6818 digitMapLetter = DIGIT ;Basic event symbols
6819 / %x41-4B / %x61-6B ; a-k, A-K
6820 / "L" / "S" ;Inter-event timers (long, short)
6821 / "Z" ;Long duration modifier
6823 ;at-most-once, and DigitMapToken and PackagesToken are not allowed
6824 ;in AuditCapabilities command
6825 auditItem = ( MuxToken / ModemToken / MediaToken /
6826 SignalsToken / EventBufferToken /
6827 DigitMapToken / StatsToken / EventsToken /
6828 ObservedEventsToken / PackagesToken )
6834 Groves, et al. Standards Track [Page 122]
6836 RFC 3525 Gateway Control Protocol June 2003
6839 serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
6840 *(COMMA serviceChangeParm) RBRKT
6842 ; each parameter at-most-once
6843 ; at most one of either serviceChangeAddress or serviceChangeMgcId
6845 ; serviceChangeMethod and serviceChangeReason are REQUIRED
6846 serviceChangeParm = (serviceChangeMethod / serviceChangeReason /
6847 serviceChangeDelay / serviceChangeAddress /
6848 serviceChangeProfile / extension / TimeStamp /
6849 serviceChangeMgcId / serviceChangeVersion )
6851 serviceChangeReplyDescriptor = ServicesToken LBRKT
6852 servChgReplyParm *(COMMA servChgReplyParm) RBRKT
6854 ; at-most-once. Version is REQUIRED on first ServiceChange response
6855 ; at most one of either serviceChangeAddress or serviceChangeMgcId
6857 servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId /
6858 serviceChangeProfile / serviceChangeVersion /
6860 serviceChangeMethod = MethodToken EQUAL (FailoverToken /
6861 ForcedToken / GracefulToken / RestartToken /
6862 DisconnectedToken / HandOffToken /
6864 ; A serviceChangeReason consists of a numeric reason code
6865 ; and an optional text description.
6866 ; A serviceChangeReason MUST be encoded using the quotedString
6868 ; The quotedString SHALL contain a decimal reason code,
6869 ; optionally followed by a single space character and a
6870 ; textual description string.
6873 serviceChangeReason = ReasonToken EQUAL VALUE
6874 serviceChangeDelay = DelayToken EQUAL UINT32
6875 serviceChangeAddress = ServiceChangeAddressToken EQUAL ( mId /
6877 serviceChangeMgcId = MgcIdToken EQUAL mId
6878 serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
6879 serviceChangeVersion = VersionToken EQUAL Version
6880 extension = extensionParameter parmValue
6882 packagesDescriptor = PackagesToken LBRKT packagesItem
6883 *(COMMA packagesItem) RBRKT
6885 Version = 1*2(DIGIT)
6886 packagesItem = NAME "-" UINT16
6890 Groves, et al. Standards Track [Page 123]
6892 RFC 3525 Gateway Control Protocol June 2003
6896 TimeStamp = Date "T" Time ; per ISO 8601:1988
6901 statisticsDescriptor = StatsToken LBRKT statisticsParameter
6902 *(COMMA statisticsParameter ) RBRKT
6904 ;at-most-once per item
6905 statisticsParameter = pkgdName [EQUAL VALUE]
6907 topologyDescriptor = TopologyToken LBRKT topologyTriple
6908 *(COMMA topologyTriple) RBRKT
6909 topologyTriple = terminationA COMMA
6910 terminationB COMMA topologyDirection
6911 terminationA = TerminationID
6912 terminationB = TerminationID
6913 topologyDirection = BothwayToken / IsolateToken / OnewayToken
6915 priority = PriorityToken EQUAL UINT16
6917 extensionParameter = "X" ("-" / "+") 1*6(ALPHA / DIGIT)
6919 ; octetString is used to describe SDP defined in RFC2327.
6920 ; Caution should be taken if CRLF in RFC2327 is used.
6921 ; To be safe, use EOL in this ABNF.
6922 ; Whenever "}" appears in SDP, it is escaped by "\", e.g., "\}"
6923 octetString = *(nonEscapeChar)
6924 nonEscapeChar = ( "\}" / %x01-7C / %x7E-FF )
6925 ; Note - The double-quote character is not allowed in quotedString.
6926 quotedString = DQUOTE *(SafeChar / RestChar/ WSP) DQUOTE
6928 UINT16 = 1*5(DIGIT) ; %x0-FFFF
6929 UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF
6931 NAME = ALPHA *63(ALPHA / DIGIT / "_" )
6932 VALUE = quotedString / 1*(SafeChar)
6933 SafeChar = DIGIT / ALPHA / "+" / "-" / "&" /
6934 "!" / "_" / "/" / "\'" / "?" / "@" /
6935 "^" / "`" / "~" / "*" / "$" / "\" /
6936 "(" / ")" / "%" / "|" / "."
6938 EQUAL = LWSP %x3D LWSP ; "="
6940 LBRKT = LWSP %x7B LWSP ; "{"
6941 RBRKT = LWSP %x7D LWSP ; "}"
6942 COMMA = LWSP %x2C LWSP ; ","
6946 Groves, et al. Standards Track [Page 124]
6948 RFC 3525 Gateway Control Protocol June 2003
6953 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
6954 DIGIT = %x30-39 ; 0-9
6955 DQUOTE = %x22 ; " (Double Quote)
6956 HEXDIG = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )
6958 HTAB = %x09 ; horizontal tab
6959 CR = %x0D ; Carriage return
6960 LF = %x0A ; linefeed
6961 LWSP = *( WSP / COMMENT / EOL )
6962 EOL = (CR [LF] / LF )
6963 WSP = SP / HTAB ; white space
6964 SEP = ( WSP / EOL / COMMENT) LWSP
6965 COMMENT = ";" *(SafeChar/ RestChar / WSP / %x22) EOL
6966 RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
6969 ; New Tokens added to sigParameter must take the format of SPA*
6970 ; * may be of any form i.e., SPAM
6971 ; New Tokens added to eventParameter must take the form of EPA*
6972 ; * may be of any form i.e., EPAD
6974 AddToken = ("Add" / "A")
6975 AuditToken = ("Audit" / "AT")
6976 AuditCapToken = ("AuditCapability" / "AC")
6977 AuditValueToken = ("AuditValue" / "AV")
6978 AuthToken = ("Authentication" / "AU")
6979 BothwayToken = ("Bothway" / "BW")
6980 BriefToken = ("Brief" / "BR")
6981 BufferToken = ("Buffer" / "BF")
6982 CtxToken = ("Context" / "C")
6983 ContextAuditToken = ("ContextAudit" / "CA")
6984 DigitMapToken = ("DigitMap" / "DM")
6985 DisconnectedToken = ("Disconnected" / "DC")
6986 DelayToken = ("Delay" / "DL")
6987 DurationToken = ("Duration" / "DR")
6988 EmbedToken = ("Embed" / "EM")
6989 EmergencyToken = ("Emergency" / "EG")
6990 ErrorToken = ("Error" / "ER")
6991 EventBufferToken = ("EventBuffer" / "EB")
6992 EventsToken = ("Events" / "E")
6993 FailoverToken = ("Failover" / "FL")
6994 ForcedToken = ("Forced" / "FO")
6995 GracefulToken = ("Graceful" / "GR")
6996 H221Token = ("H221" )
6997 H223Token = ("H223" )
6998 H226Token = ("H226" )
7002 Groves, et al. Standards Track [Page 125]
7004 RFC 3525 Gateway Control Protocol June 2003
7007 HandOffToken = ("HandOff" / "HO")
7008 ImmAckRequiredToken = ("ImmAckRequired" / "IA")
7009 InactiveToken = ("Inactive" / "IN")
7010 IsolateToken = ("Isolate" / "IS")
7011 InSvcToken = ("InService" / "IV")
7012 InterruptByEventToken = ("IntByEvent" / "IBE")
7013 InterruptByNewSignalsDescrToken
7014 = ("IntBySigDescr" / "IBS")
7015 KeepActiveToken = ("KeepActive" / "KA")
7016 LocalToken = ("Local" / "L")
7017 LocalControlToken = ("LocalControl" / "O")
7018 LockStepToken = ("LockStep" / "SP")
7019 LoopbackToken = ("Loopback" / "LB")
7020 MediaToken = ("Media" / "M")
7021 MegacopToken = ("MEGACO" / "!")
7022 MethodToken = ("Method" / "MT")
7023 MgcIdToken = ("MgcIdToTry" / "MG")
7024 ModeToken = ("Mode" / "MO")
7025 ModifyToken = ("Modify" / "MF")
7026 ModemToken = ("Modem" / "MD")
7027 MoveToken = ("Move" / "MV")
7029 MuxToken = ("Mux" / "MX")
7030 NotifyToken = ("Notify" / "N")
7031 NotifyCompletionToken = ("NotifyCompletion" / "NC")
7032 ObservedEventsToken = ("ObservedEvents" / "OE")
7033 OnewayToken = ("Oneway" / "OW")
7034 OnOffToken = ("OnOff" / "OO")
7035 OtherReasonToken = ("OtherReason" / "OR")
7036 OutOfSvcToken = ("OutOfService" / "OS")
7037 PackagesToken = ("Packages" / "PG")
7038 PendingToken = ("Pending" / "PN")
7039 PriorityToken = ("Priority" / "PR")
7040 ProfileToken = ("Profile" / "PF")
7041 ReasonToken = ("Reason" / "RE")
7042 RecvonlyToken = ("ReceiveOnly" / "RC")
7043 ReplyToken = ("Reply" / "P")
7044 RestartToken = ("Restart" / "RS")
7045 RemoteToken = ("Remote" / "R")
7046 ReservedGroupToken = ("ReservedGroup" / "RG")
7047 ReservedValueToken = ("ReservedValue" / "RV")
7048 SendonlyToken = ("SendOnly" / "SO")
7049 SendrecvToken = ("SendReceive" / "SR")
7050 ServicesToken = ("Services" / "SV")
7051 ServiceStatesToken = ("ServiceStates" / "SI")
7052 ServiceChangeToken = ("ServiceChange" / "SC")
7053 ServiceChangeAddressToken = ("ServiceChangeAddress" / "AD")
7054 SignalListToken = ("SignalList" / "SL")
7058 Groves, et al. Standards Track [Page 126]
7060 RFC 3525 Gateway Control Protocol June 2003
7063 SignalsToken = ("Signals" / "SG")
7064 SignalTypeToken = ("SignalType" / "SY")
7065 StatsToken = ("Statistics" / "SA")
7066 StreamToken = ("Stream" / "ST")
7067 SubtractToken = ("Subtract" / "S")
7068 SynchISDNToken = ("SynchISDN" / "SN")
7069 TerminationStateToken = ("TerminationState" / "TS")
7070 TestToken = ("Test" / "TE")
7071 TimeOutToken = ("TimeOut" / "TO")
7072 TopologyToken = ("Topology" / "TP")
7073 TransToken = ("Transaction" / "T")
7074 ResponseAckToken = ("TransactionResponseAck" / "K")
7077 V22bisToken = ("V22b")
7079 V32bisToken = ("V32b")
7084 VersionToken = ("Version" / "V")
7086 B.3 Hexadecimal octet coding
7088 Hexadecimal octet coding is a means for representing a string of
7089 octets as a string of hexadecimal digits, with two digits
7090 representing each octet. This octet encoding should be used when
7091 encoding octet strings in the text version of the protocol. For each
7092 octet, the 8-bit sequence is encoded as two hexadecimal digits. Bit
7093 0 is the first transmitted; bit 7 is the last. Bits 7-4 are encoded
7094 as the first hexadecimal digit, with Bit 7 as MSB and Bit 4 as LSB.
7095 Bits 3-0 are encoded as the second hexadecimal digit, with Bit 3 as
7096 MSB and Bit 0 as LSB. Examples:
7098 Octet bit pattern Hexadecimal coding
7101 10000011 10100010 11001000 00001001 C1451390
7103 B.4 Hexadecimal octet sequence
7105 A hexadecimal octet sequence is an even number of hexadecimal digits,
7106 terminated by a <CR> character.
7114 Groves, et al. Standards Track [Page 127]
7116 RFC 3525 Gateway Control Protocol June 2003
7119 ANNEX C - Tags for media stream properties
7121 Parameters for Local, Remote and LocalControl descriptors are
7122 specified as tag-value pairs if binary encoding is used for the
7123 protocol. This annex contains the property names (PropertyID), the
7124 tags (Property tag), type of the property (Type) and the values
7125 (Value). Values presented in the Value field when the field contains
7126 references shall be regarded as "information". The reference
7127 contains the normative values. If a value field does not contain a
7128 reference, then the values in that field can be considered as
7131 Tags are given as hexadecimal numbers in this annex. When setting
7132 the value of a property, a MGC may underspecify the value according
7133 to one of the mechanisms specified in 7.1.1.
7135 It is optional to support the properties in this Annex or any of its
7136 sub-sections. For example, only three properties from C.3 and only
7137 five properties from C.8 might be implemented.
7139 For type "enumeration" the value is represented by the value in
7140 brackets, e.g., Send(0), Receive(1). Annex C properties with the
7141 types "N bits" or "M Octets" should be treated as octet strings when
7142 encoding the protocol. Properties with "N bit integer" shall be
7143 treated as an integers. "String" shall be treated as an IA5String
7144 when encoding the protocol.
7146 When a type is smaller than one octet, the value shall be stored in
7147 the low-order bits of an octet string of size 1.
7149 C.1 General media attributes
7151 PropertyID Property Type Value
7154 Media 1001 Enumeration Audio(0), Video(1), Data(2)
7156 Transmission 1002 Enumeration Send(0), Receive(1),
7157 mode Send&Receive(2)
7159 Number of 1003 Unsigned 0-255
7162 Sampling 1004 Unsigned 0-2^32
7165 Bitrate 1005 Integer (0..4294967295)NOTE - Units of
7170 Groves, et al. Standards Track [Page 128]
7172 RFC 3525 Gateway Control Protocol June 2003
7175 ACodec 1006 Octet string Audio Codec Type:
7177 Non-ITU-T codecs are defined
7178 with the appropriate standards
7179 organization under a defined
7180 Organizational Identifier.
7182 Samplepp 1007 Unsigned Maximum samples or frames per
7183 integer packet: 0..65535
7185 Silencesupp 1008 Boolean Silence Suppression: True/False
7187 Encrypttype 1009 Octet string Ref.: ITU-T H.245
7189 Encryptkey 100A Octet string Encryption key
7190 size Ref.: ITU-T H.235
7193 Echocanc 100B Not Used. See H.248.1 E.13 for
7194 an example of possible Echo
7197 Gain 100C Unsigned Gain in dB: 0..65535
7200 Jitterbuff 100D Unsigned Jitter buffer size in ms:
7203 PropDelay 100E Unsigned Propagation Delay: 0..65535
7204 integer Maximum propagation delay in
7205 milliseconds for the bearer
7206 connection between two media
7207 gateways. The maximum delay
7208 will be dependent on the bearer
7211 RTPpayload 100F Integer Payload type in RTP Profile for
7212 Audio and Video Conferences
7213 with Minimal Control
7226 Groves, et al. Standards Track [Page 129]
7228 RFC 3525 Gateway Control Protocol June 2003
7233 PropertyID Property tag Type Value
7235 H222 2001 Octet string H222LogicalChannelParameters
7238 H223 2002 Octet string H223LogicalChannelParameters
7241 V76 2003 Octet string V76LogicalChannelParameters
7244 H2250 2004 Octet string H2250LogicalChannelParameters
7247 C.3 General bearer properties
7249 PropertyID Property Type Value
7252 Mediatx 3001 Enumeration Media Transport TypeTDM
7253 Circuit(0), ATM(1), FR(2),
7254 Ipv4(3), Ipv6(4), ...
7256 BIR 3002 4 octets Value depends on transport
7259 NSAP 3003 1-20 octets See NSAP.
7262 C.4 General ATM properties
7264 PropertyID Property Type Value
7267 AESA 4001 20 octets ATM End System Address
7269 VPVC 4002 4 octets: VPCI VPCI/VCI
7271 least Ref.: ITU-T Q.2931
7282 Groves, et al. Standards Track [Page 130]
7284 RFC 3525 Gateway Control Protocol June 2003
7287 SC 4003 Enumeration Service Category: CBR(0),
7288 nrt-VBR1(1), nrt VBR2(2),
7289 nrt-VBR3(3), rt-VBR1(4),
7290 rt VBR2(5), rt-VBR3(6),
7291 UBR1(7), UBR2(8), ABR(9).
7292 Ref.: ATM Forum UNI 4.0
7294 BCOB 4004 5-bit integer Broadband Bearer Class
7295 Ref.: ITU-T Q.2961.2
7297 BBTC 4005 7-bit integer Broadband Transfer Capability
7298 Ref.: ITU-T Q.2961.1
7300 ATC 4006 Enumeration I.371 ATM Traffic
7301 CapabilityDBR(0), SBR1(1),
7302 SBR2(2), SBR3(3), ABT/IT(4),
7306 STC 4007 2 bits Susceptibility to clipping:
7310 0 0 not susceptible to
7316 UPCC 4008 2 bits User Plane Connection
7322 0 1 point-to-multipoint
7325 PCR0 4009 24-bit integer Peak Cell Rate (For CLP = 0)
7328 SCR0 400A 24-bit integer Sustainable Cell Rate (For
7330 Ref.: ITU-T Q.2961.1
7332 MBS0 400B 24-bit integer Maximum Burst Size (For CLP =
7334 Ref.: ITU-T Q.2961.1
7338 Groves, et al. Standards Track [Page 131]
7340 RFC 3525 Gateway Control Protocol June 2003
7343 PCR1 400C 24-bit integer Peak Cell Rate (For CLP = 0 +
7347 SCR1 400D 24-bit integer Sustainable Cell Rate (For
7349 Ref.: ITU-T Q.2961.1
7351 MBS1 400E 24-bit integer Maximum Burst Size (For CLP =
7353 Ref.: ITU-T Q.2961.1
7355 BEI 400F Boolean Best Effort Indicator
7356 Value 1 indicates that BEI is
7357 to be included in the ATM
7358 signaling; value 0 indicates
7359 that BEI is not to be
7362 Ref.: ATM Forum UNI 4.0
7364 TI 4010 Boolean Tagging Indicator
7365 Value 0 indicates that
7366 tagging is not allowed; value
7367 1 indicates that tagging is
7369 Ref.: ITU-T Q.2961.1
7371 FD 4011 Boolean Frame Discard
7372 Value 0 indicates that no
7373 frame discard is allowed;
7374 value 1 indicates that frame
7376 Ref.: ATM Forum UNI 4.0
7378 A2PCDV 4012 24-bit integer Acceptable 2-point CDV
7379 Ref.: ITU-T Q.2965.2
7381 C2PCDV 4013 24-bit integer Cumulative 2-point CDV
7382 Ref.: ITU-T Q.2965.2
7384 APPCDV 4014 24-bit integer Acceptable P-P CDV
7385 Ref.: ATM Forum UNI 4.0
7387 CPPCDV 4015 24-bit integer Cumulative P-P CDV
7388 Ref.: ATM Forum UNI 4.0
7394 Groves, et al. Standards Track [Page 132]
7396 RFC 3525 Gateway Control Protocol June 2003
7399 ACLR 4016 8-bit integer Acceptable Cell Loss Ratio
7400 Ref.: ITU-T Q.2965.2, ATM
7403 MEETD 4017 16-bit integer Maximum End-to-end transit
7405 Ref.: ITU-T Q.2965.2, ATM
7408 CEETD 4018 16-bit integer Cumulative End-to-end transit
7410 Ref.: ITU-T Q.2965.2, ATM
7413 QosClass 4019 Integer 0-5 QoS Class
7434 Ref.: ITU-T Q.2965.1
7436 AALtype 401A 1 octet AAL Type
7440 0 0 0 0 0 0 0 0 AAL for
7442 0 0 0 0 0 0 0 1 AAL type 1
7443 0 0 0 0 0 0 1 0 AAL type 2
7444 0 0 0 0 0 0 1 1 AAL type
7446 0 0 0 0 0 1 0 1 AAL type 5
7450 Groves, et al. Standards Track [Page 133]
7452 RFC 3525 Gateway Control Protocol June 2003
7455 0 0 0 1 0 0 0 0 user-
7461 PropertyID Property Type Value
7464 DLCI 5001 Unsigned Data link connection
7467 CID 5002 Unsigned sub-channel id
7470 SID/Noiselevel 5003 Unsigned silence insertion
7473 Primary Payload 5004 Unsigned Primary Payload Type
7474 type integer Covers FAX and codecs
7478 PropertyID Property tag Type Value
7480 IPv4 6001 32 bits Ipv4Address Ipv4Address
7483 IPv6 6002 128 bits IPv6 Address
7486 Port 6003 Unsigned integer 0..65535
7488 Porttype 6004 Enumerated TCP(0), UDP(1), SCTP(2)
7493 PropertyID Property Type Value
7496 AESA 7001 20 octets AAL2 service endpoint
7497 address as defined in
7501 Ref.: ITU-T Q.2630.1
7506 Groves, et al. Standards Track [Page 134]
7508 RFC 3525 Gateway Control Protocol June 2003
7511 BIR See C.3 4 octets Served user generated
7512 reference as defined in
7516 Ref.: ITU-T Q.2630.1
7518 ALC 7002 12 octets AAL2 link
7523 Maximum/Average CPS-SDU
7525 Maximum/Average CPS-SDU
7527 Ref.: ITU-T Q.2630.1
7529 SSCS 7003 I.366.2: Audio (8 Service specific
7530 octets); Multirate (3 convergence sublayer
7531 octets), or I.366.1: information as defined
7533 octets);SAR-unassured - ITU-T Q.2630.1,and
7534 (7 octets). used in:
7537 - ITU-T I.366.1: SAR-
7539 Ref.: ITU-T Q.2630.1,
7542 SUT 7004 1..254 octets Served user transport
7543 parameter as defined in
7546 Ref.: ITU-T Q.2630.1
7548 TCI 7005 Boolean Test connection
7549 indicator as defined in
7552 Ref.: ITU-T Q.2630.1
7554 Timer_CU 7006 32-bit integer Timer-CU
7555 Milliseconds to hold
7556 partially filled cell
7562 Groves, et al. Standards Track [Page 135]
7564 RFC 3525 Gateway Control Protocol June 2003
7567 MaxCPSSDU 7007 8-bit integer Maximum Common Part
7568 Sublayer Service Data
7570 Ref.: ITU-T Q.2630.1
7572 CID 7008 8 bits subchannel id: 0-255
7576 PropertyID Property Type Value
7579 BIR See table 4-29 octets GIT (Generic Identifier
7581 Ref.: ITU-T Q.2941.1
7583 AAL1ST 8001 1 octet AAL1 Subtype
7587 0 0 0 0 0 0 0 0 null
7588 0 0 0 0 0 0 0 1 voiceband
7589 signal transport on 64 kbit/s
7590 0 0 0 0 0 0 1 0 circuit
7592 0 0 0 0 0 1 0 0 high-quality
7593 audio signal transport
7594 0 0 0 0 0 1 0 1 video signal
7598 CBRR 8002 1 octet CBR Rate
7602 0 0 0 0 0 0 0 1 64 kbit/s
7603 0 0 0 0 0 1 0 0 1544 kbit/s
7604 0 0 0 0 0 1 0 1 6312 kbit/s
7605 0 0 0 0 0 1 1 0 32 064 kbit/s
7606 0 0 0 0 0 1 1 1 44 736 kbit/s
7607 0 0 0 0 1 0 0 0 97 728 kbit/s
7608 0 0 0 1 0 0 0 0 2048 kbit/s
7609 0 0 0 1 0 0 0 1 8448 kbit/s
7610 0 0 0 1 0 0 1 0 34 368 kbit/s
7611 0 0 0 1 0 0 1 1 139 264 kbit/s
7612 0 1 0 0 0 0 0 0 n x 64 kbit/s
7613 0 1 0 0 0 0 0 1 n x 8 kbit/s
7618 Groves, et al. Standards Track [Page 136]
7620 RFC 3525 Gateway Control Protocol June 2003
7623 MULT See table Multiplier, or n x 64k/8k/300
7624 in C.9 Ref.: ITU-T Q.2931
7626 SCRI 8003 1 octet Source Clock Frequency Recovery
7631 0 0 0 0 0 0 0 0 null
7632 0 0 0 0 0 0 0 1 SRTS
7636 ECM 8004 1 octet Error Correction Method
7640 0 0 0 0 0 0 0 0 null
7641 0 0 0 0 0 0 0 1 FEC - Loss
7642 0 0 0 0 0 0 1 0 FEC - Delay
7645 SDTB 8005 16-bit Structured Data Transfer
7647 Block size of SDT CBR service
7650 PFCI 8006 8-bit Partially filled cells identifier
7654 C.9 Bearer capabilities
7656 The table entries referencing Recommendation Q.931 refer to the
7657 encoding in the bearer capability information element of Q.931, not
7658 to the low layer information element.
7660 PropertyID Tag Type Value
7662 TMR 9001 1 octet Transmission Medium
7674 Groves, et al. Standards Track [Page 137]
7676 RFC 3525 Gateway Control Protocol June 2003
7679 00000011 3.1 kHz audio
7680 00000100 reserved for
7681 alternate speech (service
7682 2)/64 kbit/s unrestricted
7684 00000101 reserved for
7686 unrestricted (service
7687 1)/speech (service 2)
7688 00000110 64 kbit/s preferred
7690 The assigned codepoints
7691 listed below are all for
7692 unrestricted service.
7693 00000111 2 x 64 kbit/s
7695 00001001 1536 kbit/s
7696 00001010 1920 kbit/s
7703 3 x 64 kbit/s through
7714 TMRSR 9002 1 octet Transmission Medium
7721 Contcheck 9003 Boolean Continuity Check
7722 0 continuity check not
7723 required on this circuit
7725 required on this circuit
7730 Groves, et al. Standards Track [Page 138]
7732 RFC 3525 Gateway Control Protocol June 2003
7736 ITC 9004 5 bits Information Transfer
7742 0 1 0 0 0 Unrestricted
7744 0 1 0 0 1 Restricted
7746 1 0 0 0 0 3.1 kHz audio
7747 1 0 0 0 1 Unrestricted
7748 digital information with
7751 All other values are
7755 TransMode 9005 2 bits Transfer Mode
7763 TransRate 9006 5 bits Transfer Rate
7767 0 0 0 0 0 This code shall
7768 be used for packet mode calls
7770 1 0 0 0 1 2 x 64 kbit/s
7771 1 0 0 1 1 384 kbit/s
7772 1 0 1 0 1 1536 kbit/s
7773 1 0 1 1 1 1920 kbit/s
7774 1 1 0 0 0 Multirate (64
7778 MULT 9007 7 bits Rate Multiplier
7779 Any value from 2 to n
7780 (maximum number of B-
7786 Groves, et al. Standards Track [Page 139]
7788 RFC 3525 Gateway Control Protocol June 2003
7792 layer1prot 9008 5 bits User Information Layer 1
7798 standardized rate adaption
7800 0 0 0 1 0 Recommendation
7802 0 0 0 1 1 Recommendation
7804 0 0 1 0 0 Recommendation
7805 G.721 32 kbit/s ADPCM and
7806 Recommendation I.460
7807 0 0 1 0 1 Recommendations
7809 0 0 1 1 0 Recommendations
7812 standardized rate adaption.
7814 standardized rate adaption
7817 standardized rate adaption
7818 X.31 HDLC flag stuffing
7819 All other values are
7821 Ref.: ITU Recommendation
7824 syncasync 9009 Boolean Synchronous/Asynchronous
7829 negotiation 900A Boolean Negotiation
7830 0 In-band negotiation
7832 1 In-band negotiation not
7836 Userrate 900B 5 bits User Rate
7842 Groves, et al. Standards Track [Page 140]
7844 RFC 3525 Gateway Control Protocol June 2003
7849 indicated by E-bits specified
7850 in Recommendation I.460 or
7851 may be negotiated in-band
7852 0 0 0 0 1 0.6 kbit/s
7853 Recommendations V.6 and X.1
7854 0 0 0 1 0 1.2 kbit/s
7856 0 0 0 1 1 2.4 kbit/s
7857 Recommendations V.6 and X.1
7858 0 0 1 0 0 3.6 kbit/s
7860 0 0 1 0 1 4.8 kbit/s
7861 Recommendations V.6 and X.1
7862 0 0 1 1 0 7.2 kbit/s
7865 Recommendation I.460
7866 0 1 0 0 0 9.6 kbit/s
7867 Recommendations V.6 and X.1
7868 0 1 0 0 1 14.4 kbit/s
7871 Recommendation I.460
7872 0 1 0 1 1 19.2 kbit/s
7875 Recommendation I.460
7876 0 1 1 0 1 38.4 kbit/s
7877 Recommendation V.110
7879 Recommendations V.6 and X.1
7882 1 0 0 1 0 57.6 kbit/s
7883 Recommendation V.14 extended
7884 1 0 0 1 1 28.8 kbit/s
7885 Recommendation V.110
7887 Recommendation V.110
7888 1 0 1 0 1 0.1345 kbit/s
7890 1 0 1 1 0 0.100 kbit/s
7893 kbit/s Recommendations V.6
7898 Groves, et al. Standards Track [Page 141]
7900 RFC 3525 Gateway Control Protocol June 2003
7904 kbit/s Recommendations V.6
7906 1 1 0 0 1 0.050 kbit/s
7907 Recommendations V.6 and X.1
7908 1 1 0 1 0 0.075 kbit/s
7909 Recommendations V.6 and X.1
7910 1 1 0 1 1 0.110 kbit/s
7911 Recommendations V.6 and X.1
7912 1 1 1 0 0 0.150 kbit/s
7913 Recommendations V.6 and X.1
7914 1 1 1 0 1 0.200 kbit/s
7915 Recommendations V.6 and X.1
7916 1 1 1 1 0 0.300 kbit/s
7917 Recommendations V.6 and X.1
7920 All other values are
7923 INTRATE 900C 2 bits Intermediate Rate
7933 nictx 900D Boolean Network Independent Clock
7934 (NIC) on transmission
7935 0 Not required to send
7936 data with network independent
7938 1 Required to send data
7939 with network independent
7943 nicrx 900E Boolean Network independent clock
7945 0 Cannot accept data with
7946 network independent clock
7947 (i.e., sender does not support
7948 this optional procedure)
7949 1 Can accept data with
7950 network independent clock
7954 Groves, et al. Standards Track [Page 142]
7956 RFC 3525 Gateway Control Protocol June 2003
7959 (i.e., sender does support
7960 this optional procedure)
7963 flowconttx 900F Boolean Flow Control on transmission
7965 0 Not required to send
7966 data with flow control
7968 1 Required to send data
7969 with flow control mechanism
7972 flowcontrx 9010 Boolean Flow control on reception
7974 0 Cannot accept data with
7975 flow control mechanism (i.e.,
7976 sender does not support this
7978 1 Can accept data with
7979 flow control mechanism (i.e.,
7980 sender does support this
7984 rateadapthdr 9011 Boolean Rate adaption header/no
7986 0 Rate adaption header
7988 1 Rate adaption header
7992 multiframe 9012 Boolean Multiple frame establishment
7993 support in data link
7995 establishment not supported.
7996 Only UI frames allowed
7998 establishment supported
8001 OPMODE 9013 Boolean Mode of operation
8002 0 Bit transparent mode of
8004 1 Protocol sensitive mode
8010 Groves, et al. Standards Track [Page 143]
8012 RFC 3525 Gateway Control Protocol June 2003
8016 llidnegot 9014 Boolean Logical link identifier
8018 0 Default, LLI = 256 only
8023 assign 9015 Boolean Assignor/assignee
8024 0 Message originator is
8026 1 Message originator is
8030 inbandneg 9016 Boolean In-band/out-band negotiation
8031 0 Negotiation is done
8032 with USER INFORMATION
8033 messages on a temporary
8034 signalling connection
8035 1 Negotiation is done in-
8036 band using logical link zero
8039 stopbits 9017 2 bits Number of stop bits
8049 databits 9018 2 bits Number of data bits excluding
8050 parity bit if present
8060 parity 9019 3 bits Parity information
8066 Groves, et al. Standards Track [Page 144]
8068 RFC 3525 Gateway Control Protocol June 2003
8077 All other values are
8081 duplexmode 901A Boolean Mode duplex
8086 modem 901B 6 bits Modem Type
8091 0 0 0 1 0 1 National use
8092 0 1 0 0 0 1 Rec. V.21
8093 0 1 0 0 1 0 Rec. V.22
8094 0 1 0 0 1 1 Rec. V.22 bis
8095 0 1 0 1 0 0 Rec. V.23
8096 0 1 0 1 0 1 Rec. V.26
8097 0 1 1 0 0 1 Rec. V.26 bis
8098 0 1 0 1 1 1 Rec. V.26 ter
8099 0 1 1 0 0 0 Rec. V.27
8100 0 1 1 0 0 1 Rec. V.27 bis
8101 0 1 1 0 1 0 Rec. V.27 ter
8102 0 1 1 0 1 1 Rec. V.29
8103 0 1 1 1 0 1 Rec. V.32
8104 0 1 1 1 1 0 Rec. V.34
8106 1 0 1 1 1 1 National use
8108 1 1 1 1 1 1 User specified
8111 layer2prot 901C 5 bits User information layer 2
8116 0 0 0 1 0 Rec. Q.921/I.441
8117 0 0 1 1 0 Rec. X.25, link
8122 Groves, et al. Standards Track [Page 145]
8124 RFC 3525 Gateway Control Protocol June 2003
8127 0 1 1 0 0 LAN logical link
8128 control (ISO/IEC 8802 2)
8129 All other values are
8133 layer3prot 901D 5 bits User information layer 3
8138 0 0 0 1 0 ITU-T Q.931
8139 0 0 1 1 0 ITU-T X.25,
8141 0 1 0 1 1 ISO/IEC TR 9577
8142 (Protocol identification in
8144 All other values are
8148 addlayer3prot 901E Octet Additional User Information
8154 Internet Protocol (RFC 791)
8157 Point-to-point Protocol (RFC
8161 DialledN 901F 30 Dialled Number
8164 DiallingN 9020 30 Dialling Number
8167 ECHOCI 9021 Not Used. See H.248.1 E.13
8168 for an example of possible
8169 Echo Control properties.
8171 NCI 9022 1 octet Nature of Connection
8174 2 1 Satellite Indicator
8178 Groves, et al. Standards Track [Page 146]
8180 RFC 3525 Gateway Control Protocol June 2003
8184 0 0 no satellite circuit
8186 0 1 one satellite circuit
8189 circuits in the connection
8193 4 3 Continuity check
8195 0 0 continuity check not
8197 0 1 continuity check
8198 required on this circuit
8199 1 0 continuity check
8200 performed on a previous
8205 5 Echo control device
8207 0 outgoing echo control
8209 1 outgoing echo control
8216 USI 9023 Octet User Service Information
8217 string Ref.: ITU-T Q.763 Clause 3.57
8219 C.10 AAL5 properties
8221 PropertyID Property Type Value
8224 FMSDU A001 32-bit Forward Maximum CPCS-SDU Size:
8225 integer Maximum CPCS-SDU size sent in the
8226 direction from the calling user to
8234 Groves, et al. Standards Track [Page 147]
8236 RFC 3525 Gateway Control Protocol June 2003
8239 BMSDU A002 32-bit Backwards Maximum CPCS-SDU Size:
8240 integer Maximum CPCS-SDU size sent in the
8241 direction from the called user to
8245 SSCS See table See table See table in C.7
8246 in C.7 in C.7 Additional values:
8249 C.11 SDP equivalents
8251 PropertyID Property Type Value
8254 SDP_V B001 String Protocol Version
8257 SDP_O B002 String Owner/creator and session ID
8260 SDP_S B003 String Session name
8263 SDP_I B004 String Session identifier
8266 SDP_U B005 String URI of descriptor
8269 SDC_E B006 String email address
8272 SDP_P B007 String phone number
8275 SDP_C B008 String Connection information
8278 SDP_B B009 String Bandwidth Information
8281 SDP_Z B00A String Time zone adjustment
8284 SDP_K B00B String Encryption Key
8290 Groves, et al. Standards Track [Page 148]
8292 RFC 3525 Gateway Control Protocol June 2003
8295 SDP_A B00C String Zero or more session attributes
8298 SDP_T B00D String Active Session Time
8301 SDP_R B00E String Zero or more repeat times
8304 SDP_M B00F String Media type, port, transport and format
8309 PropertyID Property Type Value
8312 OLC C001 Octet The value of H.245
8313 OpenLogicalChannel structure.
8314 string Ref.: ITU-T H.245
8316 OLCack C002 Octet The value of H.245
8317 string OpenLogicalChannelAck structure.
8320 OLCcnf C003 Octet The value of H.245
8321 string OpenLogicalChannelConfirm structure.
8324 OLCrej C004 Octet The value of H.245
8325 string OpenLogicalChannelReject structure.
8328 CLC C005 Octet The value of H.245
8329 string CloseLogicalChannel structure.
8332 CLCack C006 Octet The value of H.245
8333 string CloseLogicalChannelAck structure.
8346 Groves, et al. Standards Track [Page 149]
8348 RFC 3525 Gateway Control Protocol June 2003
8351 ANNEX D - Transport over IP
8353 D.1 Transport over IP/UDP using Application Level Framing (ALF)
8355 Protocol messages defined in this RFC may be transmitted over UDP.
8356 When no port is provided by the peer (see 7.2.8), commands should be
8357 sent to the default port number: 2944 for text-encoded operation, or
8358 2945 for binary-encoded operation. Responses must be sent to the
8359 address and port from which the corresponding commands were sent.
8361 ALF is a set of techniques that allows an application, as opposed to
8362 a stack, to affect how messages are sent to the other side. A
8363 typical ALF technique is to allow an application to change the order
8364 of messages sent when there is a queue after it has queued them.
8365 There is no formal specification for ALF. The procedures in Annex
8366 D.1 contain a minimum suggested set of ALF behaviours
8368 Implementors using IP/UDP with ALF should be aware of the
8369 restrictions of the MTU on the maximum message size.
8371 D.1.1 Providing At-Most-Once functionality
8373 Messages, being carried over UDP, may be subject to losses. In the
8374 absence of a timely response, commands are repeated. Most commands
8375 are not idempotent. The state of the MG would become unpredictable
8376 if, for example, Add commands were executed several times. The
8377 transmission procedures shall thus provide an "At-Most-Once"
8380 Peer protocol entities are expected to keep in memory a list of the
8381 responses that they sent to recent transactions and a list of the
8382 transactions that are currently outstanding. The transaction
8383 identifier of each incoming message is compared to the transaction
8384 identifiers of the recent responses sent to the same MId. If a match
8385 is found, the entity does not execute the transaction, but simply
8386 repeats the response. If no match is found, the message will be
8387 compared to the list of currently outstanding transactions. If a
8388 match is found in that list, indicating a duplicate transaction, the
8389 entity does not execute the transaction (see D.1.4 for procedures on
8390 sending TransactionPending).
8392 The procedure uses a long timer value, noted LONG-TIMER in the
8393 following. The timer should be set larger than the maximum duration
8394 of a transaction, which should take into account the maximum number
8402 Groves, et al. Standards Track [Page 150]
8404 RFC 3525 Gateway Control Protocol June 2003
8407 of repetitions, the maximum value of the repetition timer and the
8408 maximum propagation delay of a packet in the network. A suggested
8409 value is 30 seconds.
8411 The copy of the responses may be destroyed either LONG-TIMER seconds
8412 after the response is issued, or when the entity receives a
8413 confirmation that the response has been received, through the
8414 "Response Acknowledgement parameter". For transactions that are
8415 acknowledged through this parameter, the entity shall keep a copy of
8416 the transaction-id for LONG-TIMER seconds after the response is
8417 issued, in order to detect and ignore duplicate copies of the
8418 transaction request that could be produced by the network.
8420 D.1.2 Transaction identifiers and three-way handshake
8422 D.1.2.1 Transaction identifiers
8424 Transaction identifiers are 32-bit integer numbers. A Media Gateway
8425 Controller may decide to use a specific number space for each of the
8426 MGs that they manage, or to use the same number space for all MGs
8427 that belong to some arbitrary group. MGCs may decide to share the
8428 load of managing a large MG between several independent processes.
8429 These processes will share the same transaction number space. There
8430 are multiple possible implementations of this sharing, such as having
8431 a centralized allocation of transaction identifiers, or
8432 pre-allocating non-overlapping ranges of identifiers to different
8433 processes. The implementations shall guarantee that unique
8434 transaction identifiers are allocated to all transactions that
8435 originate from a logical MGC (identical mId). MGs can simply detect
8436 duplicate transactions by looking at the transaction identifier and
8439 D.1.2.2 Three-way handshake
8441 The TransactionResponse Acknowledgement parameter can be found in any
8442 message. It carries a set of "confirmed transaction-id ranges".
8443 Entities may choose to delete the copies of the responses to
8444 transactions whose id is included in "confirmed transaction-id
8445 ranges" received in the transaction response messages. They should
8446 silently discard further commands when the transaction-id falls
8447 within these ranges.
8449 The "confirmed transaction-id ranges" values shall not be used if
8450 more than LONG-TIMER seconds have elapsed since the MG issued its
8451 last response to that MGC, or when a MG resumes operation. In this
8452 situation, transactions should be accepted and processed, without any
8453 test on the transaction-id.
8458 Groves, et al. Standards Track [Page 151]
8460 RFC 3525 Gateway Control Protocol June 2003
8463 Messages that carry the "Transaction Response Acknowledgement"
8464 parameter may be transmitted in any order. The entity shall retain
8465 the "confirmed transaction-id ranges" received for LONG-TIMER
8468 In the binary encoding, if only the firstAck is present in a response
8469 acknowledgement (see A.2), only one transaction is acknowledged. If
8470 both firstAck and lastAck are present, then the range of transactions
8471 from firstAck to lastAck is acknowledged. In the text encoding, a
8472 horizontal dash is used to indicate a range of transactions being
8473 acknowledged (see B.2).
8475 D.1.3 Computing retransmission timers
8477 It is the responsibility of the requesting entity to provide suitable
8478 timeouts for all outstanding transactions, and to retry transactions
8479 when timeouts have been exceeded. Furthermore, when repeated
8480 transactions fail to be acknowledged, it is the responsibility of the
8481 requesting entity to seek redundant services and/or clear existing or
8482 pending connections.
8484 The specification purposely avoids specifying any value for the
8485 retransmission timers. These values are typically network dependent.
8486 The retransmission timers should normally estimate the timer value by
8487 measuring the time spent between the sending of a command and the
8488 return of a response. Implementations SHALL ensure that the
8489 algorithm used to calculate retransmission timing performs an
8490 exponentially increasing backoff of the retransmission timeout for
8491 each retransmission or repetition after the first one.
8493 NOTE - One possibility is to use the algorithm implemented in
8494 TCP-IP, which uses two variables:
8496 - The average acknowledgement delay (AAD), estimated through an
8497 exponentially smoothed average of the observed delays.
8499 - The average deviation (ADEV), estimated through an exponentially
8500 smoothed average of the absolute value of the difference between
8501 the observed delay and the current average. The retransmission
8502 timer, in TCP, is set to the sum of the average delay plus N times
8503 the average deviation. The maximum value of the timer should
8504 however be bounded for the protocol defined in this
8505 RFC, in order to guarantee that no repeated packet
8506 would be received by the gateways after LONG-TIMER seconds. A
8507 suggested maximum value is 4 seconds.
8514 Groves, et al. Standards Track [Page 152]
8516 RFC 3525 Gateway Control Protocol June 2003
8519 After any retransmission, the entity SHOULD do the following:
8521 - It should double the estimated value of the average delay, AAD.
8523 - It should compute a random value, uniformly distributed between
8526 - It should set the retransmission timer to the sum of that random
8527 value and N times the average deviation.
8529 This procedure has two effects. Because it includes an exponentially
8530 increasing component, it will automatically slow down the stream of
8531 messages in case of congestion. Because it includes a random
8532 component, it will break the potential synchronization between
8533 notifications triggered by the same external event.
8535 D.1.4 Provisional responses
8537 Executing some transactions may require a long time. Long execution
8538 times may interact with the timer-based retransmission procedure.
8539 This may result either in an inordinate number of retransmissions, or
8540 in timer values that become too long to be efficient. Entities that
8541 can predict that a transaction will require a long execution time may
8542 send a provisional response, "Transaction Pending". They SHOULD send
8543 this response if they receive a repetition of a transaction that is
8544 still being executed.
8546 Entities that receive a Transaction Pending shall switch to a
8547 different repetition timer for repeating requests. The root
8548 Termination has a property (ProvisionalResponseTimerValue), which can
8549 be set to the requested maximum number of milliseconds between
8550 receipt of a command and transmission of the TransactionPending
8551 response. Upon receipt of a final response following receipt of
8552 provisional responses, an immediate confirmation shall be sent, and
8553 normal repetition timers shall be used thereafter. An entity that
8554 sends a provisional response, SHALL include the immAckRequired field
8555 in the ensuing final response, indicating that an immediate
8556 confirmation is expected. Receipt of a Transaction Pending after
8557 receipt of a reply shall be ignored.
8559 D.1.5 Repeating Requests, Responses and Acknowledgements
8561 The protocol is organized as a set of transactions, each of which is
8562 composed of a request and a response, commonly referred to as an
8563 acknowledgement. The protocol messages, being carried over UDP, may
8564 be subject to losses. In the absence of a timely response,
8565 transactions are repeated. Entities are expected to keep in memory a
8570 Groves, et al. Standards Track [Page 153]
8572 RFC 3525 Gateway Control Protocol June 2003
8575 list of the responses that they sent to recent transactions, i.e., a
8576 list of all the responses they sent over the last LONG-TIMER seconds,
8577 and a list of the transactions that are currently being executed.
8579 The repetition mechanism is used to guard against three types of
8582 - transmission errors, when for example a packet is lost due to
8583 noise on a line or congestion in a queue;
8585 - component failure, when for example an interface to a entity
8586 becomes unavailable;
8588 - entity failure, when for example an entire entity becomes
8591 The entities should be able to derive from the past history an
8592 estimate of the packet loss rate due to transmission errors. In a
8593 properly configured system, this loss rate should be kept very low,
8594 typically less than 1%. If a Media Gateway Controller or a Media
8595 Gateway has to repeat a message more than a few times, it is very
8596 legitimate to assume that something else than a transmission error is
8597 occurring. For example, given a loss rate of 1%, the probability
8598 that five consecutive transmission attempts fail is 1 in 100 billion,
8599 an event that should occur less than once every 10 days for a Media
8600 Gateway Controller that processes 1000 transactions per second.
8601 (Indeed, the number of repetition that is considered excessive should
8602 be a function of the prevailing packet loss rate.) We should note
8603 that the "suspicion threshold", which we will call "Max1", is
8604 normally lower than the "disconnection threshold", which should be
8605 set to a larger value.
8607 A classic retransmission algorithm would simply count the number of
8608 successive repetitions, and conclude that the association is broken
8609 after retransmitting the packet an excessive number of times
8610 (typically between 7 and 11 times.) In order to account for the
8611 possibility of an undetected or in progress "failover", we modify
8612 the classic algorithm so that if the Media Gateway receives a valid
8613 ServiceChange message announcing a failover, it will start
8614 transmitting outstanding commands to that new MGC. Responses to
8615 commands are still transmitted to the source address of the command.
8617 In order to automatically adapt to network load, this RFC specifies
8618 exponentially increasing timers. If the initial timer is set to 200
8619 milliseconds, the loss of a fifth retransmission will be detected
8620 after about 6 seconds. This is probably an acceptable waiting delay
8621 to detect a failover. The repetitions should continue after that
8622 delay not only in order to perhaps overcome a transient connectivity
8626 Groves, et al. Standards Track [Page 154]
8628 RFC 3525 Gateway Control Protocol June 2003
8631 problem, but also in order to allow some more time for the execution
8632 of a failover (waiting a total delay of 30 seconds is probably
8635 It is, however, important that the maximum delay of retransmissions
8636 be bounded. Prior to any retransmission, it is checked that the time
8637 elapsed since the sending of the initial datagram is no greater than
8638 T-MAX. If more than T-MAX time has elapsed, the MG concludes that
8639 the MGC has failed, and it begins its recovery process as described
8640 in section 11.5. If the MG retries to connect to the current MGC it
8641 shall use a ServiceChange with ServiceChangeMethod set to
8642 Disconnected so that the new MGC will be aware that the MG lost one
8643 or more transactions. The value T-MAX is related to the LONG-TIMER
8644 value: the LONG-TIMER value is obtained by adding to T MAX the
8645 maximum propagation delay in the network.
8649 Protocol messages as defined in this RFC may be transmitted over TCP.
8650 When no port is specified by the other side (see 7.2.8), the commands
8651 should be sent to the default port. The defined protocol has
8652 messages as the unit of transfer, while TCP is a stream-oriented
8653 protocol. TPKT, according to RFC 1006, SHALL be used to delineate
8654 messages within the TCP stream.
8656 In a transaction-oriented protocol, there are still ways for
8657 transaction requests or responses to be lost. As such, it is
8658 recommended that entities using TCP transport implement application
8659 level timers for each request and each response, similar to those
8660 specified for application level framing over UDP.
8662 D.2.1 Providing the At-Most-Once functionality
8664 Messages, being carried over TCP, are not subject to transport
8665 losses, but loss of a transaction request or its reply may
8666 nonetheless be noted in real implementations. In the absence of a
8667 timely response, commands are repeated. Most commands are not
8668 idempotent. The state of the MG would become unpredictable if, for
8669 example, Add commands were executed several times.
8671 To guard against such losses, it is recommended that entities follow
8672 the procedures in D.1.1.
8674 D.2.2 Transaction identifiers and three-way handshake
8676 For the same reasons, it is possible that transaction replies may be
8677 lost even with a reliable delivery protocol such as TCP. It is
8678 recommended that entities follow the procedures in D.1.2.2.
8682 Groves, et al. Standards Track [Page 155]
8684 RFC 3525 Gateway Control Protocol June 2003
8687 D.2.3 Computing retransmission timers
8689 With reliable delivery, the incidence of loss of a transaction
8690 request or reply is expected to be very low. Therefore, only simple
8691 timer mechanisms are required. Exponential back-off algorithms
8692 should not be necessary, although they could be employed where, as in
8693 an MGC, the code to do so is already required, since MGCs must
8694 implement ALF/UDP as well as TCP.
8696 D.2.4 Provisional responses
8698 As with UDP, executing some transactions may require a long time.
8699 Entities that can predict that a transaction will require a long
8700 execution time may send a provisional response, "Transaction
8701 Pending". They should send this response if they receive a
8702 repetition of a transaction that is still being executed.
8704 Entities that receive a Transaction Pending shall switch to a longer
8705 repetition timer for that transaction.
8707 Entities shall retain Transactions and replies until they are
8708 confirmed. The basic procedure of D.1.4 should be followed, but
8709 simple timer values should be sufficient. There is no need to send
8710 an immediate confirmation upon receipt of a final response.
8712 D.2.5 Ordering of commands
8714 TCP provides ordered delivery of transactions. No special procedures
8715 are required. It should be noted that ALF/UDP allows sending entity
8716 to modify its behaviour under congestion, and in particular, could
8717 reorder transactions when congestion is encountered. TCP could not
8718 achieve the same results.
8738 Groves, et al. Standards Track [Page 156]
8740 RFC 3525 Gateway Control Protocol June 2003
8743 ANNEX E - Basic packages
8745 This annex contains definitions of some packages for use with
8746 Recommendation H.248.1.
8750 PackageID: g (0x0001)
8755 Generic package for commonly encountered items.
8765 EventID: cause (0x0001)
8768 EventsDescriptor parameters: None
8770 ObservedEvents Descriptor Parameters:
8773 ParameterID: Generalcause (0x0001)
8775 This parameter groups the failures into six groups, which
8776 the MGC may act upon.
8781 "NR" Normal Release (0x0001)
8782 "UR" Unavailable Resources (0x0002)
8783 "FT" Failure, Temporary (0x0003)
8784 "FP" Failure, Permanent (0x0004)
8785 "IW" Interworking Error (0x0005)
8786 "UN" Unsupported (0x0006)
8789 ParameterID: Failurecause (0x0002)
8794 Groves, et al. Standards Track [Page 157]
8796 RFC 3525 Gateway Control Protocol June 2003
8799 Possible values: OCTET STRING
8801 Description: The Failure Cause is the value generated by the
8802 Released equipment, i.e., a released network connection.
8803 The concerned value is defined in the appropriate bearer
8808 EventID: sc (0x0002)
8810 Indicates the termination of a signal for which the
8811 notifyCompletion parameter was set to enable reporting of a
8812 completion event. For further procedural description, see 7.1.1,
8815 EventsDescriptor parameters: None
8817 ObservedEvents Descriptor parameters:
8820 ParameterID: SigID (0x0001)
8822 This parameter identifies the signal which has terminated.
8823 For a signal that is contained in a signal list, the signal
8824 list identity parameter should also be returned indicating
8825 the appropriate list.
8827 Type: Binary: octet (string), Text: string
8829 Possible values: a signal which has terminated. A signal
8830 shall be identified using the pkgdName syntax without
8834 ParameterID: Meth (0x0002)
8836 Indicates the means by which the signal terminated.
8841 "TO" (0x0001) Signal timed out or otherwise completed on
8843 "EV" (0x0002) Interrupted by event
8844 "SD" (0x0003) Halted by new Signals descriptor
8845 "NC" (0x0004) Not completed, other cause
8850 Groves, et al. Standards Track [Page 158]
8852 RFC 3525 Gateway Control Protocol June 2003
8856 ParameterID: SLID (0x0003)
8858 Indicates to which signal list a signal belongs. The
8859 SignalList ID is only returned in cases where the signal
8860 resides in a signal list.
8864 Possible values: any integer
8874 E.2 Base Root Package
8876 PackageID: root (0x0002)
8881 This package defines Gateway wide properties.
8886 PropertyID: maxNumberOfContexts (0x0001)
8888 The value of this property gives the maximum number of contexts
8889 that can exist at any time. The NULL context is not included in
8894 Possible values: 1 and up
8896 Defined in: TerminationState
8898 Characteristics: read only
8900 MaxTerminationsPerContext
8901 PropertyID: maxTerminationsPerContext (0x0002)
8906 Groves, et al. Standards Track [Page 159]
8908 RFC 3525 Gateway Control Protocol June 2003
8911 The maximum number of allowed terminations in a context, see 6.1
8915 Possible values: any integer
8917 Defined in: TerminationState
8919 Characteristics: read only
8921 normalMGExecutionTime
8922 PropertyId: normalMGExecutionTime (0x0003)
8924 Settable by the MGC to indicate the interval within which the MGC
8925 expects a response to any transaction from the MG (exclusive of
8930 Possible values: any integer, represents milliseconds
8932 Defined in: TerminationState
8934 Characteristics: read / write
8936 normalMGCExecutionTime
8937 PropertyId: normalMGCExecutionTime (0x0004)
8939 Settable by the MGC to indicate the interval within which the MG
8940 should expects a response to any transaction from the MGC
8941 (exclusive of network delay)
8945 Possible values: any integer, represents milliseconds
8947 Defined in: TerminationState
8949 Characteristics: read / write
8951 MGProvisionalResponseTimerValue
8952 PropertyId: MGProvisionalResponseTimerValue (0x0005)
8954 Indicates the time within which the MGC should expect a Pending
8955 Response from the MG if a Transaction cannot be completed.
8957 Initially set to normalMGExecutionTime plus network delay, but may
8962 Groves, et al. Standards Track [Page 160]
8964 RFC 3525 Gateway Control Protocol June 2003
8969 Possible Values: any integer, represents milliseconds
8971 Defined in: TerminationState
8973 Characteristics: read / write
8975 MGCProvisionalResponseTimerValue
8976 PropertyId: MGCProvisionalResponseTimerValue (0x0006)
8978 Indicates the time within which the MG should expect a Pending
8979 Response from the MGC if a Transaction cannot be completed.
8980 Initially set to normalMGCExecutionTime plus network delay, but
8985 Possible Values: any integer, represents milliseconds
8987 Defined in: TerminationState
8989 Characteristics: read / write
9007 E.3 Tone Generator Package
9009 PackageID: tonegen (0x0003)
9018 Groves, et al. Standards Track [Page 161]
9020 RFC 3525 Gateway Control Protocol June 2003
9025 This package defines signals to generate audio tones. This
9026 package does not specify parameter values. It is intended to be
9027 extendable. Generally, tones are defined as an individual signal
9028 with a parameter, ind, representing "interdigit" time delay, and a
9029 tone id to be used with playtones. A tone id should be kept
9030 consistent with any tone generation for the same tone. MGs are
9031 expected to be provisioned with the characteristics of appropriate
9032 tones for the country in which the MG is located.
9034 Designed to be extended only.
9047 SignalID: pt (0x0001)
9049 Plays audio tone over an audio channel
9053 Duration: Provisioned
9055 Additional parameters:
9058 ParameterID: tl (0x0001)
9060 Type: list of tone ids
9062 List of tones to be played in sequence. The list SHALL
9063 contain one or more tone ids.
9065 Inter signal duration
9066 ParameterID: ind (0x0002)
9070 Timeout between two consecutive tones in milliseconds
9074 Groves, et al. Standards Track [Page 162]
9076 RFC 3525 Gateway Control Protocol June 2003
9080 No tone ids are specified in this package. Packages that extend this
9081 package can add possible values for tone id as well as adding
9082 individual tone signals.
9092 E.4 Tone Detection Package
9094 PackageID: tonedet (0x0004)
9098 This Package defines events for audio tone detection. Tones are
9099 selected by name (tone id). MGs are expected to be provisioned with
9100 the characteristics of appropriate tones for the country in which the
9103 Designed to be extended only:
9104 This package does not specify parameter values. It is intended to
9114 EventID: std, 0x0001
9116 Detects the start of a tone. The characteristics of positive tone
9117 detection are implementation dependent.
9119 EventsDescriptor parameters:
9122 ParameterID: tl (0x0001)
9124 Type: list of tone ids
9130 Groves, et al. Standards Track [Page 163]
9132 RFC 3525 Gateway Control Protocol June 2003
9135 Possible values: The only tone id defined in this package is
9136 "wild card" which is "*" in text encoding and 0x0000 in
9137 binary. Extensions to this package would add possible
9138 values for tone id. If tl is "wild card", any tone id is
9141 ObservedEventsDescriptor parameters:
9144 ParameterID: tid (0x0003)
9148 Possible values: "wildcard" as defined above is the only
9149 value defined in this package. Extensions to this package
9150 would add additional possible values for tone id.
9153 EventID: etd, 0x0002
9155 Detects the end of a tone.
9157 EventDescriptor parameters:
9160 ParameterID: tl (0x0001)
9162 Type: enumeration or list of enumerated types
9164 Possible values: No possible values are specified in this
9165 package. Extensions to this package would add possible
9168 ObservedEventsDescriptor parameters:
9171 ParameterID: tid (0x0003)
9175 Possible values: "wildcard" as defined above is the only
9176 value defined in this package. Extensions to this
9177 package would add possible values for tone id.
9180 ParameterId: dur (0x0002)
9182 Type: integer, in milliseconds
9186 Groves, et al. Standards Track [Page 164]
9188 RFC 3525 Gateway Control Protocol June 2003
9192 This parameter contains the duration of the tone from
9193 first detection until it stopped.
9196 EventID: ltd, 0x0003
9198 Detects that a tone has been playing for at least a certain amount
9201 EventDescriptor parameters:
9204 ParameterID: tl (0x0001)
9206 Type: enumeration or list
9208 Possible values: "wildcard" as defined above is the only
9209 value defined in this package. Extensions to this package
9210 would add possible values for tone id.
9213 ParameterID: dur (0x0002)
9215 Type: integer, duration to test against
9217 Possible values: any legal integer, expressed in
9220 ObservedEventsDescriptor parameters:
9223 ParameterID: tid (0x0003)
9227 Possible values: No possible values are specified in this
9228 package. Extensions to this package would add possible
9242 Groves, et al. Standards Track [Page 165]
9244 RFC 3525 Gateway Control Protocol June 2003
9251 E.5 Basic DTMF Generator Package
9253 PackageID: dg (0x0005)
9255 Extends: tonegen version 1
9257 This package defines the basic DTMF tones as signals and extends the
9258 allowed values of parameter tl of playtone in tonegen.
9271 SignalID: d0 (0x0010)
9273 Generate DTMF 0 tone. The physical characteristic of DTMF 0 is
9274 defined in the gateway.
9278 Duration: Provisioned
9280 Additional parameters:
9286 d0 (0x0010) is defined as a tone id for playtone
9288 The other DTMF characters are specified in exactly the same way. A
9289 table with all signal names and signal IDs is included. Note that
9290 each DTMF character is defined as both a signal and a tone id, thus
9291 extending the basic tone generation package. Also note that DTMF
9292 SignalIds are different from the names used in a digit map.
9298 Groves, et al. Standards Track [Page 166]
9300 RFC 3525 Gateway Control Protocol June 2003
9303 Signal name Signal ID/Tone id
9305 DTMF character 0 d0 (0x0010)
9306 DTMF character 1 d1 (0x0011)
9307 DTMF character 2 d2 (0x0012)
9308 DTMF character 3 d3 (0x0013)
9309 DTMF character 4 d4 (0x0014)
9310 DTMF character 5 d5 (0x0015)
9311 DTMF character 6 d6 (0x0016)
9312 DTMF character 7 d7 (0x0017)
9313 DTMF character 8 d8 (0x0018)
9314 DTMF character 9 d9 (0x0019)
9315 DTMF character * ds (0x0020)
9316 DTMF character # do (0x0021)
9317 DTMF character A da (0x001a)
9318 DTMF character B db (0x001b)
9319 DTMF character C dc (0x001c)
9320 DTMF character D dd (0x001d)
9330 E.6 DTMF detection Package
9332 PackageID: dd (0x0006)
9334 Extends: tonedet version 1
9336 This package defines the basic DTMF tones detection. This Package
9337 extends the possible values of tone id in the "start tone detected"
9338 "end tone detected" and "long tone detected" events.
9340 Additional tone id values are all tone ids described in package dg
9341 (basic DTMF generator package).
9343 The following table maps DTMF events to digit map symbols as
9344 described in 7.1.14.
9354 Groves, et al. Standards Track [Page 167]
9356 RFC 3525 Gateway Control Protocol June 2003
9381 EventIds are defined with the same names as the SignalIds defined
9382 in the table found in E.5.3.
9384 DigitMap Completion Event
9387 Generated when a digit map completes as described in 7.1.14.
9389 EventsDescriptor parameters: None.
9391 ObservedEventsDescriptor parameters:
9394 ParameterID: ds (0x0001)
9396 Type: string of digit map symbols (possibly empty) returned
9399 Possible values: a sequence of the characters "0" through
9400 "9", "A" through "F", and the long duration modifier "Z".
9402 Description: the portion of the current dial string as
9403 described in 7.1.14 which matched part or all of an
9404 alternative event sequence specified in the digit map.
9410 Groves, et al. Standards Track [Page 168]
9412 RFC 3525 Gateway Control Protocol June 2003
9416 ParameterID: Meth (0x0003)
9422 "UM" (0x0001) Unambiguous match
9424 "PM" (0x0002) Partial match, completion by timer expiry
9427 "FM" (0x0003) Full match, completion by timer expiry or
9430 Description: indicates the reason for generation of the
9431 event. See the procedures in 7.1.14.
9443 Digit map processing is activated only if an events descriptor is
9444 activated that contains a digit map completion event as defined in
9445 Section E.6.2 and that digit map completion event contains an eventDM
9446 field in the requested actions as defined in Section 7.1.9. Other
9447 parameters such as KeepActive or embedded events of signals
9448 descriptors may also be present in the events descriptor and do not
9449 affect the activation of digit map processing.
9451 E.7 Call Progress Tones Generator Package
9453 PackageID: cg, 0x0007
9455 Extends: tonegen version 1
9457 This package defines the basic call progress tones as signals and
9458 extends the allowed values of the tl parameter of playtone in
9466 Groves, et al. Standards Track [Page 169]
9468 RFC 3525 Gateway Control Protocol June 2003
9482 SignalID: dt (0x0030)
9484 Generate dial tone. The physical characteristic of dial tone is
9485 available in the gateway.
9487 Signal Type: TimeOut
9489 Duration: Provisioned
9491 Additional parameters:
9497 dt (0x0030) is defined as a tone id for playtone
9499 The other tones of this package are defined in exactly the same way.
9500 A table with all signal names and signal IDs is included. Note that
9501 each tone is defined as both a signal and a tone id, thus extending
9502 the basic tone generation package.
9504 Signal Name Signal ID/tone id
9506 Dial Tone dt (0x0030)
9507 Ringing Tone rt (0x0031)
9508 Busy Tone bt (0x0032)
9509 Congestion Tone ct (0x0033)
9510 Special Information Tone sit(0x0034)
9511 Warning Tone wt (0x0035)
9512 Payphone Recognition Tone prt (0x0036)
9513 Call Waiting Tone cw (0x0037)
9514 Caller Waiting Tone cr (0x0038)
9522 Groves, et al. Standards Track [Page 170]
9524 RFC 3525 Gateway Control Protocol June 2003
9529 NOTE - The required set of tone ids corresponds to those defined
9530 in Recommendation E.180/Q.35. See Recommendation E.180/Q.35 for
9531 definition of the meanings of these tones.
9534 E.8 Call Progress Tones Detection Package
9536 PackageID: cd (0x0008)
9538 Extends: tonedet version 1
9540 This package defines the basic call progress detection tones. This
9541 package extends the possible values of tone id in the "start tone
9542 detected", "end tone detected" and "long tone detected" events.
9546 toneID values are defined for start tone detected, end tone
9547 detected and long tone detected with the same values as those in
9548 package cg (call progress tones generation package).
9550 The required set of tone ids corresponds to Recommendation
9551 E.180/Q.35. See Recommendation E.180/Q.35 for definition of the
9552 meanings of these tones.
9560 Events are defined as in the call progress tones generator package
9561 (cg) for the tones listed in the table of E.7.3.
9578 Groves, et al. Standards Track [Page 171]
9580 RFC 3525 Gateway Control Protocol June 2003
9583 E.9 Analog Line Supervision Package
9585 PackageID: al, 0x0009
9589 This package defines events and signals for an analog line.
9598 EventID: on (0x0004)
9600 Detects handset going on hook. Whenever an events descriptor is
9601 activated that requests monitoring for an on-hook event and the
9602 line is already on-hook, then the MG shall behave according to the
9603 setting of the "strict" parameter.
9605 EventDescriptor parameters:
9608 ParameterID: strict (0x0001)
9612 Possible values: "exact" (0x00), "state" (0x01), "failWrong"
9615 "exact" means that only an actual hook state transition to
9616 on-hook is to be recognized;
9618 "state" means that the event is to be recognized either if
9619 the hook state transition is detected or if the hook state
9622 "failWrong" means that if the hook state is already
9623 on-hook, the command fails and an error is reported.
9625 ObservedEventsDescriptor parameters:
9628 ParameterID: init (0x0002)
9634 Groves, et al. Standards Track [Page 172]
9636 RFC 3525 Gateway Control Protocol June 2003
9641 "True" means that the event was reported because the line
9642 was already on-hook when the events descriptor containing
9643 this event was activated;
9645 "False" means that the event represents an actual state
9646 transition to on-hook.
9649 EventID: of (0x0005)
9651 Detects handset going off hook. Whenever an events descriptor is
9652 activated that requests monitoring for an off-hook event and the
9653 line is already off-hook, then the MG shall behave according to
9654 the setting of the "strict" parameter.
9656 EventDescriptor parameters:
9659 ParameterID: strict (0x0001)
9663 Possible values: "exact" (0x00), "state" (0x01), "failWrong"
9666 "exact" means that only an actual hook state transition
9667 to off-hook is to be recognized;
9669 "state" means that the event is to be recognized either
9670 if the hook state transition is detected or if the hook
9671 state is already off-hook;
9673 "failWrong" means that if the hook state is already off-
9674 hook, the command fails and an error is reported.
9676 ObservedEventsDescriptor parameters
9679 ParameterID: init (0x0002)
9690 Groves, et al. Standards Track [Page 173]
9692 RFC 3525 Gateway Control Protocol June 2003
9697 "True" means that the event was reported because the line
9698 was already off-hook when the events descriptor
9699 containing this event was activated;
9701 "False" means that the event represents an actual state
9702 transition to off-hook.
9707 Detects handset flash. A flash occurs when an onhook is followed
9708 by an offhook between a minimum and maximum duration.
9710 EventDescriptor parameters:
9713 ParameterID: mindur (0x0004)
9715 Type: integer in milliseconds
9717 Default value is provisioned.
9720 ParameterID: maxdur (0x0005)
9722 Type: integer in milliseconds
9724 Default value is provisioned.
9726 ObservedEventsDescriptor parameters:
9733 SignalID: ri, 0x0002
9735 Applies ringing on the line
9737 Signal Type: TimeOut
9739 Duration: Provisioned
9746 Groves, et al. Standards Track [Page 174]
9748 RFC 3525 Gateway Control Protocol June 2003
9751 Additional parameters:
9754 ParameterID: cad (0x0006)
9756 Type: list of integers representing durations of alternating
9757 on and off segments, constituting a complete ringing cycle
9758 starting with an on. Units in milliseconds
9760 Default is fixed or provisioned. Restricted function MGs
9761 may ignore cadence values they are incapable of generating.
9764 ParameterID: freq (0x0007)
9768 Default is fixed or provisioned. Restricted function MGs
9769 may ignore frequency values they are incapable of
9778 If the MGC sets an EventsDescriptor containing a hook state
9779 transition event (on-hook or off-hook) with the "strict" (0x0001)
9780 parameter set to "failWrong", and the hook state is already what the
9781 transition implies, the execution of the command containing that
9782 EventsDescriptor fails. The MG SHALL include error code 540
9783 "Unexpected initial hook state" in its reponse.
9787 This package defines a new error code:
9789 540 - Unexpected initial hook state
9791 The procedure for use of this code is given in E.9.5.
9793 E.10 Basic Continuity Package
9795 PackageID: ct (0x000a)
9802 Groves, et al. Standards Track [Page 175]
9804 RFC 3525 Gateway Control Protocol June 2003
9807 This package defines events and signals for continuity test. The
9808 continuity test includes provision of either a loopback or
9809 transceiver functionality.
9818 EventID: cmp, 0x0005
9820 This event detects test completion of continuity test.
9822 EventDescriptor parameters
9826 ObservedEventsDescriptor parameters
9829 ParameterID: res (0x0008)
9833 Possible values: success (0x0001), failure (0x0000)
9838 SignalID: ct (0x0003)
9840 Initiates sending of continuity test tone on the termination to
9841 which it is applied.
9843 Signal Type: TimeOut
9845 Default value is provisioned
9847 Additional parameters:
9852 SignalID: rsp (0x0004)
9858 Groves, et al. Standards Track [Page 176]
9860 RFC 3525 Gateway Control Protocol June 2003
9863 The signal is used to respond to a continuity test. See E.10.5
9864 for further explanation.
9868 Default duration is provisioned
9870 Additional parameters:
9880 When a MGC wants to initiate a continuity test, it sends a command to
9883 - a signals descriptor with the ct signal; and
9885 - an events descriptor containing the cmp event.
9887 Upon reception of a command containing the ct signal and cmp event,
9888 the MG initiates the continuity test tone for the specified
9889 Termination. If the return tone is detected and any other required
9890 conditions are satisfied before the signal times out, the cmp event
9891 shall be generated with the value of the result parameter equal to
9892 success. In all other cases, the cmp event shall be generated with
9893 the value of the result parameter equal to failure.
9895 When a MGC wants the MG to respond to a continuity test, it sends a
9896 command to the MG containing a signals descriptor with the rsp
9897 signal. Upon reception of a command with the rsp signal, the MG
9898 either applies a loopback or (for 2-wire circuits) awaits reception
9899 of a continuity test tone. In the loopback case, any incoming
9900 information shall be reflected back as outgoing information. In the
9901 2-wire case, any time the appropriate test tone is received, the
9902 appropriate response tone should be sent. The MGC determines when to
9903 remove the rsp signal.
9905 When a continuity test is performed on a Termination, no echo devices
9906 or codecs shall be active on that Termination.
9908 Performing voice path assurance as part of continuity testing is
9909 provisioned by bilateral agreement between network operators.
9914 Groves, et al. Standards Track [Page 177]
9916 RFC 3525 Gateway Control Protocol June 2003
9919 (Informative Note) Example tones and test procedure details are
9920 given in Q.724 sections 7 and 8, Q.764 section 2.1.8 and Q.1902.4.
9922 E.11 Network Package
9924 PackageID: nt (0x000b)
9928 This package defines properties of network terminations independent
9933 Maximum Jitter Buffer
9934 PropertyID: jit (0x0007)
9936 This property puts a maximum size on the jitter buffer.
9938 Type: integer in milliseconds
9940 Possible values: This property is specified in milliseconds.
9942 Defined in: LocalControlDescriptor
9944 Characteristics: read/write
9949 EventID: netfail, 0x0005
9951 The termination generates this event upon detection of a failure
9952 due to external or internal network reasons.
9954 EventDescriptor parameters
9958 ObservedEventsDescriptor parameters
9961 ParameterID: cs (0x0001)
9965 Possible values: any text string
9970 Groves, et al. Standards Track [Page 178]
9972 RFC 3525 Gateway Control Protocol June 2003
9975 This parameter may be included with the failure event to
9976 provide diagnostic information on the reason of failure.
9979 EventID: qualert, 0x0006
9981 This property allows the MG to indicate a loss of quality of the
9982 network connection. The MG may do this by measuring packet loss,
9983 interarrival jitter, propagation delay and then indicating this
9984 using a percentage of quality loss.
9986 EventDescriptor parameters
9989 ParameterId: th (0x0001)
9993 Possible values: 0 to 99
9995 Description: threshold for percent of quality loss measured,
9996 calculated based on a provisioned method, that could take
9997 into consideration packet loss, jitter, and delay for
9998 example. Event is triggered when calculation exceeds the
10001 ObservedEventsDescriptor parameters
10004 ParameterId: th (0x0001)
10008 Possible values: 0 to 99
10010 Description: percent of quality loss measured, calculated
10011 based on a provisioned method, that could take into
10012 consideration packet loss, jitter, and delay for example.
10026 Groves, et al. Standards Track [Page 179]
10028 RFC 3525 Gateway Control Protocol June 2003
10034 StatisticsID: dur (0x0001)
10036 Description: provides duration of time the termination has been in
10039 Type: double, in milliseconds
10042 StatisticID: os (0x0002)
10046 Possible values: any 64-bit integer
10049 StatisticID: or (0x0003)
10053 Possible values: any 64-bit integer
10061 PackageID: rtp (0x000c)
10063 Extends: Network Package version 1
10065 This package is used to support packet-based multimedia data transfer
10066 by means of the Real-time Transport Protocol (RTP) [RFC 1889].
10075 EventID: pltrans, 0x0001
10077 This event detects and notifies when there is a transition of the
10078 RTP payload format from one format to another.
10082 Groves, et al. Standards Track [Page 180]
10084 RFC 3525 Gateway Control Protocol June 2003
10087 EventDescriptor parameters
10091 ObservedEventsDescriptor parameters
10093 ParameterName: rtppayload
10094 ParameterID: rtppltype, 0x01
10096 Type: list of enumerated types.
10098 Possible values: The encoding method shall be specified by
10099 using one or several valid encoding names, as defined in the
10100 RTP AV Profile or registered with IANA.
10109 StatisticID: ps (0x0004)
10113 Possible values: any 64-bit integer
10116 StatisticID: pr (0x0005)
10120 Possible values: any 64-bit integer
10123 StatisticID: pl (0x0006)
10125 Describes the current rate of packet loss on an RTP stream, as
10126 defined in IETF RFC 1889. Packet loss is expressed as percentage
10127 value: number of packets lost in the interval between two
10128 reception reports, divided by the number of packets expected
10129 during that interval.
10133 Possible values: a 32-bit whole number and a 32-bit fraction.
10138 Groves, et al. Standards Track [Page 181]
10140 RFC 3525 Gateway Control Protocol June 2003
10144 StatisticID: jit (0x0007)
10146 Requests the current value of the interarrival jitter on an RTP
10147 stream as defined in IETF RFC 1889. Jitter measures the variation
10148 in interarrival time for RTP data packets.
10151 StatisticID:delay (0x0008)
10153 Requests the current value of packet propagation delay expressed
10154 in timestamp units. Same as average latency.
10160 E.13 TDM Circuit Package
10162 PackageID: tdmc (0x000d)
10164 Extends: Network Package version 1
10166 This package may be used by any termination that supports gain and
10167 echo control. It was originally intended for use on TDM circuits
10168 but may be more widely used.
10171 New versions or extensions of this package should take non-TDM use
10177 PropertyID: ec (0x0008)
10183 "on" (when the echo cancellation is requested) and
10185 "off" (when it is turned off.)
10187 The default is provisioned.
10189 Defined in: LocalControlDescriptor
10194 Groves, et al. Standards Track [Page 182]
10196 RFC 3525 Gateway Control Protocol June 2003
10199 Characteristics: read/write
10202 PropertyID: gain (0x000a)
10204 Gain control, or usage of of signal level adaptation and
10205 noise level reduction is used to adapt the level of the signal.
10206 However, it is necessary, for example for modem calls, to turn
10213 The gain control parameter may either be specified as
10214 "automatic" (0xffffffff), or as an explicit number of decibels
10215 of gain (any other integer value). The default is provisioned
10218 Defined in: LocalControlDescriptor
10220 Characteristics: read/write
10250 Groves, et al. Standards Track [Page 183]
10252 RFC 3525 Gateway Control Protocol June 2003
10255 APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE)
10257 All H.248.1 implementors must read the normative part of this RFC
10258 carefully before implementing from it. The examples in this appendix
10259 should not be used as stand-alone explanations of how to create
10262 The examples in this appendix use SDP for encoding of the Local and
10263 and Remote stream descriptors. SDP is defined in RFC 2327. If there
10264 is is any discrepancy between the SDP in the examples, and RFC 2327,
10265 the the RFC should be consulted for correctness. Audio profiles used
10266 are are those defined in IETF RFC 1890, and others registered with
10267 IANA. For example, G.711 A-law is called PCMA in SDP, and is
10268 assigned profile 0. G.723.1 is called G723 and is profile 4; H.263 is
10269 called H263 and is profile 34. See also
10270 http://www.iana.org/assignments/rtp-parameters.
10272 A.1 Residential Gateway to Residential Gateway Call
10274 This example scenario illustrates the use of the elements of the
10275 protocol to set up a Residential Gateway to Residential Gateway call
10276 over an IP-based network. For simplicity, this example assumes that
10277 both Residential Gateways involved in the call are controlled by the
10278 same Media Gateway Controller.
10280 A.1.1 Programming Residential GW Analog Line Terminations for Idle
10283 The following illustrates the API invocations from the Media Gateway
10284 Controller and Media Gateways to get the Terminations in this
10285 scenario programmed for idle behavior. Both the originating and
10286 terminating Media Gateways have idle AnalogLine Terminations
10287 programmed to look for call initiation events (i.e., -offhook) by
10288 using the Modify Command with the appropriate parameters. The null
10289 Context is used to indicate that the Terminations are not yet
10290 involved in a Context. The ROOT termination is used to indicate the
10291 entire MG instead of a termination within the MG.
10293 In this example, MG1 has the IP address 124.124.124.222, MG2 is
10294 125.125.125.111, and the MGC is 123.123.123.4. The default Megaco
10295 port is 55555 for all three.
10297 1. An MG registers with an MGC using the ServiceChange command:
10301 MEGACO/1 [124.124.124.222] Transaction = 9998 {
10306 Groves, et al. Standards Track [Page 184]
10308 RFC 3525 Gateway Control Protocol June 2003
10311 ServiceChange = ROOT {Services {
10313 ServiceChangeAddress=55555, Profile=ResGW/1}
10317 2. The MGC sends a reply:
10321 MEGACO/1 [123.123.123.4]:55555 Reply = 9998 {
10322 Context = - {ServiceChange = ROOT {
10323 Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } }
10325 3. The MGC programs a Termination in the NULL context. The
10326 terminationId is A4444, the streamId is 1, the requestId in the
10327 Events descriptor is 2222. The mId is the identifier of the sender
10328 of this message, in this case, it is the IP address and port
10329 [123.123.123.4]:55555. Mode for this stream is set to SendReceive.
10330 "al" is the analog line supervision package. Local and Remote are
10331 assumed to be provisioned.
10335 MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 {
10338 Media { Stream = 1 {
10340 Mode = SendReceive,
10341 tdmc/gain=2, ; in dB,
10347 Events = 2222 {al/of(strict=state)}
10352 The dialplan script could have been loaded into the MG previously.
10353 Its function would be to wait for the OffHook, turn on dialtone and
10354 start collecting DTMF digits. However in this example, we use the
10355 digit map, which is put into place after the offhook is detected
10362 Groves, et al. Standards Track [Page 185]
10364 RFC 3525 Gateway Control Protocol June 2003
10367 Note that the embedded EventsDescriptor could have been used to
10368 combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
10370 4. The MG1 accepts the Modify with this reply:
10374 MEGACO/1 [124.124.124.222]:55555
10377 Context = - {Modify = A4444} }
10379 5. A similar exchange happens between MG2 and the MGC, resulting in
10380 an idle Termination called A5555.
10382 A.1.2 Collecting Originator Digits and Initiating Termination
10384 The following builds upon the previously shown conditions. It
10385 illustrates the transactions from the Media Gateway Controller and
10386 originating Media Gateway (MG1) to get the originating Termination
10387 (A4444) through the stages of digit collection required to initiate a
10388 connection to the terminating Media Gateway (MG2).
10390 6. MG1 detects an offhook event from User 1 and reports it to the
10391 Media Gateway Controller via the Notify Command.
10395 MEGACO/1 [124.124.124.222]:55555 Transaction = 10000 {
10397 Notify = A4444 {ObservedEvents =2222 {
10398 19990729T22000000:al/of(init=false)}}
10401 7. And the Notify is acknowledged.
10405 MEGACO/1 [123.123.123.4]:55555 Reply = 10000 {
10407 Context = - {Notify = A4444} }
10418 Groves, et al. Standards Track [Page 186]
10420 RFC 3525 Gateway Control Protocol June 2003
10423 8. The MGC Modifies the termination to play dial tone, to look for
10424 digits according to Dialplan0 and to look for the on-hook event now.
10428 MEGACO/1 [123.123.123.4]:55555 Transaction = 10001 {
10432 al/on(strict=state), dd/ce {DigitMap=Dialplan0}
10435 DigitMap= Dialplan0{ (0| 00|[1-
10436 7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
10440 9. And the Modify is acknowledged.
10444 MEGACO/1 [124.124.124.222]:55555 Reply = 10001 {
10445 Context = - {Modify = A4444} }
10447 10. Next, digits are accumulated by MG1 as they are dialed by User
10448 1. Dialtone is stopped upon detection of the first digit. When an
10449 appropriate match is made of collected digits against the currently
10450 programmed Dialplan for A4444, another Notify is sent to the Media
10451 Gateway Controller.
10455 MEGACO/1 [124.124.124.222]:55555 Transaction = 10002 {
10457 Notify = A4444 {ObservedEvents =2223 {
10458 19990729T22010001:dd/ce{ds="916135551212",Meth=UM}}}
10461 11. And the Notify is acknowledged.
10465 MEGACO/1 [123.123.123.4]:55555 Reply = 10002 {
10466 Context = - {Notify = A4444} }
10469 12. The controller then analyses the digits and determines that a
10470 connection needs to be made from MG1 to MG2. Both the TDM
10474 Groves, et al. Standards Track [Page 187]
10476 RFC 3525 Gateway Control Protocol June 2003
10479 termination A4444, and an RTP termination are added to a new context
10480 in MG1. Mode is ReceiveOnly since Remote descriptor values are not
10481 yet specified. Preferred codecs are in the MGC's preferred order of
10486 MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 {
10493 Mode = ReceiveOnly,
10497 Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4
10498 a=ptime:30 v=0 c=IN IP4 $ m=audio $ RTP/AVP 0
10506 NOTE - The MGC states its preferred parameter values as a series
10507 of SDP blocks in Local. The MG fills in the Local Descriptor in
10510 13. MG1 acknowledges the new Termination and fills in the Local IP
10511 address and UDP port. It also makes a choice for the codec based on
10512 the MGC preferences in Local. MG1 sets the RTP port to 2222.
10516 MEGACO/1 [124.124.124.222]:55555 Reply = 10003 {
10522 Local { v=0 o=- 2890844526 2890842807 IN IP4
10523 124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
10524 RTP/AVP 4 a=ptime:30 a=recvonly
10525 } ; RTP profile for G.723.1 is 4
10530 Groves, et al. Standards Track [Page 188]
10532 RFC 3525 Gateway Control Protocol June 2003
10539 14. The MGC will now associate A5555 with a new Context on MG2, and
10540 establish an RTP Stream (i.e., A5556 will be assigned), SendReceive
10541 connection through to the originating user, User 1. The MGC also
10542 sets ring on A5555.
10546 MEGACO/1 [123.123.123.4]:55555 Transaction = 50003 {
10548 Add = A5555 { Media {
10550 LocalControl {Mode = SendReceive} }},
10551 Events=1234{al/of(strict=state)},
10558 Mode = SendReceive,
10561 Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4
10564 Remote { v=0 c=IN IP4 124.124.124.222 m=audio 2222
10565 RTP/AVP 4 a=ptime:30
10566 } ; RTP profile for G.723.1 is 4
10572 15. This is acknowledged. The stream port number is different from
10573 the control port number. In this case it is 1111 (in the SDP).
10577 MEGACO/1 [125.125.125.111]:55555 Reply = 50003 {
10586 Groves, et al. Standards Track [Page 189]
10588 RFC 3525 Gateway Control Protocol June 2003
10591 Local { v=0 o=- 7736844526 7736842807 IN IP4
10592 125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
10594 } ; RTP profile for G723.1 is 4
10600 16. The above IPAddr and UDPport need to be given to MG1 now.
10604 MEGACO/1 [123.123.123.4]:55555 Transaction = 10005 {
10612 Remote { v=0 o=- 7736844526 7736842807 IN IP4
10613 125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
10616 } ; RTP profile for G723.1 is 4
10624 MEGACO/1 [124.124.124.222]:55555 Reply = 10005 {
10625 Context = 2000 {Modify = A4444, Modify = A4445} }
10627 17. The two gateways are now connected and User 1 hears the
10628 RingBack. The MG2 now waits until User2 picks up the receiver and
10629 then the two-way call is established.
10642 Groves, et al. Standards Track [Page 190]
10644 RFC 3525 Gateway Control Protocol June 2003
10649 MEGACO/1 [125.125.125.111]:55555 Transaction = 50005 {
10652 Notify = A5555 {ObservedEvents =1234 {
10653 19990729T22020002:al/of(init=false)}}
10658 MEGACO/1 [123.123.123.4]:55555 Reply = 50005 {
10659 Context = - {Notify = A5555} }
10663 MEGACO/1 [123.123.123.4]:55555 Transaction = 50006 {
10666 Events = 1235 {al/on(strict=state)},
10667 Signals { } ; to turn off ringing
10673 MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
10674 Context = 5000 {Modify = A4445} }
10676 18. Change mode on MG1 to SendReceive, and stop the ringback.
10680 MEGACO/1 [123.123.123.4]:55555 Transaction = 10006 {
10698 Groves, et al. Standards Track [Page 191]
10700 RFC 3525 Gateway Control Protocol June 2003
10707 MEGACO/1 [124.124.124.222]:55555 Reply = 10006 {
10708 Context = 2000 {Modify = A4445, Modify = A4444}}
10710 19. The MGC decides to Audit the RTP termination on MG2.
10714 MEGACO/1 [123.123.123.4]:55555 Transaction = 50007 {
10715 Context = - {AuditValue = A5556{
10716 Audit{Media, DigitMap, Events, Signals, Packages, Statistics }}
10719 20. The MG2 replies.
10723 MEGACO/1 [125.125.125.111]:55555 Reply = 50007 {
10724 Context = - { AuditValue = A5556 {
10726 TerminationState { ServiceStates = InService,
10729 LocalControl { Mode = SendReceive,
10731 Local { v=0 o=- 7736844526 7736842807 IN IP4
10732 125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
10733 RTP/AVP 4 a=ptime:30
10735 Remote { v=0 o=- 2890844526 2890842807 IN IP4
10736 124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
10737 RTP/AVP 4 a=ptime:30
10742 Packages {nt-1, rtp-1},
10743 Statistics { rtp/ps=1200, ; packets sent
10744 nt/os=62300, ; octets sent
10745 rtp/pr=700, ; packets received
10746 nt/or=45100, ; octets received
10747 rtp/pl=0.2, ; % packet loss
10749 rtp/delay=40 } ; avg latency
10754 Groves, et al. Standards Track [Page 192]
10756 RFC 3525 Gateway Control Protocol June 2003
10761 21. When the MGC receives an onhook signal from one of the MGs, it
10762 brings down the call. In this example, the user at MG2 hangs up
10767 MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 {
10769 Notify = A5555 {ObservedEvents =1235 {
10770 19990729T24020002:al/on(init=false)}
10776 MEGACO/1 [123.123.123.4]:55555 Reply = 50008 {
10778 Context = - {Notify = A5555} }
10780 22. The MGC now sends both MGs a Subtract to take down the call.
10781 Only the subtracts to MG2 are shown here. Each termination has its
10782 own set of statistics that it gathers. An MGC may not need to
10783 request both to be returned. A5555 is a physical termination, and
10784 A5556 is an RTP termination.
10788 MEGACO/1 [123.123.123.4]:55555 Transaction = 50009 {
10790 Subtract = A5555 {Audit{Statistics}},
10791 Subtract = A5556 {Audit{Statistics}}
10796 MEGACO/1 [125.125.125.111]:55555 Reply = 50009 {
10800 nt/os=45123, ; Octets Sent
10801 nt/dur=40 ; in seconds
10806 rtp/ps=1245, ; packets sent
10810 Groves, et al. Standards Track [Page 193]
10812 RFC 3525 Gateway Control Protocol June 2003
10815 nt/os=62345, ; octets sent
10816 rtp/pr=780, ; packets received
10817 nt/or=45123, ; octets received
10818 rtp/pl=10, ; % packets lost
10820 rtp/delay=48 ; average latency
10825 23. The MGC now sets up both MG1 and MG2 to be ready to detect the
10826 next off-hook event. See step 1. Note that this could be the
10827 default state of a termination in the null context, and if this were
10828 the case, no message need be sent from the MGC to the MG. Once a
10829 termination returns to the null context, it goes back to the default
10830 termination values for that termination.
10866 Groves, et al. Standards Track [Page 194]
10868 RFC 3525 Gateway Control Protocol June 2003
10871 APPENDIX II Changes From RFC 3015
10873 In the following table, "source" indicates when the change was first
10874 approved. It has the following values:
10876 IG1100: H.248 Implementor's Guide approved in November, 2000 (as TD
10877 Plen-39, Christian Groves, editor).
10879 IG0601: H.248 Implementor's Guide approved in June, 2001 (as TD
10880 Plen-15, Christian Groves, editor).
10882 IGDUB: Draft H.248 Implementor's Guide approved at the Q.3
10883 Rapporteur's meeting held near Dublin, October 2001 (as TD-28, Terry
10886 GEN0202: added at the Geneva meeting, February 2002, which consented
10887 to H.248 v1 Amendment 1 (as TD Plen-36r1, Marcello Pantaleo, editor).
10889 ITUPOST: added in post-Geneva editing by the ITU-T.
10891 TTPOST: added in post-approval editing by the Megaco Chair, Tom
10892 Taylor, who assembled this document for submission.
10894 Section Source Change
10896 1 ITUPOST Reference changed from H.248 to H.248.1.
10898 2.1 ITUPOST Reference added for error codes, changed from
10899 H.248 Annex L to H.248.8 (2002).
10901 2.1 IG1100 Corrected Q.765 reference to Q.765.5.
10903 2.1 GEN0202 Added reference to X.690.
10905 2.2 GEN0202 Added reference to H.226.
10907 2.2 IGDUB Added informative references to Q.724, Q.764,
10910 4 IG0601 Added expansion of ALF.
10912 5 TTPOST Gave priority to IETF conventions (added at
10913 start of document).
10922 Groves, et al. Standards Track [Page 195]
10924 RFC 3525 Gateway Control Protocol June 2003
10927 6.1.1 IG0601 Added text regarding use of wildcards for
10928 context identifiers. (This information
10929 already appeared in section 8.1.2. The IG
10930 change subsequently disappeared.)
10932 6.1.1 IG1100 Added ranking of priority values.
10934 6.2 IGDUB Deleted definition of signals.
10936 6.2 GEN0202 Expanded text and diagrams describing
10937 multiplexing terminations.
10939 6.2 TTPOST Added asterisks to multiplexing diagrams to
10940 indicate centre of context. Added Figure 6a
10941 showing cascading of multiplexes.
10943 6.2.2 IG0601 Added text indicating that ALL does not
10946 6.2.3 IG1100 Added text clarifying what must be supported
10947 to claim support of a package.
10949 6.2.3 IG1100 Added text indicating what packages a peer can
10950 indicate support for, when some of them are
10951 extensions of others.
10953 6.2.4 IG0601 Added text on ability of provisioning to
10954 override default values, and need for MGC to
10955 audit to learn the provisioned defaults.
10957 6.2.4 IG0601 Added text indicating effect of omitting
10958 specific properties from Descriptors in
10959 commands modifying a termination.
10960 Contradicted original text saying that omitted
10961 properties retain their prior values (still
10962 true for entirely-omitted Descriptors).
10964 6.2.4 GEN0202 Modified above text to restrict it to
10965 read/write properties, allow for default
10966 behaviour in place of default values if so
10967 specified in the property definition.
10969 6.2.4 IGDUB Trimmed definition of signals Descriptor in
10970 table and inserted cross-reference to section
10973 6.2.4 IG1100 Added Topology and Error Descriptors to table.
10978 Groves, et al. Standards Track [Page 196]
10980 RFC 3525 Gateway Control Protocol June 2003
10983 6.2.5 IGDUB Specified error code to return if ROOT used
10986 7.1.1 IG1100 Added qualification to explanation of effect
10987 of missing Audit Descriptor, excepting
10990 7.1.3 GEN0202 Changed "inputs" to "bearers" to be consistent
10991 with terminology in 6.2.
10993 7.1.4 IG0601 Small change to make clear that more than one
10994 of Local, Remote, and LocalControl can be
10995 included in the default streamId.
10997 7.1.7 IG0601 Default value for Mode specified to be
11000 7.1.7 GEN0202 Added text requiring processing of media in
11001 any of the reserved formats, where more than
11002 one has been reserved in a given stream.
11004 7.1.8 IGDUB Added restriction to at most one m= line per
11005 session description.
11007 7.1.9 IG0601 Text added to omit request identifier if the
11008 EventsDescriptor is empty. Further text added
11009 at end to indicate the effects of an empty
11010 EventsDescriptor and an empty
11011 EventBufferDescriptor.
11013 7.1.9 IG0601 Fixed typo for destination of a Notify.
11015 7.1.9 IG1100 Added note to say event remains active after
11016 it has been notified, so long as it is still
11017 present in the active Events Descriptor.
11019 7.1.11 IGDUB Added definition of signals.
11021 7.1.11 GEN0202 Modified definition to include example of more
11022 complex signal, and added role of signal in
11023 media preparation for future signals.
11025 7.1.11 IGDUB The timeout completion reason was broadened to
11026 include other circumstances where the signal
11027 completed on its own. Text added to indicate
11028 that if default signal type changed to TO,
11029 duration parameter must be provided.
11034 Groves, et al. Standards Track [Page 197]
11036 RFC 3525 Gateway Control Protocol June 2003
11039 7.1.11 GEN0202 Removed reference to BR signal being "so
11040 short" it will stop on its own. Added text
11041 indicating that if the type of a signal is
11042 changed to TO, the Duration parameter must be
11045 7.1.11 IG1100 Deleted text discussing type of Signals List.
11047 7.1.12 GEN0202 Improved wording of introductory paragraph and
11048 added text making content of returned
11051 7.1.14.2 GEN0202 Added text indicating that when the start
11052 timer is set to 0, initial digit timing is
11053 disabled and the MG waits indefinitely for
11056 7.1.14.2 GEN0202 Added text pointing out that default digit
11057 timer values should be provisioned, but can be
11058 overridden in the digit map.
11060 7.1.14.3 GEN0202 Changed result of long-short digit timer
11061 conflict from undefined to long.
11063 7.1.14.6 IG1100 Clarified that the digit map is provided by
11064 the eventDM parameter, which must be present.
11066 7.1.14.7 GEN0202 Added text clarifying that events covered by
11067 the digit map completion event have no side-
11068 effects unless separately enabled.
11070 7.1.14.8 IG0601 Added requirement that the event specification
11071 include the eventDM parameter.
11073 7.1.17 IGDUB Added text to indicate timestamp is optional
11074 and to include observed event parameters in
11077 7.1.17 GEN0202 Deleted provision that time is expressed in
11078 UTC (since intention was to use format, not
11081 7.1.18 IGDUB Added text indicating error to return if
11082 topology option not supported.
11090 Groves, et al. Standards Track [Page 198]
11092 RFC 3525 Gateway Control Protocol June 2003
11095 7.1.18 IG1100 Added text clarifying effect of not mentioning
11096 TTPOST a termination in a topology Descriptor, and
11097 default topology for a new termination. (This
11098 text got lost between the Dublin meeting and
11099 the production of H.248 Amendment 1 out of the
11100 Geneva 02/02 meeting. It has been added back
11101 to the present document.)
11103 7.1.19 IG1100 New section to describe Error Descriptor.
11104 GEN0202 Slightly edited in Geneva 02/02 meeting.
11105 ITUPOST Reference for error code documentation updated
11108 7.1.19 IG0601 Added paragraph giving guidance on level at
11109 which errors should be reported.
11111 7.2 IG1100 Noted possibility of Error Descriptor in reply
11114 7.2.1 IG1100 Added EventBufferDescriptor as Add parameter.
11116 7.2.1 IG1100 Removed restriction on use of CHOOSE wildcard.
11118 7.2.2 IG1100 Added EventBufferDescriptor as Modify
11121 7.2.2 GEN0202 Added text on side-effects of Modify of a
11122 multiplexing termination.
11124 7.2.3 IG1100 Added prohibition against subtracting from the
11127 7.2.3 GEN0202 Added text on side-effects of Subtract of a
11128 multiplexing termination.
11130 7.2.3 IGDUB Added text clarifying effect of empty
11131 AuditDescriptor in Subtract.
11133 7.2.4 IG1100 Added EventBufferDescriptor as Move parameter.
11135 7.2.4 GEN0202 Removed misleading statement that Move acts as
11136 subtract from original context.
11138 7.2.4 IG1100 Clarified effect of Move on properties of the
11141 7.2.4 GEN0202 Added text on side-effects of Move of a
11142 multiplexing termination.
11146 Groves, et al. Standards Track [Page 199]
11148 RFC 3525 Gateway Control Protocol June 2003
11151 7.2.5 IG1100 Added examples showing W- wildcard usage.
11153 7.2.5 IG1100 Noted that returning a list of all contextIDs
11154 requires that they be returned one per
11157 7.2.5 IG1100 Added table entry (ALL, specific) to determine
11158 context in which termination currently
11161 7.2.6 GEN0202 Added table similar to that in 7.2.5.
11163 7.2.7 IG0601 Added TerminationID to API.
11165 7.2.7 IGDUB Indicated timestamp was optional in Notify, to
11166 accord with syntax.
11168 7.2.7 IG1100 Noted possibility of sending Error Descriptor
11171 7.2.8 IG0601 Added text to description of Forced method to
11172 indicate that Forced on ROOT indicates a cold
11173 restart (all context state lost).
11175 7.2.8 IGDUB Amplified explanation of Disconnected method
11176 to emphasize return to the previously
11179 7.2.8 IG0601 Added text for MG use of Failover method when
11180 it detects MGC failure.
11182 7.2.8 IG1100 Added notes discouraging use of
11183 ServiceChangeAddress and warning that it could
11184 be either a full address or just a port
11187 7.2.8 IG0601 Added text indicating that timestamp does not
11188 necessarily represent absolute time, only
11189 local clock reading.
11191 7.2.8 IGDUB Corrected "gateway" to "MGC" in discussion of
11192 returned ServiceChangeMgcId parameter.
11194 7.3 IG0601 Removed error code documentation to Annex L
11195 ITUPOST (now H.248.8).
11197 8 IG1100 Added requirement that an Action be non-empty.
11202 Groves, et al. Standards Track [Page 200]
11204 RFC 3525 Gateway Control Protocol June 2003
11207 8 GEN0202 Added context properties and context property
11208 audit requests to commands as potential
11209 contents of actions.
11211 8.1.2 GEN0202 Added prohibition on using partial contextIDs
11212 with ALL wildcards.
11214 8.2.2 IG1100 Added text clarifying when in transaction
11215 processing the requested actions have been
11216 completed and a reply can be sent.
11218 8.2.2 IG1100 Added ALL as allowed contextID in
11221 8.2.2 GEN0202 Provided general reference to section 7.1.19
11222 for generation of error Descriptors.
11224 8.2.2 IG0601 Corrected Actions to Commands when discussing
11225 partially-understood action.
11227 8.3 IG0601 Added text specifying that the same MId value
11228 must be used by a given entity throughout the
11229 life of a control association.
11231 8.3 IG0601 Added text expanding on independence of
11232 transactions from messages.
11234 9 ITUPOST Indicated that additional transports may be
11235 defined in separate Recommendations as well as
11236 annexes to the primary specification.
11238 9 IG0601 Gave specific example of "request source
11241 9.1 IG1100 Deleted restriction to one outstanding Notify
11242 command on a termination at one time, since
11243 this is transport-specific.
11245 9.1 IG0601 Restored restriction, but noted that it
11246 applied only to transport not guaranteeing
11249 10.2 IG1100 Corrected length of synthesized address field
11250 from 10 to 20 hex digits and indicated that
11251 calculation should be over entire message, not
11252 just one transaction.
11258 Groves, et al. Standards Track [Page 201]
11260 RFC 3525 Gateway Control Protocol June 2003
11263 11.2 IG1100 Corrected text in first two paragraphs
11264 describing use of ServiceChangeMgcId
11267 11.2 IG1100 Corrected "Transaction Accept" to "Transaction
11270 11.4 IG0601 Noted that support of redundant MGs requires
11271 GEN0202 use of a reliable transport and support in the
11272 MGC. Added more explanation in Geneva.
11274 11.5 IG0601 Added text clarifying procedure if MG unable
11275 to establish a control relationship with any
11276 of its eligible MGCs.
11278 11.5 IGDUB Added text indicating that when trying to
11279 reestablish contact with the previously
11280 controlling MGC the MG uses the Disconnected
11283 11.5 IG1100 Clarified handoff procedure.
11285 11.5 GEN0202 Changed text on replies to transactions in
11286 progress during handoff. Replies now
11287 discarded when the service relationship with
11288 the old MGC has ended, rather than sent to the
11289 new MGC. The new MGC could still send replies
11290 to requests sent to the old MGC.
11292 12.1.1 GEN0202 Added optional package designation as
11293 "designed to be extended only".
11295 12.1.1 IG1100 Made prohibition on overloading of identifiers
11296 in extended packages transitive through all
11297 ancestors of the extended package.
11299 12.1.2 IGDUB Clarified the set of types allowed for
11302 12.1.2 GEN0202 Added requirement to specify the base type of
11305 12.1.2 GEN0202 Provided requirements for content of the
11306 "Possible Values" template item, including
11307 specification of default values or behaviour.
11314 Groves, et al. Standards Track [Page 202]
11316 RFC 3525 Gateway Control Protocol June 2003
11319 12.1.4 GEN0202 Added requirement to specify the default
11320 signal type, and specify a default duration
11321 for TO signals. Also noted that duration is
11322 meaningless for BR, and that the signal type
11323 might be dependent on the values of other
11326 12.2 GEN0202 Fixed section title (covers only event and
11327 signal parameters, not properties or
11330 12.2 IG1100 Reserved SPA and EPA prefixes, so they are not
11331 to be used for signal and event parameter
11334 12.2 IG0601 Expanded list of reserved prefixes.
11336 12.2 IGDUB Clarified the set of types allowed for signal
11337 and event parameters.
11339 12.2 GEN0202 Added requirement to specify the base type of
11342 12.2 GEN0202 Provided requirements for content of the
11343 "Possible Values" template item, including
11344 specification of default values or behaviour.
11346 12.4 IGDUB Corrected to indicate identifiers must start
11347 with alphabetic rather than alphanumeric
11350 13.1 IG0601 Changed private range of binary package
11351 identifiers to convenient hex values.
11353 A GEN0202 Removed versions from X.680 and X.690
11356 A.2 IGDUB Added note warning that the syntax alone does
11357 not provide a complete description of the
11358 constraints, but must be supplemented by a
11359 reading of the text and comments.
11361 A.2 IG0601 Added description of double wrapping of
11362 parameters declared as OCTET STRING.
11370 Groves, et al. Standards Track [Page 203]
11372 RFC 3525 Gateway Control Protocol June 2003
11375 A.2 GEN0202 Some editing of double wrapping description to
11376 use ASN.1, BER in their proper places. Added
11377 possibility of encoding strings as UTF8String,
11378 but only if they contain non-ASCII characters.
11380 A.2 IGDUB Added line in table on double wrapping of true
11383 A.2 IG1100 Corrected and expanded comments describing
11384 mtpAddress form of MId. Fixed maximum length
11385 of mtpAddress both here and in
11386 ServiceChangeAddress.
11388 A.2 IG0601 Inserted missing lines in IP4Address
11391 A.2 IG0601 Modified TransactionResponseAck to allow
11392 acknowledgement of multiple ranges of
11395 A.2 IG0601 Corrected numerical value of CHOOSE as a
11396 context identifier.
11398 A.2 IGDUB Added missing extension marker in
11401 A.2 IG1100 AuditReply and AuditResult modified to bring
11402 binary functionality into line with text
11405 A.2 IG0601 Removed OPTIONAL tag from terminationID in
11408 A.2 IG0601 Added extraInfo substructure to EventParameter
11411 A.2 IG0601 Modified MediaDescriptor to make it optional
11412 to specify a stream.
11414 A.2 IG0601 Added OPTIONAL tags to reserveValue and
11417 A.2 IGDUB Added to comments for pkgdName to indicate
11418 applicability to event names, signal names,
11419 and statisticIds as well as property.
11426 Groves, et al. Standards Track [Page 204]
11428 RFC 3525 Gateway Control Protocol June 2003
11431 A.2 IG0601 RequestID made optional in EventsDescriptor
11432 and SecondEventsDescriptor and comment added
11433 saying it must be present if events are
11436 A.2 IG1100 Added OPTIONAL tags on RequestActions and
11437 SecondRequestedActions keepActive BOOLEANs.
11439 A.2 IG1100 Added comment to indicate requestID value to
11440 use in an AuditCapReply.
11442 A.2 GEN0202 Added comment to DigitMapValue indicating time
11445 A.2 IG0601 Added comment indicating coding of Value for
11446 GEN0202 ServiceChangeReason. Cleaned up in Geneva to
11447 use ASN.1 and BER in their proper places.
11449 A.2 IG0601 Inserted missing extension marker in
11450 ServiceChangeParm production.
11452 A.2 IG0601 Aligned definition of mtpAddress in
11453 ServiceChangeAddress with that in MId.
11455 A.2 IG0601 Added timestamp to ServiceChangeResParm.
11457 A.2 IGDUB Changed type of profileName in
11458 ServiceChangeProfile to IA5String.
11460 A.2 IG0601 Made returned value optional in
11461 statisticsParameter, to support
11462 auditCapability result.
11464 A.2 GEN0202 Added reference to ISO 8601:1988 for
11467 A.2 IG1100 Value production modified to support the
11468 sublist parameter type.
11470 A.3 IG1100 Corrected ABNF for digitStringlisT, replacing
11473 A.3 IG1100 Added parentheses to digitMapRange production.
11475 A.3 IG1100 Replaced more abbreviated syntax for pathName
11476 with fuller definition and constraints copied
11482 Groves, et al. Standards Track [Page 205]
11484 RFC 3525 Gateway Control Protocol June 2003
11487 B.2 IGDUB Added note warning that the syntax alone does
11488 not provide a complete description of the
11489 constraints, but must be supplemented by a
11490 reading of the text and comments.
11492 B.2 IG0601 Added note warning that the interpretation of
11493 symbols is context-dependent.
11495 B.2 IG1100 Added comment to indicate case insensitivity
11496 of protocol (excepting SDP) and ABNF.
11498 B.2 IG0601 Expanded upon and capitalized this comment.
11500 B.2 IG0601 Lengthy note added on the coding of the VALUE
11503 B.2 IGDUB Deleted sentence in note suggesting that
11504 packages could add new types for properties,
11505 parameters, or statistics.
11507 B.2 IG0601 Added note indicating that parsers should
11508 allow for white space preceding the first line
11509 of SDP in Local or Remote.
11511 B.2 IGDUB Added comments identifying the O- and W- tags.
11513 B.2 IG1100 Moved wildcard tag up from individual commands
11514 to commandRequestList.
11516 B.2 GEN0202 Added additional error case to actionReply.
11518 B.2 IG0601 Modified syntax of auditOther to allow return
11519 of terminationID only.
11521 B.2 IGDUB Corrected upper limit for V4hex.
11523 B.2 IG1100 Corrected and expanded comments describing
11524 mtpAddress form of MId.
11526 B.2 IG0601 Modified comment to mediaParm to make
11527 streamParms and StreamDescriptor mutually
11530 B.2 GEN0202 Modified comment further to indicate at most
11531 one instance of terminationStateDescriptor.
11533 B.2 GEN0202 Expanded comment for streamParm to indicate
11534 the restriction on repetition is per item.
11538 Groves, et al. Standards Track [Page 206]
11540 RFC 3525 Gateway Control Protocol June 2003
11543 B.2 IG0601 Modified "at most once" comments to localParm,
11544 terminationStateParm, and modemType, to allow
11545 multiple instances of propertyParm in the
11546 first two cases and extensionParameter in the
11549 B.2 IG0601 Added note before description of Local and
11550 Remote, pointing out that the octet value x00
11551 is not allowed in octetString.
11553 B.2 IG0601 Syntax for eventsDescriptor, embedFirst, and
11554 eventBufferDescriptor modified to make
11555 contents beyond token optional.
11557 B.2 IGDUB Replaced "event" by "item" in comment to
11558 pkgdName because pkgdName applies to
11559 properties, signals, and statistics as well.
11561 B.2 IG0601 Corrected placement of EQUAL in eventDM
11564 B.2 IG1100 Added comment and syntax to indicate requestID
11565 value to use in an AuditCapReply.
11567 B.2 IG1100 Corrected Modem Descriptor to allow package
11568 items as properties.
11570 B.2 IG0601 Comment to modemType changed to allow multiple
11571 instances of extensionParameter.
11573 B.2 GEN0202 Comment added to indicate units for Timer.
11575 B.2 IG1100 Added parentheses to digitMapRange production.
11577 B.2 IG1100 Added comment to serviceChangeParm,
11578 restricting each parameter to one appearance.
11580 B.2 IG0601 Added comments making serviceChangeMgcId and
11581 serviceChangeAddress mutually exclusive in
11582 ServiceChangeParm and servChgReplyParm.
11584 B.2 IGDUB Added comment to serviceChangeParm indicating
11585 that ServiceChangeMethod and
11586 ServiceChangeReason are required.
11588 B.2 IG0601 Added Timestamp to servChgReplyParm.
11594 Groves, et al. Standards Track [Page 207]
11596 RFC 3525 Gateway Control Protocol June 2003
11599 B.2 IG0601 Added comment indicating coding of Value for
11600 ServiceChangeReason.
11602 B.2 IG0601 Modified ServiceChangeAddress to use MId
11603 definition for full address.
11605 B.2 IG1100 Made returned value optional in
11606 statisticsParameter, to support
11607 auditCapability result.
11609 B.2 IG1100 Changed topologyDescriptor to allow multiple
11612 B.2 IG0601 Added comment forbidding use of a double quote
11613 within a quotedString value.
11615 B.2 IG1100 Reserved prefixes for new tokens added to
11616 signalParameter and eventParameter, to avoid
11617 collision with package names.
11619 B.2 IG1100 EmbedToken and EmergencyToken changed to
11620 remove clash with EventBufferToken.
11622 B.3 IG1100 New section describing hexadecimal octet
11625 B.4 IG1100 New section describing hex octet sequence.
11627 C IG1100 Added permission to use Annex C properties in
11628 LocalControl as well as in Local and Remote.
11630 C IG0601 Added text making support of all properties of
11633 C IGDUB Added directions to reconcile tabulated
11634 formats with allowed types for properties.
11636 C.1 IG1100 Corrected Q.765 reference to Q.765.5 for
11639 C.1 IG1100 Deprecated Echocanc codepoint in favour of
11640 package-defined property.
11642 C.4 ITUPOST Updated references from Q.2961 to Q.2961.1.
11644 C.4 IGDUB Added details on format of VPVC.
11646 C.9 IG1100 Renamed USI to layer1prot.
11650 Groves, et al. Standards Track [Page 208]
11652 RFC 3525 Gateway Control Protocol June 2003
11655 C.9 IG1100 Deprecated ECHOCI codepoint in favour of
11656 package-defined property.
11658 C.9 IG1100 Added new USI property.
11660 C.11 IG1100 Added m= line tag.
11662 D.1 IG0601 Added explanation of ALF.
11664 D.1.5 IGDUB Expanded text indicating that when trying to
11665 reestablish contact with the previously
11666 controlling MGC the MG uses the Disconnected
11669 E.1.2 GEN0202 Added missing EventsDescriptor parameters
11672 E.1.2 GEN0202 For the Signal Completion event:
11673 - corrected the description of how it is
11675 - heavily edited the description of the Signal
11676 Identity observed event parameter and added a
11679 E.1.2 IGDUB The timeout completion reason for the Signal
11680 Completion event was broadened to include
11681 other circumstances where the signal completed
11684 E.1.2 IG1100 Added signal list ID observed event parameter
11685 to the Signal Completion event.
11687 E.2.1 IG0601 Added missing read only, read-write
11690 E.2.1 IG0601 Split ProvisionalResponseTimer properties into
11691 one for MG, one for MGC.
11693 E.3 GEN0202 Added "Designed to be extended only" to
11694 tonegen package description.
11696 E.4 GEN0202 Added "Designed to be extended only" to
11697 tonedet package description.
11699 E.4.2 GEN0202 Added type for tone ID observed parameter for
11700 Long Tone Detected event.
11706 Groves, et al. Standards Track [Page 209]
11708 RFC 3525 Gateway Control Protocol June 2003
11711 E.6.2 IG1100 Corrected binary identifier for digit map
11712 completion event to avoid clash with base
11715 E.6.2 IG1100 Removed procedural text.
11717 E.6.5 IG1100 Added procedural text indicating where to find
11718 the applicable digit map and indicating the
11719 error to return if the parameter is missing.
11721 E.6.5 IG0601 Further modified procedural text.
11723 E.7.3 IG1100 Corrected text identifier for payphone
11724 recognition tone to avoid clash with base
11727 E.10.5 IGDUB Provided informative references for tones and
11728 procedures for continuity check.
11730 E.13 GEN0202 Added note that TDM package could also apply
11731 to other transports.
11733 E.13.1 IG1100 Changed default for echo cancellation from
11734 "on" to provisioned.
11736 E.13.1 IG0601 Corrected type for gain property.
11738 Appendix TTPOST Included a number of corrections which were
11739 I not picked up in H.248.1 Amendment 1 but which
11740 do appear in H.248.1 v2.
11742 Intellectual Property Rights
11744 The ITU draws attention to the possibility that the practice or
11745 implementation of this RFC may involve the use of a claimed
11746 Intellectual Property Right. The ITU takes no position concerning
11747 the evidence, validity or applicability of claimed Intellectual
11748 Property Rights, whether asserted by ITU members or others outside of
11749 the Recommendation development process.
11751 As of the date of approval of this RFC, the ITU had received notice
11752 of intellectual property, protected by patents, which may be required
11753 to implement this RFC. However, implementors are cautioned that this
11754 may not represent the latest information and are therefore strongly
11755 urged to consult the TSB patent database.
11762 Groves, et al. Standards Track [Page 210]
11764 RFC 3525 Gateway Control Protocol June 2003
11767 The IETF has also received notice of intellectual property claims
11768 relating to Megaco/H.248.1. Please consult the IETF IPR
11769 announcements at http://www.ietf.org/ipr.html.
11773 Megaco/H.248.1 is the result of hard work by many people in both the
11774 IETF and in ITU-T Study Group 16. This section records those who
11775 played a prominent role in ITU-T meetings, on the Megaco list, or
11778 Megaco/H.248 owes a large initial debt to the MGCP protocol (RFC
11779 2705), and thus to its authors, Mauricio Arango, Andrew Dugan, Ike
11780 Elliott, Christian Huitema, and Scott Pickett. Flemming Andreasen
11781 does not appear on this list of authors, but was a major contributor
11782 to the development of both MGCP and Megaco/H.248.1. RFC 3435 has an
11783 extensive acknowledgement of many other people who worked on media
11784 gateway control before Megaco got started.
11786 The authors of the first Megaco RFCs (2805, then 3015) were Fernando
11787 Cuervo, Nancy Greene, Abdallah Rayhan, Christian Huitema, Brian
11788 Rosen, and John Segers. Christian Groves conceived and was editor of
11789 Annex C. The people most active on the Megaco list in the period
11790 leading up to the completion of RFC 2885 were Brian Rosen, Tom
11791 Taylor, Nancy Greene, Christian Huitema, Matt Holdrege, Chip Sharp,
11792 John Segers, Michael Thomas, Henry Sinnreich, and Paul Sijben. The
11793 people who sacrificed sleep and meals to complete the massive amount
11794 of work required in the decisive Study Group 16 meeting of February,
11795 2000, were Michael Brown, Ranga Dendi, Larry Forni, Glen Freundlich,
11796 Christian Groves, Alf Heidemark, Steve Magnell, Selvam Rengasami,
11797 Rich Rubin, Klaus Sambor, John Segers, Chip Sharp, Tom Taylor, and
11800 The most active people on the Megaco list in the period since the
11801 February 2000 have been Tom Taylor, Brian Rosen, Christian Groves,
11802 Madhu Babu Brahmanapally, Troy Cauble, Terry Anderson, Chuong Nguyen,
11803 and Kevin Boyle, but many other people have been regular
11804 contributors. Brian Rosen did tremendous service in putting together
11805 the Megaco interoperability tests. On the Study Group 16 side, the
11806 editorial team for the final revised document in February, 2002
11807 included Christian Groves, Marcello Pantaleo, Terry Anderson, Peter
11808 Leis, Kevin Boyle, and Tom Taylor.
11810 Tom Taylor as Megaco Chair managed the day to day operation of the
11811 Megaco list, with Brian Rosen taking an equal share of the burden for
11812 most of the last three years. Glen Freundlich as the Study Group 16
11813 Rapporteur ran the ITU-T meetings and ensured that all of the work at
11814 hand was completed. Without Glen's determination the Megaco/H.248
11818 Groves, et al. Standards Track [Page 211]
11820 RFC 3525 Gateway Control Protocol June 2003
11823 standard would have taken at least half a year longer to produce.
11824 Christian Groves filled in ably as Rapporteur when Glen could no
11831 Bernardsville, NJ 07924
11834 EMail: tlatla@verizon.net
11838 Ericsson AsiaPacificLab Australia
11839 37/360 Elizabeth St
11840 Melbourne, Victoria 3000
11843 EMail: Christian.Groves@ericsson.com.au
11847 Ericsson Eurolab Deuschland
11849 52134 Herzogenrath, Germany
11851 EMail: Marcello.Pantaleo@eed.ericsson.se
11860 Phone: +1 613 736 0961
11861 EMail: taylor@nortelnetworks.com
11874 Groves, et al. Standards Track [Page 212]
11876 RFC 3525 Gateway Control Protocol June 2003
11879 Full Copyright Statement
11881 Copyright (C) The Internet Society (2003). All Rights Reserved.
11883 This document and translations of it may be copied and furnished to
11884 others, and derivative works that comment on or otherwise explain it
11885 or assist in its implementation may be prepared, copied, published
11886 and distributed, in whole or in part, without restriction of any
11887 kind, provided that the above copyright notice and this paragraph are
11888 included on all such copies and derivative works. However, this
11889 document itself may not be modified in any way, such as by removing
11890 the copyright notice or references to the Internet Society or other
11891 Internet organizations, except as needed for the purpose of
11892 developing Internet standards in which case the procedures for
11893 copyrights defined in the Internet Standards process must be
11894 followed, or as required to translate it into languages other than
11897 The limited permissions granted above are perpetual and will not be
11898 revoked by the Internet Society or its successors or assigns.
11900 This document and the information contained herein is provided on an
11901 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
11902 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
11903 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
11904 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
11905 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11909 Funding for the RFC Editor function is currently provided by the
11930 Groves, et al. Standards Track [Page 213]
Code Review / com / asn1c.git / blob