mirror of https://gerrit.osmocom.org/asn1c
11932 lines
429 KiB
Plaintext
11932 lines
429 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group C. Groves
|
||
Request for Comments: 3525 M. Pantaleo
|
||
Obsoletes: 3015 LM Ericsson
|
||
Category: Standards Track T. Anderson
|
||
Consultant
|
||
T. Taylor
|
||
Nortel Networks
|
||
Editors
|
||
June 2003
|
||
|
||
|
||
Gateway Control Protocol Version 1
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This document defines the protocol used between elements of a
|
||
physically decomposed multimedia gateway, i.e., a Media Gateway and a
|
||
Media Gateway Controller. The protocol presented in this document
|
||
meets the requirements for a media gateway control protocol as
|
||
presented in RFC 2805.
|
||
|
||
This document replaces RFC 3015. It is the result of continued
|
||
cooperation between the IETF Megaco Working Group and ITU-T Study
|
||
Group 16. It incorporates the original text of RFC 3015, modified by
|
||
corrections and clarifications discussed on the Megaco
|
||
E-mail list and incorporated into the Study Group 16 Implementor's
|
||
Guide for Recommendation H.248. The present version of this document
|
||
underwent ITU-T Last Call as Recommendation H.248 Amendment 1.
|
||
Because of ITU-T renumbering, it was published by the ITU-T as
|
||
Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.
|
||
|
||
Users of this specification are advised to consult the H.248 Sub-
|
||
series Implementors' Guide at http://www.itu.int/itudoc/itu-
|
||
t/com16/implgd for additional corrections and clarifications.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 1]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Conventions used in this document
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119 [RFC2119].
|
||
|
||
Table of Contents
|
||
|
||
1 Scope.........................................................5
|
||
1.1 Changes From RFC 3015.....................................5
|
||
1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)...5
|
||
2 References....................................................6
|
||
2.1 Normative references......................................6
|
||
2.2 Informative references....................................9
|
||
3 Definitions..................................................10
|
||
4 Abbreviations................................................11
|
||
5 Conventions..................................................12
|
||
6 Connection model.............................................13
|
||
6.1 Contexts.................................................16
|
||
6.2 Terminations.............................................17
|
||
6.2.1 Termination dynamics.................................21
|
||
6.2.2 TerminationIDs.......................................21
|
||
6.2.3 Packages.............................................22
|
||
6.2.4 Termination properties and descriptors...............23
|
||
6.2.5 Root Termination.....................................25
|
||
7 Commands.....................................................26
|
||
7.1 Descriptors..............................................27
|
||
7.1.1 Specifying parameters................................27
|
||
7.1.2 Modem descriptor.....................................28
|
||
7.1.3 Multiplex descriptor.................................28
|
||
7.1.4 Media descriptor.....................................29
|
||
7.1.5 TerminationState descriptor..........................29
|
||
7.1.6 Stream descriptor....................................30
|
||
7.1.7 LocalControl descriptor..............................31
|
||
7.1.8 Local and Remote descriptors.........................32
|
||
7.1.9 Events descriptor....................................35
|
||
7.1.10 EventBuffer descriptor..............................38
|
||
7.1.11 Signals descriptor..................................38
|
||
7.1.12 Audit descriptor....................................40
|
||
7.1.13 ServiceChange descriptor............................41
|
||
7.1.14 DigitMap descriptor.................................41
|
||
7.1.15 Statistics descriptor...............................46
|
||
7.1.16 Packages descriptor.................................47
|
||
7.1.17 ObservedEvents descriptor...........................47
|
||
7.1.18 Topology descriptor.................................47
|
||
7.1.19 Error Descriptor....................................50
|
||
7.2 Command Application Programming Interface................50
|
||
7.2.1 Add..................................................51
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 2]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.2.2 Modify...............................................52
|
||
7.2.3 Subtract.............................................53
|
||
7.2.4 Move.................................................55
|
||
7.2.5 AuditValue...........................................56
|
||
7.2.6 AuditCapabilities....................................59
|
||
7.2.7 Notify...............................................60
|
||
7.2.8 ServiceChange........................................61
|
||
7.2.9 Manipulating and Auditing Context Attributes.........65
|
||
7.2.10 Generic Command Syntax..............................66
|
||
7.3 Command Error Codes......................................66
|
||
8 Transactions.................................................66
|
||
8.1 Common parameters........................................68
|
||
8.1.1 Transaction Identifiers..............................68
|
||
8.1.2 Context Identifiers..................................68
|
||
8.2 Transaction Application Programming Interface............69
|
||
8.2.1 TransactionRequest...................................69
|
||
8.2.2 TransactionReply.....................................69
|
||
8.2.3 TransactionPending...................................71
|
||
8.3 Messages.................................................72
|
||
9 Transport....................................................72
|
||
9.1 Ordering of Commands.....................................73
|
||
9.2 Protection against Restart Avalanche.....................74
|
||
10 Security Considerations.....................................75
|
||
10.1 Protection of Protocol Connections......................75
|
||
10.2 Interim AH scheme.......................................76
|
||
10.3 Protection of Media Connections.........................77
|
||
11 MG-MGC Control Interface....................................78
|
||
11.1 Multiple Virtual MGs....................................78
|
||
11.2 Cold start..............................................79
|
||
11.3 Negotiation of protocol version.........................79
|
||
11.4 Failure of a MG.........................................80
|
||
11.5 Failure of an MGC.......................................81
|
||
12 Package definition..........................................82
|
||
12.1 Guidelines for defining packages........................82
|
||
12.1.1 Package.............................................83
|
||
12.1.2 Properties..........................................84
|
||
12.1.3 Events..............................................85
|
||
12.1.4 Signals.............................................85
|
||
12.1.5 Statistics..........................................86
|
||
12.1.6 Procedures..........................................86
|
||
12.2 Guidelines to defining Parameters to Events and Signals.86
|
||
12.3 Lists...................................................87
|
||
12.4 Identifiers.............................................87
|
||
12.5 Package registration....................................88
|
||
13 IANA Considerations.........................................88
|
||
13.1 Packages................................................88
|
||
13.2 Error codes.............................................89
|
||
13.3 ServiceChange reasons...................................89
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 3]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ANNEX A Binary encoding of the protocol.......................90
|
||
A.1 Coding of wildcards......................................90
|
||
A.2 ASN.1 syntax specification...............................92
|
||
A.3 Digit maps and path names...............................111
|
||
ANNEX B Text encoding of the protocol.........................113
|
||
B.1 Coding of wildcards.....................................113
|
||
B.2 ABNF specification......................................113
|
||
B.3 Hexadecimal octet coding................................127
|
||
B.4 Hexadecimal octet sequence..............................127
|
||
ANNEX C Tags for media stream properties......................128
|
||
C.1 General media attributes................................128
|
||
C.2 Mux properties..........................................130
|
||
C.3 General bearer properties...............................130
|
||
C.4 General ATM properties..................................130
|
||
C.5 Frame Relay.............................................134
|
||
C.6 IP......................................................134
|
||
C.7 ATM AAL2................................................134
|
||
C.8 ATM AAL1................................................136
|
||
C.9 Bearer capabilities.....................................137
|
||
C.10 AAL5 properties........................................147
|
||
C.11 SDP equivalents........................................148
|
||
C.12 H.245..................................................149
|
||
ANNEX D Transport over IP.....................................150
|
||
D.1 Transport over IP/UDP using Application Level Framing ..150
|
||
D.1.1 Providing At-Most-Once functionality................150
|
||
D.1.2 Transaction identifiers and three-way handshake.....151
|
||
D.1.3 Computing retransmission timers.....................152
|
||
D.1.4 Provisional responses...............................153
|
||
D.1.5 Repeating Requests, Responses and Acknowledgements..153
|
||
D.2 Using TCP...............................................155
|
||
D.2.1 Providing the At-Most-Once functionality............155
|
||
D.2.2 Transaction identifiers and three-way handshake.....155
|
||
D.2.3 Computing retransmission timers.....................156
|
||
D.2.4 Provisional responses...............................156
|
||
D.2.5 Ordering of commands................................156
|
||
ANNEX E Basic packages.......................................157
|
||
E.1 Generic.................................................157
|
||
E.2 Base Root Package.......................................159
|
||
E.3 Tone Generator Package..................................161
|
||
E.4 Tone Detection Package..................................163
|
||
E.5 Basic DTMF Generator Package............................166
|
||
E.6 DTMF detection Package..................................167
|
||
E.7 Call Progress Tones Generator Package...................169
|
||
E.8 Call Progress Tones Detection Package...................171
|
||
E.9 Analog Line Supervision Package.........................172
|
||
E.10 Basic Continuity Package...............................175
|
||
E.11 Network Package........................................178
|
||
E.12 RTP Package............................................180
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 4]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.13 TDM Circuit Package....................................182
|
||
APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE)...................184
|
||
A.1 Residential Gateway to Residential Gateway Call.........184
|
||
A.1.1 Programming Residential GW Analog Line Terminations
|
||
for Idle Behavior...................................184
|
||
A.1.2 Collecting Originator Digits and Initiating
|
||
Termination.........................................186
|
||
APPENDIX II Changes From RFC 3015............................195
|
||
Intellectual Property Rights..................................210
|
||
Acknowledgments...............................................211
|
||
Authors' Addresses............................................212
|
||
Full Copyright Statement......................................213
|
||
|
||
1 Scope
|
||
|
||
The present document, which is identical to the published version of
|
||
ITU-T Recommendation H.248.1 (03/2002) except as noted below, defines
|
||
the protocols used between elements of a physically decomposed
|
||
multimedia gateway. There are no functional differences from a
|
||
system view between a decomposed gateway, with distributed sub-
|
||
components potentially on more than one physical device, and a
|
||
monolithic gateway such as described in ITU-T Recommendation H.246.
|
||
This document does not define how gateways, multipoint control units
|
||
or interactive voice response units (IVRs) work. Instead it creates
|
||
a general framework that is suitable for these applications.
|
||
|
||
Packet network interfaces may include IP, ATM or possibly others.
|
||
The interfaces will support a variety of Switched Circuit Network
|
||
(SCN) signalling systems, including tone signalling, ISDN, ISUP, QSIG
|
||
and GSM. National variants of these signalling systems will be
|
||
supported where applicable.
|
||
|
||
1.1 Changes From RFC 3015
|
||
|
||
The differences between this document and RFC 3015 are documented in
|
||
Appendix II.
|
||
|
||
1.2 Differences From ITU-T Recommendation H.248.1 (03/2002)
|
||
|
||
This document differs from the corresponding ITU-T publication in the
|
||
following respects:
|
||
|
||
- Added IETF front matter in place of the corresponding ITU-T
|
||
material.
|
||
|
||
- The ITU-T summary is too H.323-specific and has been omitted.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 5]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- The IETF conventions have been stated as governing this document.
|
||
As discussed in section 5 below, this gives slightly greater
|
||
strength to "should" requirements.
|
||
|
||
- The Scope section (just above) has been edited slightly to suit
|
||
its IETF context.
|
||
|
||
- Added normative references to RFCs 2026 and 2119.
|
||
|
||
- Figures 4, 5, and 6 show the centre of the context for greater
|
||
clarity. Also added Figure 6a showing an important additional
|
||
example.
|
||
|
||
- Added a paragraph in section 7.1.18 which was approved in the
|
||
Implementor's Guide but lost inadvertently in the ITU-T approved
|
||
version.
|
||
|
||
- This document incorporates corrections to the informative examples
|
||
in Appendix I which also appear in H.248.1 version 2, but which
|
||
were not picked up in H.248.1 (03/2002).
|
||
|
||
- This document includes a new Appendix II listing all the changes
|
||
from RFC 3015.
|
||
|
||
- This document includes an Acknowledgements section listing the
|
||
authors of RFC 3015 but also many other people who contributed to
|
||
the development of the Megaco/H.248.x protocol.
|
||
|
||
- Moved the Intellectual Property declaration to its usual place in
|
||
an IETF document and added a reference to declarations on the IETF
|
||
web site.
|
||
|
||
2 References
|
||
|
||
The following ITU-T Recommendations and other references contain
|
||
provisions which, through reference in this text, constitute
|
||
provisions of this RFC. At the time of publication, the editions
|
||
indicated were valid. All Recommendations and other references are
|
||
subject to revision; all users of this RFC are therefore encouraged
|
||
to investigate the possibility of applying the most recent edition of
|
||
the Recommendations and other references listed below. A list of the
|
||
currently valid ITU-T Recommendations is regularly published.
|
||
|
||
2.1 Normative references
|
||
|
||
- ITU-T Recommendation H.225.0 (1999), Call signalling protocols and
|
||
media stream packetization for packet-based multimedia
|
||
communication systems.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 6]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- ITU-T Recommendation H.235 (1998), Security and encryption for
|
||
H-Series (H.323 and other H.245-based) multimedia terminals.
|
||
|
||
- ITU-T Recommendation H.245 (1998), Control protocol for multimedia
|
||
communication.
|
||
|
||
- ITU-T Recommendation H.246 (1998), Interworking of H-series
|
||
multimedia terminals with H-series multimedia terminals and
|
||
voice/voiceband terminals on GSTN and ISDN.
|
||
|
||
- ITU-T Recommendation H.248.8 (2002), H.248 Error Codes and Service
|
||
Change Reasons.
|
||
|
||
- ITU-T Recommendation H.323 (1999), Packet-based multimedia
|
||
communication systems.
|
||
|
||
- ITU-T Recommendation I.363.1 (1996), B-ISDN ATM adaptation layer
|
||
(AAL) specification: Type 1 AAL.
|
||
|
||
- ITU-T Recommendation I.363.2 (1997), B-ISDN ATM adaptation layer
|
||
(AAL) specification: Type 2 AAL.
|
||
|
||
- ITU-T Recommendation I.363.5 (1996), B-ISDN ATM adaptation layer
|
||
(AAL) specification: Type 5 AAL.
|
||
|
||
- ITU-T Recommendation I.366.1 (1998), Segmentation and Reassembly
|
||
Service Specific Convergence Sublayer for the AAL type 2.
|
||
|
||
- ITU-T Recommendation I.366.2 (1999), AAL type 2 service specific
|
||
convergence sublayer for trunking.
|
||
|
||
- ITU-T Recommendation I.371 (2000), Traffic control and congestion
|
||
control in B-ISDN.
|
||
|
||
- ITU-T Recommendation Q.763 (1999), Signalling System No. 7 - ISDN
|
||
user part formats and codes.
|
||
|
||
- ITU-T Recommendation Q.765.5 (2001), Application transport
|
||
mechanism - Bearer independent call control (BICC).
|
||
|
||
- ITU-T Recommendation Q.931 (1998), ISDN user-network interface
|
||
layer 3 specification for basic call control.
|
||
|
||
- ITU-T Recommendation Q.2630.1 (1999), AAL type 2 signalling
|
||
protocol (Capability Set 1).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 7]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- ITU-T Recommendation Q.2931 (1995), Digital Subscriber Signalling
|
||
System No. 2 (DSS2) - User-Network Interface (UNI) - Layer 3
|
||
specification for basic call/connection control.
|
||
|
||
- ITU-T Recommendation Q.2941.1 (1997), Digital Subscriber
|
||
Signalling System No. 2 - Generic identifier transport.
|
||
|
||
- ITU-T Recommendation Q.2961.1 (1995), Additional signalling
|
||
capabilities to support traffic parameters for the tagging option
|
||
and the sustainable call rate parameter set.
|
||
|
||
- ITU-T Recommendation Q.2961.2 (1997), Additional traffic
|
||
parameters: Support of ATM transfer capability in the broadband
|
||
bearer capability information element.
|
||
|
||
- ITU-T Recommendation Q.2965.1 (1999), Digital subscriber
|
||
signalling system No. 2 - Support of Quality of Service classes.
|
||
|
||
- ITU-T Recommendation Q.2965.2 (1999), Digital subscriber
|
||
signalling system No. 2 - Signalling of individual Quality of
|
||
Service parameters.
|
||
|
||
- ITU-T Recommendation V.76 (1996), Generic multiplexer using V.42
|
||
LAPM-based procedures.
|
||
|
||
- ITU-T Recommendation X.213 (1995), Information technology - Open
|
||
Systems Interconnection - Network service definition plus
|
||
Amendment 1 (1997), Addition of the Internet protocol address
|
||
format identifier.
|
||
|
||
- ITU-T Recommendation X.680 (1997), Information technology -
|
||
Abstract Syntax Notation One (ASN.1): Specification of basic
|
||
notation.
|
||
|
||
- ITU-T Recommendation X.690 (1997), Information Technology - ASN.1
|
||
Encoding Rules: Specification of Basic Encoding Rules (BER),
|
||
Canonical Encoding Rules (CER) and Distinguished Encoding Rules
|
||
(DER).
|
||
|
||
- ATM Forum (1996), ATM User-Network Interface (UNI) Signalling
|
||
Specification - Version 4.0.
|
||
|
||
[RFC 1006] Rose, M. and D. Cass, "ISO Transport Service on top of the
|
||
TCP, Version 3", STD 35, RFC 1006, May 1987.
|
||
|
||
[RFC 2026] Brander, S., "The Internet Standards Process -- Revision
|
||
3", BCP 9, RFC 2026, October 1996.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 8]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC 2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", RFC 2234, November 1997.
|
||
|
||
[RFC 2327] Handley, M. and V. Jacobson, "SDP: Session Description
|
||
Protocol", RFC 2327, April 1998.
|
||
|
||
[RFC 2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
|
||
2402, November 1998.
|
||
|
||
[RFC 2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
|
||
Payload (ESP)", RFC 2406, November 1998.
|
||
|
||
2.2 Informative references
|
||
|
||
- ITU-T Recommendation E.180/Q.35 (1998), Technical characteristics
|
||
of tones for the telephone service.
|
||
|
||
- CCITT Recommendation G.711 (1988), Pulse Code Modulation (PCM) of
|
||
voice frequencies.
|
||
|
||
- ITU-T Recommendation H.221 (1999), Frame structure for a 64 to
|
||
1920 kbit/s channel in audiovisual teleservices.
|
||
|
||
- ITU T Recommendation H.223 (1996), Multiplexing protocol for low
|
||
bit rate multimedia communication.
|
||
|
||
- ITU-T Recommendation H.226 (1998), Channel aggregation protocol
|
||
for multilink operation on circuit-switched networks
|
||
|
||
- ITU-T Recommendation Q.724 (1998), Signalling procedures.
|
||
|
||
- ITU-T Recommendation Q.764 (1999), Signalling system No. 7 - ISDN
|
||
user part signalling procedures.
|
||
|
||
- ITU-T Recommendation Q.1902.4 (2001), Bearer independent call
|
||
control protocol - Basic call procedures.
|
||
|
||
[RFC 768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
||
August 1980.
|
||
|
||
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
|
||
1981.
|
||
|
||
[RFC 793] Postel, J., "Transmission Control Protocol", STD 7, RFC
|
||
793, September 1981.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 9]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
[RFC 1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
|
||
51, RFC 1661, July 1994.
|
||
|
||
[RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
|
||
Jacobson, "RTP: A Transport Protocol for Real-Time
|
||
Applications", RFC 1889, January 1996.
|
||
|
||
[RFC 1890] Schulzrinne, H. and G. Fokus, "RTP Profile for Audio and
|
||
Video Conferences with Minimal Control", RFC 1890,
|
||
January 1996.
|
||
|
||
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the
|
||
Internet Protocol", RFC 2401, November 1998.
|
||
|
||
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
||
(IPv6) Specification", RFC 2460, December 1998.
|
||
|
||
[RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
|
||
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
|
||
March 1999.
|
||
|
||
[RFC 2805] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway
|
||
Control Protocol Architecture and Requirements", RFC 2805,
|
||
April 2000.
|
||
|
||
3 Definitions
|
||
|
||
This document defines the following terms:
|
||
|
||
Access gateway:
|
||
A type of gateway that provides a User-Network Interface (UNI) such
|
||
as ISDN.
|
||
|
||
Descriptor:
|
||
A syntactic element of the protocol that groups related properties.
|
||
For instance, the properties of a media flow on the MG can be set by
|
||
the MGC by including the appropriate descriptor in a command.
|
||
|
||
Media Gateway (MG):
|
||
The media gateway converts media provided in one type of network to
|
||
the format required in another type of network. For example, a MG
|
||
could terminate bearer channels from a switched circuit network
|
||
(e.g., DS0s) and media streams from a packet network (e.g., RTP
|
||
streams in an IP network). This gateway may be capable of processing
|
||
audio, video and T.120 alone or in any combination, and will be
|
||
capable of full duplex media translations. The MG may also play
|
||
audio/video messages and perform other IVR functions, or may perform
|
||
media conferencing.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 10]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Media Gateway Controller (MGC):
|
||
Controls the parts of the call state that pertain to connection
|
||
control for media channels in a MG.
|
||
|
||
Multipoint Control Unit (MCU):
|
||
An entity that controls the setup and coordination of a multi-user
|
||
conference that typically includes processing of audio, video and
|
||
data.
|
||
|
||
Residential gateway:
|
||
A gateway that interworks an analogue line to a packet network. A
|
||
residential gateway typically contains one or two analogue lines and
|
||
is located at the customer premises.
|
||
|
||
SCN FAS signalling gateway:
|
||
This function contains the SCN Signalling Interface that terminates
|
||
SS7, ISDN or other signalling links where the call control channel
|
||
and bearer channels are collocated in the same physical span.
|
||
|
||
SCN NFAS signalling gateway:
|
||
This function contains the SCN Signalling Interface that terminates
|
||
SS7 or other signalling links where the call control channels are
|
||
separated from bearer channels.
|
||
|
||
Stream:
|
||
Bidirectional media or control flow received/sent by a media gateway
|
||
as part of a call or conference.
|
||
|
||
Trunk:
|
||
A communication channel between two switching systems such as a DS0
|
||
on a T1 or E1 line.
|
||
|
||
Trunking gateway:
|
||
A gateway between SCN network and packet network that typically
|
||
terminates a large number of digital circuits.
|
||
|
||
4 Abbreviations
|
||
|
||
This RFC document uses the following abbreviations:
|
||
|
||
ALF Application Layer Framing
|
||
|
||
ATM Asynchronous Transfer Mode
|
||
|
||
CAS Channel Associated Signalling
|
||
|
||
DTMF Dual Tone Multi-Frequency
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 11]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
FAS Facility Associated Signalling
|
||
|
||
GSM Global System for Mobile communications
|
||
|
||
GW GateWay
|
||
|
||
IANA Internet Assigned Numbers Authority (superseded by Internet
|
||
Corporation for Assigned Names and Numbers - ICANN)
|
||
|
||
IP Internet Protocol
|
||
|
||
ISUP ISDN User Part
|
||
|
||
IVR Interactive Voice Response
|
||
|
||
MG Media Gateway
|
||
|
||
MGC Media Gateway Controller
|
||
|
||
NFAS Non-Facility Associated Signalling
|
||
|
||
PRI Primary Rate Interface
|
||
|
||
PSTN Public Switched Telephone Network
|
||
|
||
QoS Quality of Service
|
||
|
||
RTP Real-time Transport Protocol
|
||
|
||
SCN Switched Circuit Network
|
||
|
||
SG Signalling Gateway
|
||
|
||
SS7 Signalling System No. 7
|
||
|
||
5 Conventions
|
||
|
||
In the H.248.1 Recommendation, "SHALL" refers to a mandatory
|
||
requirement, while "SHOULD" refers to a suggested but optional
|
||
feature or procedure. The term "MAY" refers to an optional course of
|
||
action without expressing a preference. Note that these definition
|
||
are overridden in the present document by the RFC 2119 conventions
|
||
stated at the beginning of this document. RFC 2119 has a more
|
||
precise definition of "should" than is provided by the ITU-T.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 12]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
6 Connection model
|
||
|
||
The connection model for the protocol describes the logical entities,
|
||
or objects, within the Media Gateway that can be controlled by the
|
||
Media Gateway Controller. The main abstractions used in the
|
||
connection model are Terminations and Contexts.
|
||
|
||
A Termination sources and/or sinks one or more streams. In a
|
||
multimedia conference, a Termination can be multimedia and sources or
|
||
sinks multiple media streams. The media stream parameters, as well
|
||
as modem, and bearer parameters are encapsulated within the
|
||
Termination.
|
||
|
||
A Context is an association between a collection of Terminations.
|
||
There is a special type of Context, the null Context, which contains
|
||
all Terminations that are not associated to any other Termination.
|
||
For instance, in a decomposed access gateway, all idle lines are
|
||
represented by Terminations in the null Context.
|
||
|
||
Following is a graphical depiction of these concepts. The diagram of
|
||
Figure 1 gives several examples and is not meant to be an
|
||
all-inclusive illustration. The asterisk box in each of the Contexts
|
||
represents the logical association of Terminations implied by the
|
||
Context.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 13]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
+------------------------------------------------------+
|
||
|Media Gateway |
|
||
| +-------------------------------------------------+ |
|
||
| |Context +-------------+ | |
|
||
| | | Termination | | |
|
||
| | |-------------| | |
|
||
| | +-------------+ +->| SCN Bearer |<---+->
|
||
| | | Termination | +-----+ | | Channel | | |
|
||
| | |-------------| | |---+ +-------------+ | |
|
||
<-+--->| RTP Stream |---| * | | |
|
||
| | | | | |---+ +-------------+ | |
|
||
| | +-------------+ +-----+ | | Termination | | |
|
||
| | | |-------------| | |
|
||
| | +->| SCN Bearer |<---+->
|
||
| | | Channel | | |
|
||
| | +-------------+ | |
|
||
| +-------------------------------------------------+ |
|
||
| |
|
||
| |
|
||
| +------------------------------+ |
|
||
| (NULL Context) |Context | |
|
||
| +-------------+ | +-------------+ | |
|
||
| | Termination | | +-----+ | Termination | | |
|
||
| |-------------| | | | |-------------| | |
|
||
| | SCN Bearer | | | * |------| SCN Bearer |<---+->
|
||
| | Channel | | | | | Channel | | |
|
||
| +-------------+ | +-----+ +-------------+ | |
|
||
| +------------------------------+ |
|
||
| |
|
||
| |
|
||
| +-------------------------------------------------+ |
|
||
| |Context | |
|
||
| | +-------------+ +-------------+ | |
|
||
| | | Termination | +-----+ | Termination | | |
|
||
| | |-------------| | | |-------------| | |
|
||
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
|
||
| | | Channel | | | | Channel | | |
|
||
| | +-------------+ +-----+ +-------------+ | |
|
||
| +-------------------------------------------------+ |
|
||
| ___________________________________________________ |
|
||
+------------------------------------------------------+
|
||
|
||
Figure 1: Examples of Megaco/H.248 Connection Model
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 14]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The example in Figure 2 shows an example of one way to accomplish a
|
||
call-waiting scenario in a decomposed access gateway, illustrating
|
||
the relocation of a Termination between Contexts. Terminations T1
|
||
and T2 belong to Context C1 in a two-way audio call. A second audio
|
||
call is waiting for T1 from Termination T3. T3 is alone in Context
|
||
C2. T1 accepts the call from T3, placing T2 on hold. This action
|
||
results in T1 moving into Context C2, as shown in Figure 3.
|
||
|
||
+------------------------------------------------------+
|
||
|Media Gateway |
|
||
| +-------------------------------------------------+ |
|
||
| |Context C1 | |
|
||
| | +-------------+ +-------------+ | |
|
||
| | | Term. T2 | +-----+ | Term. T1 | | |
|
||
| | |-------------| | | |-------------| | |
|
||
<-+--->| RTP Stream |---| * |------| SCN Bearer |<---+->
|
||
| | | | | | | Channel | | |
|
||
| | +-------------+ +-----+ +-------------+ | |
|
||
| +-------------------------------------------------+ |
|
||
| |
|
||
| +-------------------------------------------------+ |
|
||
| |Context C2 | |
|
||
| | +-------------+ | |
|
||
| | +-----+ | Term. T3 | | |
|
||
| | | | |-------------| | |
|
||
| | | * |------| SCN Bearer |<---+->
|
||
| | | | | Channel | | |
|
||
| | +-----+ +-------------+ | |
|
||
| +-------------------------------------------------+ |
|
||
+------------------------------------------------------+
|
||
|
||
Figure 2: Example Call Waiting Scenario / Alerting Applied to T1
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 15]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
+------------------------------------------------------+
|
||
|Media Gateway |
|
||
| +-------------------------------------------------+ |
|
||
| |Context C1 | |
|
||
| | +-------------+ | |
|
||
| | | Term. T2 | +-----+ | |
|
||
| | |-------------| | | | |
|
||
<-+--->| RTP Stream |---| * | | |
|
||
| | | | | | | |
|
||
| | +-------------+ +-----+ | |
|
||
| +-------------------------------------------------+ |
|
||
| |
|
||
| +-------------------------------------------------+ |
|
||
| |Context C2 | |
|
||
| | +-------------+ +-------------+ | |
|
||
| | | Term. T1 | +-----+ | Term. T3 | | |
|
||
| | |-------------| | | |-------------| | |
|
||
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
|
||
| | | Channel | | | | Channel | | |
|
||
| | +-------------+ +-----+ +-------------+ | |
|
||
| +-------------------------------------------------+ |
|
||
+------------------------------------------------------+
|
||
|
||
Figure 3. Example Call Waiting Scenario / Answer by T1
|
||
|
||
6.1 Contexts
|
||
|
||
A Context is an association between a number of Terminations. The
|
||
Context describes the topology (who hears/sees whom) and the media
|
||
mixing and/or switching parameters if more than two Terminations are
|
||
involved in the association.
|
||
|
||
There is a special Context called the null Context. It contains
|
||
Terminations that are not associated to any other Termination.
|
||
Terminations in the null Context can have their parameters examined
|
||
or modified, and may have events detected on them.
|
||
|
||
In general, an Add command is used to add Terminations to Contexts.
|
||
If the MGC does not specify an existing Context to which the
|
||
Termination is to be added, the MG creates a new Context. A
|
||
Termination may be removed from a Context with a Subtract command,
|
||
and a Termination may be moved from one Context to another with a
|
||
Move command. A Termination SHALL exist in only one Context at a
|
||
time.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 16]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The maximum number of Terminations in a Context is a MG property.
|
||
Media gateways that offer only point-to-point connectivity might
|
||
allow at most two Terminations per Context. Media gateways that
|
||
support multipoint conferences might allow three or more Terminations
|
||
per Context.
|
||
|
||
6.1.1 Context attributes and descriptors
|
||
|
||
The attributes of Contexts are:
|
||
|
||
- ContextID.
|
||
|
||
- The topology (who hears/sees whom).
|
||
|
||
The topology of a Context describes the flow of media between the
|
||
Terminations within a Context. In contrast, the mode of a
|
||
Termination (send/receive/...) describes the flow of the media at
|
||
the ingress/egress of the media gateway.
|
||
|
||
- The priority is used for a Context in order to provide the MG with
|
||
information about a certain precedence handling for a Context.
|
||
The MGC can also use the priority to control autonomously the
|
||
traffic precedence in the MG in a smooth way in certain
|
||
situations (e.g., restart), when a lot of Contexts must be handled
|
||
simultaneously. Priority 0 is the lowest priority and a priority
|
||
of 15 is the highest priority.
|
||
|
||
- An indicator for an emergency call is also provided to allow a
|
||
preference handling in the MG.
|
||
|
||
6.1.2 Creating, deleting and modifying Contexts
|
||
|
||
The protocol can be used to (implicitly) create Contexts and modify
|
||
the parameter values of existing Contexts. The protocol has commands
|
||
to add Terminations to Contexts, subtract them from Contexts, and to
|
||
move Terminations between Contexts. Contexts are deleted implicitly
|
||
when the last remaining Termination is subtracted or moved out.
|
||
|
||
6.2 Terminations
|
||
|
||
A Termination is a logical entity on a MG that sources and/or sinks
|
||
media and/or control streams. A Termination is described by a number
|
||
of characterizing Properties, which are grouped in a set of
|
||
Descriptors that are included in commands. Terminations have unique
|
||
identities (TerminationIDs), assigned by the MG at the time of their
|
||
creation.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 17]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Terminations representing physical entities have a semi-permanent
|
||
existence. For example, a Termination representing a TDM channel
|
||
might exist for as long as it is provisioned in the gateway.
|
||
Terminations representing ephemeral information flows, such as RTP
|
||
flows, would usually exist only for the duration of their use.
|
||
|
||
Ephemeral Terminations are created by means of an Add command. They
|
||
are destroyed by means of a Subtract command. In contrast, when a
|
||
physical Termination is Added to or Subtracted from a Context, it is
|
||
taken from or to the null Context, respectively.
|
||
|
||
Terminations may have signals applied to them (see 7.1.11).
|
||
Terminations may be programmed to detect Events, the occurrence of
|
||
which can trigger notification messages to the MGC, or action by the
|
||
MG. Statistics may be accumulated on a Termination. Statistics are
|
||
reported to the MGC upon request (by means of the AuditValue command,
|
||
see 7.2.5) and when the Termination is taken out of the call it is
|
||
in.
|
||
|
||
Multimedia gateways may process multiplexed media streams. For
|
||
example, Recommendation H.221 describes a frame structure for
|
||
multiple media streams multiplexed on a number of digital 64 kbit/s
|
||
channels. Such a case is handled in the connection model in the
|
||
following way. For every bearer channel that carries part of the
|
||
multiplexed streams, there is a physical or ephemeral "bearer
|
||
Termination". The bearer Terminations that source/sink the digital
|
||
channels are connected to a separate Termination called the
|
||
"multiplexing Termination". The multiplexing termination is an
|
||
ephemeral termination representing a frame-oriented session. The
|
||
MultiplexDescriptor for this Termination describes the multiplex used
|
||
(e.g., H.221 for an H.320 session) and indicates the order in which
|
||
the contained digital channels are assembled into a frame.
|
||
|
||
Multiplexing terminations may be cascades (e.g., H.226 multiplex of
|
||
digital channels feeding into a H.223 multiplex supporting an H.324
|
||
session).
|
||
|
||
The individual media streams carried in the session are described by
|
||
StreamDescriptors on the multiplexing Termination. These media
|
||
streams can be associated with streams sourced/sunk by Terminations
|
||
in the Context other than the bearer Terminations supporting the
|
||
multiplexing Termination. Each bearer Termination supports only a
|
||
single data stream. These data streams do not appear explicitly as
|
||
streams on the multiplexing Termination and they are hidden from the
|
||
rest of the context.
|
||
|
||
Figures 4, 5, 6, and 6a illustrate typical applications of the
|
||
multiplexing termination and Multiplex Descriptor.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 18]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
+-----------------------------------+
|
||
| Context +-------+ |
|
||
+----+ | | |
|
||
Circuit 1 -|--| TC1|---------+ Tmux | |
|
||
| +----+ (Str 1) | | Audio +-----+
|
||
| | | +-----*-----+ |-----
|
||
| +----+ | H.22x | Stream 1 | |
|
||
Circuit 2 -|--| TC2|---------+ multi-| | TR1 |
|
||
| +----+ (Str 1) | plex | |(RTP)|
|
||
| | | | Video | |
|
||
| +----+ | +-----*-----+ |-----
|
||
Circuit 3 -|--| TC3|---------+ | Stream 2 | |
|
||
/ +----+ (Str 1) | | +-----+
|
||
/ | +-------+ |
|
||
/ +-----------------\-----------------+
|
||
Audio, video, and control \
|
||
signals are carried in frames Tmux is an ephemeral with two
|
||
spanning the circuits. explicit Stream Descriptors
|
||
and a Multiplex Descriptor.
|
||
|
||
Figure 4: Multiplexed Termination Scenario - Circuit to Packet
|
||
(Asterisks * denote the centre of the context)
|
||
|
||
Context
|
||
+--------------------------------------+
|
||
| +-------+ +-------+ |
|
||
+----+ | | | | +----+
|
||
Circuit 1 ----| TC1|---+ Tmux1 | Audio | Tmux2 +---| TC4|---
|
||
+----+ | +---*----+ | +----+
|
||
| | | Str 1 | | |
|
||
+----+ | H.22x | | H.22x | +----+
|
||
Circuit 2 ----| TC2|---+ multi-| | multi-+---| TC5|---
|
||
+----+ | plex | | plex | +----+
|
||
| | | Video | | |
|
||
+----+ | +---*----+ | +----+
|
||
Circuit 3 ----| TC3|---+ | Str 2 | +---| TC6|---
|
||
+----+ | | | | +----+
|
||
| +-------+ +-------+ |
|
||
+-----------------\-----/--------------+
|
||
\ /
|
||
Tmux1 and Tmux2 are ephemerals each with two
|
||
explicit Stream Descriptors and a Multiplex Descriptor.
|
||
|
||
Figure 5: Multiplexed Termination Scenario - Circuit to Circuit
|
||
(Asterisks * denote the centre of the context)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 19]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
+-----------------------------------+
|
||
| Context +-------+ |
|
||
+----+ | | |
|
||
Circuit 1 -|--| TC1|---------+ Tmux | |
|
||
| +----+ (Str 1) | | Audio +-----+
|
||
| | | +-----*-----+ TR1 |-----
|
||
| +----+ | H.22x | Stream 1 |(RTP)|
|
||
Circuit 2 -|--| TC2|---------+ multi-| +-----+
|
||
| +----+ (Str 1) | plex | |
|
||
| | | | Video +-----+
|
||
| +----+ | +-----*-----+ TR2 |-----
|
||
Circuit 3 -|--| TC3|---------+ | Stream 2 |(RTP)|
|
||
/ +----+ (Str 1) | | +-----+
|
||
/ | +-------+ |
|
||
/ +-----------------\-----------------+
|
||
Audio, video, and control \ Tmux is an ephemeral with two
|
||
signals are carried in frames explicit Stream Descriptors and
|
||
spanning the circuits. and a Multiplex Descriptor.
|
||
|
||
Figure 6: Multiplexed Termination Scenario - Single to Multiple
|
||
Terminations
|
||
(Asterisks * denote the centre of the context)
|
||
|
||
Context
|
||
+---------------------------------------------+
|
||
| +-------+ +-------+ |
|
||
Cct 1 +----+ | | | | Audio +-----+
|
||
----| TC1|---+ Tmux1 | | Tmux2 +-----*-----| TR1 |-----
|
||
+----+ | | | | Stream 1 |(RTP)|
|
||
| | | Data | | +-----+
|
||
Cct 2 +----+ | H.226 +-------+ H.223 | |
|
||
----| TC2|---+ multi-|(Str 1)| multi-| Control +-----+
|
||
+----+ | plex | | plex +-----*-----+ Tctl|-----
|
||
| | | | | Stream 3 +-----+
|
||
Cct 3 +----+ | | | | |
|
||
----| TC3|---+ | | | +-----+
|
||
+----+ | | | +-----*-----+ TR2 |-----
|
||
| +-------+ | | Video |(RTP)|
|
||
| +-------+ Stream 2 +-----+
|
||
| |
|
||
+---------------------------------------------+
|
||
Tmux1 has a Multiplex Descriptor and a single data stream.
|
||
Tmux2 has a Multiplex Descriptor with a single bearer and
|
||
three explicit Stream Descriptors.
|
||
|
||
Figure 6a: Multiplexed Termination Scenario - Cascaded Multiplexes
|
||
(Asterisks * denote the centre of the context)
|
||
Note: this figure does not appear in Rec. H.248.1
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 20]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Terminations may be created which represent multiplexed bearers, such
|
||
as an ATM AAL Type 2 bearer. When a new multiplexed bearer is to be
|
||
created, an ephemeral Termination is created in a Context established
|
||
for this purpose. When the Termination is subtracted, the
|
||
multiplexed bearer is destroyed.
|
||
|
||
6.2.1 Termination dynamics
|
||
|
||
The protocol can be used to create new Terminations and to modify
|
||
property values of existing Terminations. These modifications
|
||
include the possibility of adding or removing events and/or signals.
|
||
The Termination properties, and events and signals are described in
|
||
the ensuing subclauses. An MGC can only release/modify Terminations
|
||
and the resources that the Termination represents which it has
|
||
previously seized via, e.g., the Add command.
|
||
|
||
6.2.2 TerminationIDs
|
||
|
||
Terminations are referenced by a TerminationID, which is an arbitrary
|
||
schema chosen by the MG.
|
||
|
||
TerminationIDs of physical Terminations are provisioned in the Media
|
||
Gateway. The TerminationIDs may be chosen to have structure. For
|
||
instance, a TerminationID may consist of trunk group and a trunk
|
||
within the group.
|
||
|
||
A wildcarding mechanism using two types of wildcards can be used with
|
||
TerminationIDs. The two wildcards are ALL and CHOOSE. The former is
|
||
used to address multiple Terminations at once, while the latter is
|
||
used to indicate to a media gateway that it must select a Termination
|
||
satisfying the partially specified TerminationID. This allows, for
|
||
instance, that a MGC instructs a MG to choose a circuit within a
|
||
trunk group.
|
||
|
||
When ALL is used in the TerminationID of a command, the effect is
|
||
identical to repeating the command with each of the matching
|
||
TerminationIDs. The use of ALL does not address the ROOT
|
||
termination. Since each of these commands may generate a response,
|
||
the size of the entire response may be large. If individual
|
||
responses are not required, a wildcard response may be requested. In
|
||
such a case, a single response is generated, which contains the UNION
|
||
of all of the individual responses which otherwise would have been
|
||
generated, with duplicate values suppressed. For instance, given a
|
||
Termination Ta with properties p1=a, p2=b and Termination Tb with
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 21]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
properties p2=c, p3=d, a UNION response would consist of a wildcarded
|
||
TerminationId and the sequence of properties p1=a, p2=b,c and p3=d.
|
||
Wildcard response may be particularly useful in the Audit commands.
|
||
|
||
The encoding of the wildcarding mechanism is detailed in Annexes A
|
||
and B.
|
||
|
||
6.2.3 Packages
|
||
|
||
Different types of gateways may implement Terminations that have
|
||
widely differing characteristics. Variations in Terminations are
|
||
accommodated in the protocol by allowing Terminations to have
|
||
optional Properties, Events, Signals and Statistics implemented by
|
||
MGs.
|
||
|
||
In order to achieve MG/MGC interoperability, such options are grouped
|
||
into Packages, and typically a Termination realizes a set of such
|
||
Packages. More information on definition of packages can be found in
|
||
clause 12. An MGC can audit a Termination to determine which
|
||
Packages it realizes.
|
||
|
||
Properties, Events, Signals and Statistics defined in Packages, as
|
||
well as parameters to them, are referenced by identifiers (Ids).
|
||
Identifiers are scoped. For each package, PropertyIds, EventIds,
|
||
SignalIds, StatisticsIds and ParameterIds have unique name spaces and
|
||
the same identifier may be used in each of them. Two PropertyIds in
|
||
different packages may also have the same identifier, etc.
|
||
|
||
To support a particular package the MG must support all properties,
|
||
signals, events and statistics defined in a package. It must also
|
||
support all Signal and Event parameters. The MG may support a subset
|
||
of the values listed in a package for a particular Property or
|
||
Parameter.
|
||
|
||
When packages are extended, the properties, events, signals and
|
||
statistics defined in the base package can be referred to using
|
||
either the extended package name or the base package name. For
|
||
example, if Package A defines event e1, and Package B extends Package
|
||
A, then B/e1 is an event for a termination implementing Package B. By
|
||
definition, the MG MUST also implement the base Package, but it is
|
||
optional to publish the base package as an allowed interface. If it
|
||
does publish A, then A would be reported on the Package Descriptor
|
||
in AuditValue as well as B, and event A/e1 would be available on a
|
||
termination. If the MG does not publish A, then only B/e1 would be
|
||
available. If published through AuditValue, A/e1 and B/e1 are the
|
||
same event.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 22]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
For improved interoperability and backward compatibility, an MG MAY
|
||
publish all Packages supported by its Terminations, including base
|
||
Packages from which extended Packages are derived. An exception to
|
||
this is in cases where the base packages are expressly "Designed to
|
||
be extended only".
|
||
|
||
6.2.4 Termination properties and descriptors
|
||
|
||
Terminations have properties. The properties have unique
|
||
PropertyIDs. Most properties have default values, which are
|
||
explicitly defined in this protocol specification or in a package
|
||
(see clause 12) or set by provisioning. If not provisioned
|
||
otherwise, the properties in all descriptors except TerminationState
|
||
and LocalControl default to empty/"no value" when a Termination is
|
||
first created or returned to the null Context. The default contents
|
||
of the two exceptions are described in 7.1.5 and 7.1.7.
|
||
|
||
The provisioning of a property value in the MG will override any
|
||
default value, be it supplied in this protocol specification or in a
|
||
package. Therefore if it is essential for the MGC to have full
|
||
control over the property values of a Termination, it should supply
|
||
explicit values when ADDing the Termination to a Context.
|
||
Alternatively, for a physical Termination the MGC can determine any
|
||
provisioned property values by auditing the Termination while it is
|
||
in the NULL Context.
|
||
|
||
There are a number of common properties for Terminations and
|
||
properties specific to media streams. The common properties are also
|
||
called the Termination state properties. For each media stream,
|
||
there are local properties and properties of the received and
|
||
transmitted flows.
|
||
|
||
Properties not included in the base protocol are defined in Packages.
|
||
These properties are referred to by a name consisting of the
|
||
PackageName and a PropertyId. Most properties have default values
|
||
described in the Package description. Properties may be read-only or
|
||
read/write. The possible values of a property may be audited, as can
|
||
their current values. For properties that are read/write, the MGC
|
||
can set their values. A property may be declared as "Global" which
|
||
has a single value shared by all Terminations realizing the package.
|
||
Related properties are grouped into descriptors for convenience.
|
||
|
||
When a Termination is added to a Context, the value of its read/write
|
||
properties can be set by including the appropriate descriptors as
|
||
parameters to the Add command. Similarly, a property of a
|
||
Termination in a Context may have its value changed by the Modify
|
||
command.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 23]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Properties may also have their values changed when a Termination is
|
||
moved from one Context to another as a result of a Move command. In
|
||
some cases, descriptors are returned as output from a command.
|
||
|
||
In general, if a Descriptor is completely omitted from one of the
|
||
aforementioned Commands, the properties in that Descriptor retain
|
||
their prior values for the Termination(s) upon which the Command
|
||
acts. On the other hand, if some read/write properties are omitted
|
||
from a Descriptor in a Command (i.e., the Descriptor is only
|
||
partially specified), those properties will be reset to their default
|
||
values for the Termination(s) upon which the Command acts, unless the
|
||
package specifies other behavior. For more details, see clause 7.1
|
||
dealing with the individual Descriptors.
|
||
|
||
The following table lists all of the possible descriptors and their
|
||
use. Not all descriptors are legal as input or output parameters to
|
||
every command.
|
||
|
||
Descriptor name Description
|
||
|
||
Modem Identifies modem type and properties when
|
||
applicable
|
||
|
||
Mux Describes multiplex type for multimedia
|
||
Terminations (e.g., H.221, H.223, H.225.0) and
|
||
Terminations forming the input mux
|
||
|
||
Media A list of media stream specifications (see 7.1.4)
|
||
|
||
TerminationState Properties of a Termination (which can be defined
|
||
in Packages) that are not stream specific
|
||
|
||
Stream A list of remote/local/localControl descriptors for
|
||
a single stream
|
||
|
||
Local Contains properties that specify the media flows
|
||
that the MG receives from the remote entity.
|
||
|
||
Remote Contains properties that specify the media flows
|
||
that the MG sends to the remote entity.
|
||
|
||
LocalControl Contains properties (which can be defined in
|
||
packages) that are of interest between the MG and
|
||
the MGC.
|
||
|
||
Events Describes events to be detected by the MG and what
|
||
to do when an event is detected.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 24]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
EventBuffer Describes events to be detected by the MG when
|
||
Event Buffering is active.
|
||
|
||
Signals Describes signals (see 7.1.11) applied to
|
||
Terminations.
|
||
|
||
Audit In Audit commands, identifies which information is
|
||
desired.
|
||
|
||
Packages In AuditValue, returns a list of Packages realized
|
||
by Termination.
|
||
|
||
DigitMap Defines patterns against which sequences of a
|
||
specified set of events are to be matched so they
|
||
can be reported as a group rather than singly.
|
||
|
||
ServiceChange In ServiceChange, what, why service change
|
||
occurred, etc.
|
||
|
||
ObservedEvents In Notify or AuditValue, report of events observed.
|
||
|
||
Statistics In Subtract and Audit, report of Statistics kept on
|
||
a Termination.
|
||
|
||
Topology Specifies flow directions between Terminations in a
|
||
Context.
|
||
|
||
Error Contains an error code and optionally error text;
|
||
it may occur in command replies and in Notify
|
||
requests.
|
||
|
||
6.2.5 Root Termination
|
||
|
||
Occasionally, a command must refer to the entire gateway, rather than
|
||
a Termination within it. A special TerminationID, "Root" is reserved
|
||
for this purpose. Packages may be defined on Root. Root thus may
|
||
have properties, events and statistics (signals are not appropriate
|
||
for root). Accordingly, the root TerminationID may appear in:
|
||
|
||
- a Modify command - to change a property or set an event
|
||
|
||
- a Notify command - to report an event
|
||
|
||
- an AuditValue return - to examine the values of properties and
|
||
statistics implemented on root
|
||
|
||
- an AuditCapability - to determine what properties of root are
|
||
implemented
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 25]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- a ServiceChange - to declare the gateway in or out of service.
|
||
|
||
Any other use of the root TerminationID is an error. Error code
|
||
410 - Incorrect identifier shall be returned in these cases.
|
||
|
||
7 Commands
|
||
|
||
The protocol provides commands for manipulating the logical entities
|
||
of the protocol connection model, Contexts and Terminations.
|
||
Commands provide control at the finest level of granularity supported
|
||
by the protocol. For example, Commands exist to add Terminations to
|
||
a Context, modify Terminations, subtract Terminations from a Context,
|
||
and audit properties of Contexts or Terminations. Commands provide
|
||
for complete control of the properties of Contexts and Terminations.
|
||
This includes specifying which events a Termination is to report,
|
||
which signals/actions are to be applied to a Termination and
|
||
specifying the topology of a Context (who hears/sees whom).
|
||
|
||
Most commands are for the specific use of the Media Gateway
|
||
Controller as command initiator in controlling Media Gateways as
|
||
command responders. The exceptions are the Notify and ServiceChange
|
||
commands: Notify is sent from Media Gateway to Media Gateway
|
||
Controller, and ServiceChange may be sent by either entity. Below is
|
||
an overview of the commands; they are explained in more detail in
|
||
7.2.
|
||
|
||
1) Add - The Add command adds a Termination to a Context. The Add
|
||
command on the first Termination in a Context is used to create a
|
||
Context.
|
||
|
||
2) Modify - The Modify command modifies the properties, events and
|
||
signals of a Termination.
|
||
|
||
3) Subtract - The Subtract command disconnects a Termination from its
|
||
Context and returns statistics on the Termination's participation
|
||
in the Context. The Subtract command on the last Termination in a
|
||
Context deletes the Context.
|
||
|
||
4) Move - The Move command atomically moves a Termination to another
|
||
Context.
|
||
|
||
5) AuditValue - The AuditValue command returns the current state of
|
||
properties, events, signals and statistics of Terminations.
|
||
|
||
6) AuditCapabilities - The AuditCapabilities command returns all the
|
||
possible values for Termination properties, events and signals
|
||
allowed by the Media Gateway.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 26]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7) Notify - The Notify command allows the Media Gateway to inform the
|
||
Media Gateway Controller of the occurrence of events in the Media
|
||
Gateway.
|
||
|
||
8) ServiceChange - The ServiceChange command allows the Media Gateway
|
||
to notify the Media Gateway Controller that a Termination or group
|
||
of Terminations is about to be taken out of service or has just
|
||
been returned to service. ServiceChange is also used by the MG to
|
||
announce its availability to a MGC (registration), and to notify
|
||
the MGC of impending or completed restart of the MG. The MGC may
|
||
announce a handover to the MG by sending it a ServiceChange
|
||
command. The MGC may also use ServiceChange to instruct the MG to
|
||
take a Termination or group of Terminations in or out of service.
|
||
|
||
These commands are detailed in 7.2.1 through 7.2.8.
|
||
|
||
7.1 Descriptors
|
||
|
||
The parameters to a command are termed Descriptors. A descriptor
|
||
consists of a name and a list of items. Some items may have values.
|
||
Many Commands share common descriptors. This subclause enumerates
|
||
these descriptors. Descriptors may be returned as output from a
|
||
command. In any such return of descriptor contents, an empty
|
||
descriptor is represented by its name unaccompanied by any list.
|
||
Parameters and parameter usage specific to a given Command type are
|
||
described in the subclause that describes the Command.
|
||
|
||
7.1.1 Specifying parameters
|
||
|
||
Command parameters are structured into a number of descriptors. In
|
||
general, the text format of descriptors is
|
||
DescriptorName=<someID>{parm=value, parm=value, ...}.
|
||
|
||
Parameters may be fully specified, overspecified or underspecified:
|
||
|
||
1) Fully specified parameters have a single, unambiguous value that
|
||
the command initiator is instructing the command responder to use
|
||
for the specified parameter.
|
||
|
||
2) Underspecified parameters, using the CHOOSE value, allow the
|
||
command responder to choose any value it can support.
|
||
|
||
3) Overspecified parameters have a list of potential values. The
|
||
list order specifies the command initiator's order of preference
|
||
of selection. The command responder chooses one value from
|
||
the offered list and returns that value to the command initiator.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 27]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
If a required descriptor other than the Audit descriptor is
|
||
unspecified (i.e., entirely absent) from a command, the previous
|
||
values set in that descriptor for that Termination, if any, are
|
||
retained. In commands other than Subtract, a missing Audit
|
||
descriptor is equivalent to an empty Audit descriptor. The Behaviour
|
||
of the MG with respect to unspecified parameters within a descriptor
|
||
varies with the descriptor concerned, as indicated in succeeding
|
||
subclauses. Whenever a parameter is underspecified or overspecified,
|
||
the descriptor containing the value chosen by the responder is
|
||
included as output from the command.
|
||
|
||
Each command specifies the TerminationId the command operates on.
|
||
This TerminationId may be "wildcarded". When the TerminationId of a
|
||
command is wildcarded, the effect shall be as if the command was
|
||
repeated with each of the TerminationIds matched.
|
||
|
||
7.1.2 Modem descriptor
|
||
|
||
The Modem descriptor specifies the modem type and parameters, if any,
|
||
required for use in e.g., H.324 and text conversation. The
|
||
descriptor includes the following modem types: V.18, V.22, V.22 bis,
|
||
V.32, V.32 bis, V.34, V.90, V.91, Synchronous ISDN, and allows for
|
||
extensions. By default, no Modem descriptor is present in a
|
||
Termination.
|
||
|
||
7.1.3 Multiplex descriptor
|
||
|
||
In multimedia calls, a number of media streams are carried on a
|
||
(possibly different) number of bearers. The multiplex descriptor
|
||
associates the media and the bearers. The descriptor includes the
|
||
multiplex type:
|
||
|
||
- H.221;
|
||
|
||
- H.223;
|
||
|
||
- H.226;
|
||
|
||
- V.76;
|
||
|
||
- possible extensions,
|
||
|
||
and a set of TerminationIDs representing the multiplexed bearers, in
|
||
order. For example:
|
||
|
||
Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 28]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.1.4 Media descriptor
|
||
|
||
The Media descriptor specifies the parameters for all the media
|
||
streams. These parameters are structured into two descriptors: a
|
||
TerminationState descriptor, which specifies the properties of a
|
||
Termination that are not stream dependent, and one or more Stream
|
||
descriptors each of which describes a single media stream.
|
||
|
||
A stream is identified by a StreamID. The StreamID is used to link
|
||
the streams in a Context that belong together. Multiple streams
|
||
exiting a Termination shall be synchronized with each other. Within
|
||
the Stream descriptor, there are up to three subsidiary descriptors:
|
||
LocalControl, Local, and Remote. The relationship between these
|
||
descriptors is thus:
|
||
|
||
Media descriptor
|
||
TerminationState Descriptor
|
||
Stream descriptor
|
||
LocalControl descriptor
|
||
Local descriptor
|
||
Remote descriptor
|
||
|
||
As a convenience, LocalControl, Local, or Remote descriptors may be
|
||
included in the Media descriptor without an enclosing Stream
|
||
descriptor. In this case, the StreamID is assumed to be 1.
|
||
|
||
7.1.5 TerminationState descriptor
|
||
|
||
The TerminationState descriptor contains the ServiceStates property,
|
||
the EventBufferControl property and properties of a Termination
|
||
(defined in Packages) that are not stream specific.
|
||
|
||
The ServiceStates property describes the overall state of the
|
||
Termination (not stream specific). A Termination can be in one of
|
||
the following states: "test", "out of service", or "in service". The
|
||
"test" state indicates that the Termination is being tested. The
|
||
state "out of service" indicates that the Termination cannot be used
|
||
for traffic. The state "in service" indicates that a Termination can
|
||
be used or is being used for normal traffic. "in service" is the
|
||
default state.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 29]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Values assigned to Properties may be simple values
|
||
(integer/string/enumeration) or may be underspecified, where more
|
||
than one value is supplied and the MG may make a choice:
|
||
|
||
- Alternative Values - multiple values in a list, one of which must
|
||
be selected
|
||
|
||
- Ranges - minimum and maximum values, any value between min and max
|
||
must be selected, boundary values included
|
||
|
||
- Greater Than/Less Than - value must be greater/less than specified
|
||
value
|
||
|
||
- CHOOSE Wildcard - the MG chooses from the allowed values for the
|
||
property
|
||
|
||
The EventBufferControl property specifies whether events are buffered
|
||
following detection of an event in the Events descriptor, or
|
||
processed immediately. See 7.1.9 for details.
|
||
|
||
7.1.6 Stream descriptor
|
||
|
||
A Stream descriptor specifies the parameters of a single
|
||
bidirectional stream. These parameters are structured into three
|
||
descriptors: one that contains Termination properties specific to a
|
||
stream and one each for local and remote flows. The Stream
|
||
Descriptor includes a StreamID which identifies the stream. Streams
|
||
are created by specifying a new StreamID on one of the Terminations
|
||
in a Context. A stream is deleted by setting empty Local and Remote
|
||
descriptors for the stream with ReserveGroup and ReserveValue in
|
||
LocalControl set to "false" on all Terminations in the Context that
|
||
previously supported that stream.
|
||
|
||
StreamIDs are of local significance between MGC and MG and they are
|
||
assigned by the MGC. Within a Context, StreamID is a means by which
|
||
to indicate which media flows are interconnected: streams with the
|
||
same StreamID are connected.
|
||
|
||
If a Termination is moved from one Context to another, the effect on
|
||
the Context to which the Termination is moved is the same as in the
|
||
case that a new Termination were added with the same StreamIDs as the
|
||
moved Termination.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 30]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.1.7 LocalControl descriptor
|
||
|
||
The LocalControl descriptor contains the Mode property, the
|
||
ReserveGroup and ReserveValue properties and properties of a
|
||
Termination (defined in Packages) that are stream specific, and are
|
||
of interest between the MG and the MGC. Values of properties may be
|
||
underspecified as in 7.1.1.
|
||
|
||
The allowed values for the mode property are send-only, receive-only,
|
||
send/receive, inactive and loop-back. "Send" and "receive" are with
|
||
respect to the exterior of the Context, so that, for example, a
|
||
stream set to mode=sendOnly does not pass received media into the
|
||
Context. The default value for the mode property is "Inactive".
|
||
Signals and Events are not affected by mode.
|
||
|
||
The boolean-valued Reserve properties, ReserveValue and ReserveGroup,
|
||
of a Termination indicate what the MG is expected to do when it
|
||
receives a Local and/or Remote descriptor.
|
||
|
||
If the value of a Reserve property is True, the MG SHALL reserve
|
||
resources for all alternatives specified in the Local and/or Remote
|
||
descriptors for which it currently has resources available. It SHALL
|
||
respond with the alternatives for which it reserves resources. If it
|
||
cannot not support any of the alternatives, it SHALL respond with a
|
||
reply to the MGC that contains empty Local and/or Remote descriptors.
|
||
If media begins to flow while more than a single alternative is
|
||
reserved, media packets may be sent/received on any of the
|
||
alternatives and must be processed, although only a single
|
||
alternative may be active at any given time.
|
||
|
||
If the value of a Reserve property is False, the MG SHALL choose one
|
||
of the alternatives specified in the Local descriptor (if present)
|
||
and one of the alternatives specified in the Remote descriptor (if
|
||
present). If the MG has not yet reserved resources to support the
|
||
selected alternative, it SHALL reserve the resources. If, on the
|
||
other hand, it already reserved resources for the Termination
|
||
addressed (because of a prior exchange with ReserveValue and/or
|
||
ReserveGroup equal to True), it SHALL release any excess resources it
|
||
reserved previously. Finally, the MG shall send a reply to the MGC
|
||
containing the alternatives for the Local and/or Remote descriptor
|
||
that it selected. If the MG does not have sufficient resources to
|
||
support any of the alternatives specified, it SHALL respond with
|
||
error 510 (insufficient resources).
|
||
|
||
The default value of ReserveValue and ReserveGroup is False. More
|
||
information on the use of the two Reserve properties is provided in
|
||
7.1.8.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 31]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A new setting of the LocalControl Descriptor completely replaces the
|
||
previous setting of that descriptor in the MG. Thus, to retain
|
||
information from the previous setting, the MGC must include that
|
||
information in the new setting. If the MGC wishes to delete some
|
||
information from the existing descriptor, it merely resends the
|
||
descriptor (in a Modify command) with the unwanted information
|
||
stripped out.
|
||
|
||
7.1.8 Local and Remote descriptors
|
||
|
||
The MGC uses Local and Remote descriptors to reserve and commit MG
|
||
resources for media decoding and encoding for the given Stream(s) and
|
||
Termination to which they apply. The MG includes these descriptors
|
||
in its response to indicate what it is actually prepared to support.
|
||
The MG SHALL include additional properties and their values in its
|
||
response if these properties are mandatory yet not present in the
|
||
requests made by the MGC (e.g., by specifying detailed video encoding
|
||
parameters where the MGC only specified the payload type).
|
||
|
||
Local refers to the media received by the MG and Remote refers to the
|
||
media sent by the MG.
|
||
|
||
When text encoding the protocol, the descriptors consist of session
|
||
descriptions as defined in SDP (RFC 2327). In session descriptions
|
||
sent from the MGC to the MG, the following exceptions to the syntax
|
||
of RFC 2327 are allowed:
|
||
|
||
- the "s=", "t=" and "o=" lines are optional;
|
||
|
||
- the use of CHOOSE is allowed in place of a single parameter value;
|
||
and
|
||
|
||
- the use of alternatives is allowed in place of a single parameter
|
||
value.
|
||
|
||
A Stream Descriptor specifies a single bi-directional media stream
|
||
and so a single session description MUST NOT include more than one
|
||
media description ("m=" line). A Stream Descriptor may contain
|
||
additional session descriptions as alternatives. Each media stream
|
||
for a termination must appear in distinct Stream Descriptors. When
|
||
multiple session descriptions are provided in one descriptor, the
|
||
"v=" lines are required as delimiters; otherwise they are optional in
|
||
session descriptions sent to the MG. Implementations shall accept
|
||
session descriptions that are fully conformant to RFC 2327. When
|
||
binary encoding the protocol the descriptor consists of groups of
|
||
properties (tag-value pairs) as specified in Annex C. Each such
|
||
group may contain the parameters of a session description.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 32]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Below, the semantics of the Local and Remote descriptors are
|
||
specified in detail. The specification consists of two parts. The
|
||
first part specifies the interpretation of the contents of the
|
||
descriptor. The second part specifies the actions the MG must take
|
||
upon receiving the Local and Remote descriptors. The actions to be
|
||
taken by the MG depend on the values of the ReserveValue and
|
||
ReserveGroup properties of the LocalControl descriptor.
|
||
|
||
Either the Local or the Remote descriptor or both may be:
|
||
|
||
1) unspecified (i.e., absent);
|
||
|
||
2) empty;
|
||
|
||
3) underspecified through use of CHOOSE in a property value;
|
||
|
||
4) fully specified; or
|
||
|
||
5) overspecified through presentation of multiple groups of
|
||
properties and possibly multiple property values in one or more of
|
||
these groups.
|
||
|
||
Where the descriptors have been passed from the MGC to the MG, they
|
||
are interpreted according to the rules given in 7.1.1, with the
|
||
following additional comments for clarification:
|
||
|
||
a) An unspecified Local or Remote descriptor is considered to be a
|
||
missing mandatory parameter. It requires the MG to use whatever
|
||
was last specified for that descriptor. It is possible that there
|
||
was no previously specified value, in which case the descriptor
|
||
concerned is ignored in further processing of the command.
|
||
|
||
b) An empty Local (Remote) descriptor in a message from the MGC
|
||
signifies a request to release any resources reserved for the
|
||
media flow received (sent).
|
||
|
||
c) If multiple groups of properties are present in a Local or Remote
|
||
descriptor or multiple values within a group, the order of
|
||
preference is descending.
|
||
|
||
d) Underspecified or overspecified properties within a group of
|
||
properties sent by the MGC are requests for the MG to choose one
|
||
or more values which it can support for each of those properties.
|
||
In case of an overspecified property, the list of values is in
|
||
descending order of preference.
|
||
|
||
Subject to the above rules, subsequent action depends on the values
|
||
of the ReserveValue and ReserveGroup properties in LocalControl.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 33]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
If ReserveGroup is True, the MG reserves the resources required to
|
||
support any of the requested property group alternatives that it can
|
||
currently support. If ReserveValue is True, the MG reserves the
|
||
resources required to support any of the requested property value
|
||
alternatives that it can currently support.
|
||
|
||
NOTE - If a Local or Remote descriptor contains multiple groups of
|
||
properties, and ReserveGroup is True, then the MG is requested to
|
||
reserve resources so that it can decode or encode the media stream
|
||
according to any of the alternatives. For instance, if the Local
|
||
descriptor contains two groups of properties, one specifying
|
||
packetized G.711 A-law audio and the other G.723.1 audio, the MG
|
||
reserves resources so that it can decode one audio stream encoded in
|
||
either G.711 A-law format or G.723.1 format. The MG does not have to
|
||
reserve resources to decode two audio streams simultaneously, one
|
||
encoded in G.711 A-law and one in G.723.1. The intention for the use
|
||
of ReserveValue is analogous.
|
||
|
||
If ReserveGroup is true or ReserveValue is True, then the following
|
||
rules apply:
|
||
|
||
- If the MG has insufficient resources to support all alternatives
|
||
requested by the MGC and the MGC requested resources in both Local
|
||
and Remote, the MG should reserve resources to support at least
|
||
one alternative each within Local and Remote.
|
||
|
||
- If the MG has insufficient resources to support at least one
|
||
alternative within a Local (Remote) descriptor received from the
|
||
MGC, it shall return an empty Local (Remote) in response.
|
||
|
||
- In its response to the MGC, when the MGC included Local and Remote
|
||
descriptors, the MG SHALL include Local and Remote descriptors for
|
||
all groups of properties and property values it reserved resources
|
||
for. If the MG is incapable of supporting at least one of the
|
||
alternatives within the Local (Remote) descriptor received from
|
||
the MGC, it SHALL return an empty Local (Remote) descriptor.
|
||
|
||
- If the Mode property of the LocalControl descriptor is RecvOnly,
|
||
SendRecv, or LoopBack, the MG must be prepared to receive media
|
||
encoded according to any of the alternatives included in its
|
||
response to the MGC.
|
||
|
||
If ReserveGroup is False and ReserveValue is False, then the MG
|
||
SHOULD apply the following rules to resolve Local and Remote to a
|
||
single alternative each:
|
||
|
||
- The MG chooses the first alternative in Local for which it is able
|
||
to support at least one alternative in Remote.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 34]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- If the MG is unable to support at least one Local and one Remote
|
||
alternative, it returns Error 510 (Insufficient Resources).
|
||
|
||
- The MG returns its selected alternative in each of Local and
|
||
Remote.
|
||
|
||
A new setting of a Local or Remote descriptor completely replaces the
|
||
previous setting of that descriptor in the MG. Thus, to retain
|
||
information from the previous setting, the MGC must include that
|
||
information in the new setting. If the MGC wishes to delete some
|
||
information from the existing descriptor, it merely resends the
|
||
descriptor (in a Modify command) with the unwanted information
|
||
stripped out.
|
||
|
||
7.1.9 Events descriptor
|
||
|
||
The EventsDescriptor parameter contains a RequestIdentifier and a
|
||
list of events that the Media Gateway is requested to detect and
|
||
report. The RequestIdentifier is used to correlate the request with
|
||
the notifications that it may trigger. Requested events include, for
|
||
example, fax tones, continuity test results, and on-hook and off-hook
|
||
transitions. The RequestIdentifier is omitted if the
|
||
EventsDescriptor is empty (i.e., no events are specified).
|
||
|
||
Each event in the descriptor contains the Event name, an optional
|
||
streamID, an optional KeepActive flag, and optional parameters. The
|
||
Event name consists of a Package Name (where the event is defined)
|
||
and an EventID. The ALL wildcard may be used for the EventID,
|
||
indicating that all events from the specified package have to be
|
||
detected. The default streamID is 0, indicating that the event to be
|
||
detected is not related to a particular media stream. Events can
|
||
have parameters. This allows a single event description to have some
|
||
variation in meaning without creating large numbers of individual
|
||
events. Further event parameters are defined in the package.
|
||
|
||
If a digit map completion event is present or implied in the
|
||
EventsDescriptor, the EventDM parameter is used to carry either the
|
||
name or the value of the associated digit map. See 7.1.14 for
|
||
further details.
|
||
|
||
When an event is processed against the contents of an active Events
|
||
Descriptor and found to be present in that descriptor ("recognized"),
|
||
the default action of the MG is to send a Notify command to the MGC.
|
||
Notification may be deferred if the event is absorbed into the
|
||
current dial string of an active digit map (see 7.1.14). Any other
|
||
action is for further study. Moreover, event recognition may cause
|
||
currently active signals to stop, or may cause the current Events
|
||
and/or Signals descriptor to be replaced, as described at the end of
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 35]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
this subclause. Unless the Events Descriptor is replaced by another
|
||
Events Descriptor, it remains active after an event has been
|
||
recognized.
|
||
|
||
If the value of the EventBufferControl property equals LockStep,
|
||
following detection of such an event, normal handling of events is
|
||
suspended. Any event which is subsequently detected and occurs in
|
||
the EventBuffer descriptor is added to the end of the EventBuffer (a
|
||
FIFO queue), along with the time that it was detected. The MG SHALL
|
||
wait for a new EventsDescriptor to be loaded. A new EventsDescriptor
|
||
can be loaded either as the result of receiving a command with a new
|
||
EventsDescriptor, or by activating an embedded EventsDescriptor.
|
||
|
||
If EventBufferControl equals Off, the MG continues processing based
|
||
on the active EventsDescriptor.
|
||
|
||
In the case of an embedded EventsDescriptor being activated, the MG
|
||
continues event processing based on the newly activated
|
||
EventsDescriptor.
|
||
|
||
NOTE 1 - For purposes of EventBuffer handling, activation of an
|
||
embedded EventsDescriptor is equivalent to receipt of a new
|
||
EventsDescriptor.
|
||
|
||
When the MG receives a command with a new EventsDescriptor, one or
|
||
more events may have been buffered in the EventBuffer in the MG. The
|
||
value of EventBufferControl then determines how the MG treats such
|
||
buffered events.
|
||
|
||
Case 1
|
||
|
||
If EventBufferControl equals LockStep and the MG receives a new
|
||
EventsDescriptor, it will check the FIFO EventBuffer and take the
|
||
following actions:
|
||
|
||
1) If the EventBuffer is empty, the MG waits for detection of events
|
||
based on the new EventsDescriptor.
|
||
|
||
2) If the EventBuffer is non-empty, the MG processes the FIFO queue
|
||
starting with the first event:
|
||
|
||
a) If the event in the queue is in the events listed in the new
|
||
EventsDescriptor, the MG acts on the event and removes the
|
||
event from the EventBuffer. The time stamp of the Notify shall
|
||
be the time the event was actually detected. The MG then waits
|
||
for a new EventsDescriptor. While waiting for a new
|
||
EventsDescriptor, any events detected that appear in the
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 36]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
EventsBufferDescriptor will be placed in the EventBuffer. When
|
||
a new EventsDescriptor is received, the event processing will
|
||
repeat from step 1.
|
||
|
||
b) If the event is not in the new EventsDescriptor, the MG SHALL
|
||
discard the event and repeat from step 1.
|
||
|
||
Case 2
|
||
|
||
If EventBufferControl equals Off and the MG receives a new
|
||
EventsDescriptor, it processes new events with the new
|
||
EventsDescriptor.
|
||
|
||
If the MG receives a command instructing it to set the value of
|
||
EventBufferControl to Off, all events in the EventBuffer SHALL be
|
||
discarded.
|
||
|
||
The MG may report several events in a single Transaction as long as
|
||
this does not unnecessarily delay the reporting of individual events.
|
||
|
||
For procedures regarding transmitting the Notify command, refer to
|
||
the appropriate annex or Recommendation of the H.248 sub-series for
|
||
specific transport considerations.
|
||
|
||
The default value of EventBufferControl is Off.
|
||
|
||
NOTE 2 - Since the EventBufferControl property is in the
|
||
TerminationStateDescriptor, the MG might receive a command that
|
||
changes the EventBufferControl property and does not include an
|
||
EventsDescriptor.
|
||
|
||
Normally, recognition of an event shall cause any active signals to
|
||
stop. When KeepActive is specified in the event, the MG shall not
|
||
interrupt any signals active on the Termination on which the event is
|
||
detected.
|
||
|
||
An event can include an Embedded Signals descriptor and/or an
|
||
Embedded Events descriptor which, if present, replaces the current
|
||
Signals/Events descriptor when the event is recognized. It is
|
||
possible, for example, to specify that the dial-tone Signal be
|
||
generated when an off-hook Event is recognized, or that the dial-tone
|
||
Signal be stopped when a digit is recognized. A media gateway
|
||
controller shall not send EventsDescriptors with an event both marked
|
||
KeepActive and containing an embedded SignalsDescriptor.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 37]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Only one level of embedding is permitted. An embedded
|
||
EventsDescriptor SHALL NOT contain another embedded EventsDescriptor;
|
||
an embedded EventsDescriptor MAY contain an embedded
|
||
SignalsDescriptor.
|
||
|
||
An EventsDescriptor received by a media gateway replaces any previous
|
||
Events descriptor. Event notification in process shall complete, and
|
||
events detected after the command containing the new EventsDescriptor
|
||
executes, shall be processed according to the new EventsDescriptor.
|
||
|
||
An empty Events Descriptor disables all event recognition and
|
||
reporting. An empty EventBuffer Descriptor clears the EventBuffer
|
||
and disables all event accumulation in LockStep mode: the only events
|
||
reported will be those occurring while an Events Descriptor is
|
||
active. If an empty Events Descriptor is activated while the
|
||
Termination is operating in LockStep mode, the events buffer is
|
||
immediately cleared.
|
||
|
||
7.1.10 EventBuffer descriptor
|
||
|
||
The EventBuffer descriptor contains a list of events, with their
|
||
parameters if any, that the MG is requested to detect and buffer when
|
||
EventBufferControl equals LockStep (see 7.1.9).
|
||
|
||
7.1.11 Signals descriptor
|
||
|
||
Signals are MG generated media such as tones and announcements as
|
||
well as bearer-related signals such as hookswitch. More complex
|
||
signals may include a sequence of such simple signals interspersed
|
||
with and conditioned upon the receipt and analysis of media or
|
||
bearer-related signals. Examples include echoing of received data as
|
||
in Continuity Test package. Signals may also request preparation of
|
||
media content for future signals.
|
||
|
||
A SignalsDescriptor is a parameter that contains the set of signals
|
||
that the Media Gateway is asked to apply to a Termination. A
|
||
SignalsDescriptor contains a number of signals and/or sequential
|
||
signal lists. A SignalsDescriptor may contain zero signals and
|
||
sequential signal lists. Support of sequential signal lists is
|
||
optional.
|
||
|
||
Signals are defined in packages. Signals shall be named with a
|
||
Package name (in which the signal is defined) and a SignalID. No
|
||
wildcard shall be used in the SignalID. Signals that occur in a
|
||
SignalsDescriptor have an optional StreamID parameter (default is 0,
|
||
to indicate that the signal is not related to a particular media
|
||
stream), an optional signal type (see below), an optional duration
|
||
and possibly parameters defined in the package that defines the
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 38]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
signal. This allows a single signal to have some variation in
|
||
meaning, obviating the need to create large numbers of individual
|
||
signals.
|
||
|
||
Finally, the optional parameter "notifyCompletion" allows a MGC to
|
||
indicate that it wishes to be notified when the signal finishes
|
||
playout. The possible cases are that the signal timed out (or
|
||
otherwise completed on its own), that it was interrupted by an event,
|
||
that it was halted when a Signals descriptor was replaced, or that it
|
||
stopped or never started for other reasons. If the notifyCompletion
|
||
parameter is not included in a Signals descriptor, notification is
|
||
generated only if the signal stopped or was never started for other
|
||
reasons. For reporting to occur, the signal completion event (see
|
||
E.1.2) must be enabled in the currently active Events descriptor.
|
||
|
||
The duration is an integer value that is expressed in hundredths of a
|
||
second.
|
||
|
||
There are three types of signals:
|
||
|
||
- on/off - the signal lasts until it is turned off;
|
||
|
||
- timeout - the signal lasts until it is turned off or a specific
|
||
period of time elapses;
|
||
|
||
- brief - the signal will stop on its own unless a new Signals
|
||
descriptor is applied that causes it to stop; no timeout value is
|
||
needed.
|
||
|
||
If a signal of default type other than TO has its type overridden to
|
||
type TO in the Signals descriptor, the duration parameter must be
|
||
present.
|
||
|
||
If the signal type is specified in a SignalsDescriptor, it overrides
|
||
the default signal type (see 12.1.4). If duration is specified for
|
||
an on/off signal, it SHALL be ignored.
|
||
|
||
A sequential signal list consists of a signal list identifier and a
|
||
sequence of signals to be played sequentially. Only the trailing
|
||
element of the sequence of signals in a sequential signal list may be
|
||
an on/off signal. The duration of a sequential signal list is the
|
||
sum of the durations of the signals it contains.
|
||
|
||
Multiple signals and sequential signal lists in the same
|
||
SignalsDescriptor shall be played simultaneously.
|
||
|
||
Signals are defined as proceeding from the Termination towards the
|
||
exterior of the Context unless otherwise specified in a package.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 39]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
When the same Signal is applied to multiple Terminations within one
|
||
Transaction, the MG should consider using the same resource to
|
||
generate these Signals.
|
||
|
||
Production of a Signal on a Termination is stopped by application of
|
||
a new SignalsDescriptor, or detection of an Event on the Termination
|
||
(see 7.1.9).
|
||
|
||
A new SignalsDescriptor replaces any existing SignalsDescriptor. Any
|
||
signals applied to the Termination not in the replacement descriptor
|
||
shall be stopped, and new signals are applied, except as follows.
|
||
Signals present in the replacement descriptor and containing the
|
||
KeepActive flag shall be continued if they are currently playing and
|
||
have not already completed. If a replacement signal descriptor
|
||
contains a signal that is not currently playing and contains the
|
||
KeepActive flag, that signal SHALL be ignored. If the replacement
|
||
descriptor contains a sequential signal list with the same identifier
|
||
as the existing descriptor, then
|
||
|
||
- the signal type and sequence of signals in the sequential signal
|
||
list in the replacement descriptor shall be ignored; and
|
||
|
||
- the playing of the signals in the sequential signal list in the
|
||
existing descriptor shall not be interrupted.
|
||
|
||
7.1.12 Audit descriptor
|
||
|
||
The Audit descriptor specifies what information is to be audited.
|
||
The Audit descriptor specifies the list of descriptors to be
|
||
returned. Audit may be used in any command to force the return of
|
||
any descriptor containing the current values of its properties,
|
||
events, signals and statistics even if that descriptor was not
|
||
present in the command, or had no underspecified parameters.
|
||
Possible items in the Audit descriptor are:
|
||
|
||
Modem
|
||
Mux
|
||
Events
|
||
Media
|
||
Signals
|
||
ObservedEvents
|
||
DigitMap
|
||
Statistics
|
||
Packages
|
||
EventBuffer
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 40]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Audit may be empty, in which case, no descriptors are returned. This
|
||
is useful in Subtract, to inhibit return of statistics, especially
|
||
when using wildcard.
|
||
|
||
7.1.13 ServiceChange descriptor
|
||
|
||
The ServiceChangeDescriptor contains the following parameters:
|
||
|
||
. ServiceChangeMethod
|
||
. ServiceChangeReason
|
||
. ServiceChangeAddress
|
||
. ServiceChangeDelay
|
||
. ServiceChangeProfile
|
||
. ServiceChangeVersion
|
||
. ServiceChangeMGCId
|
||
. TimeStamp
|
||
. Extension
|
||
|
||
See 7.2.8.
|
||
|
||
7.1.14 DigitMap descriptor
|
||
|
||
7.1.14.1 DigitMap definition, creation, modification and deletion
|
||
|
||
A DigitMap is a dialing plan resident in the Media Gateway used for
|
||
detecting and reporting digit events received on a Termination. The
|
||
DigitMap descriptor contains a DigitMap name and the DigitMap to be
|
||
assigned. A digit map may be preloaded into the MG by management
|
||
action and referenced by name in an EventsDescriptor, may be defined
|
||
dynamically and subsequently referenced by name, or the actual
|
||
digitmap itself may be specified in the EventsDescriptor. It is
|
||
permissible for a digit map completion event within an Events
|
||
descriptor to refer by name to a DigitMap which is defined by a
|
||
DigitMap descriptor within the same command, regardless of the
|
||
transmitted order of the respective descriptors.
|
||
|
||
DigitMaps defined in a DigitMapDescriptor can occur in any of the
|
||
standard Termination manipulation Commands of the protocol. A
|
||
DigitMap, once defined, can be used on all Terminations specified by
|
||
the (possibly wildcarded) TerminationID in such a command. DigitMaps
|
||
defined on the root Termination are global and can be used on every
|
||
Termination in the MG, provided that a DigitMap with the same name
|
||
has not been defined on the given Termination. When a DigitMap is
|
||
defined dynamically in a DigitMap descriptor:
|
||
|
||
- A new DigitMap is created by specifying a name that is not yet
|
||
defined. The value shall be present.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 41]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- A DigitMap value is updated by supplying a new value for a name
|
||
that is already defined. Terminations presently using the
|
||
digitmap shall continue to use the old definition; subsequent
|
||
EventsDescriptors specifying the name, including any
|
||
EventsDescriptor in the command containing the DigitMap
|
||
descriptor, shall use the new one.
|
||
|
||
- A DigitMap is deleted by supplying an empty value for a name that
|
||
is already defined. Terminations presently using the digitmap
|
||
shall continue to use the old definition.
|
||
|
||
7.1.14.2 DigitMap Timers
|
||
|
||
The collection of digits according to a DigitMap may be protected by
|
||
three timers, viz. a start timer (T), short timer (S), and long timer
|
||
(L).
|
||
|
||
1) The start timer (T) is used prior to any digits having been
|
||
dialed. If the start timer is overridden with the value set to
|
||
zero (T=0), then the start timer shall be disabled. This implies
|
||
that the MG will wait indefinitely for digits.
|
||
|
||
2) If the Media Gateway can determine that at least one more digit is
|
||
needed for a digit string to match any of the allowed patterns in
|
||
the digit map, then the interdigit timer value should be set to a
|
||
long (L) duration (e.g., 16 seconds).
|
||
|
||
3) If the digit string has matched one of the patterns in a digit
|
||
map, but it is possible that more digits could be received which
|
||
would cause a match with a different pattern, then instead of
|
||
reporting the match immediately, the MG must apply the short timer
|
||
(S) and wait for more digits.
|
||
|
||
The timers are configurable parameters to a DigitMap. Default values
|
||
of these timers should be provisioned on the MG, but can be
|
||
overridden by values specified within the DigitMap.
|
||
|
||
7.1.14.3 DigitMap Syntax
|
||
|
||
The formal syntax of the digit map is described by the DigitMap rule
|
||
in the formal syntax description of the protocol (see Annex A and
|
||
Annex B). A DigitMap, according to this syntax, is defined either by
|
||
a string or by a list of strings. Each string in the list is an
|
||
alternative event sequence, specified either as a sequence of digit
|
||
map symbols or as a regular expression of digit map symbols. These
|
||
digit map symbols, the digits "0" through "9" and letters "A" through
|
||
a maximum value depending on the signalling system concerned, but
|
||
never exceeding "K", correspond to specified events within a package
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 42]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
which has been designated in the Events descriptor on the Termination
|
||
to which the digit map is being applied. (The mapping between events
|
||
and digit map symbols is defined in the documentation for packages
|
||
associated with channel-associated signalling systems such as DTMF,
|
||
MF, or R2. Digits "0" through "9" MUST be mapped to the
|
||
corresponding digit events within the signalling system concerned.
|
||
Letters should be allocated in logical fashion, facilitating the use
|
||
of range notation for alternative events.)
|
||
|
||
The letter "x" is used as a wildcard, designating any event
|
||
corresponding to symbols in the range "0"-"9". The string may also
|
||
contain explicit ranges and, more generally, explicit sets of
|
||
symbols, designating alternative events any one of which satisfies
|
||
that position of the digit map. Finally, the dot symbol "." stands
|
||
for zero or more repetitions of the event selector (event, range of
|
||
events, set of alternative events, or wildcard) that precedes it. As
|
||
a consequence of the third timing rule above, inter-event timing
|
||
while matching a terminal dot symbol uses the short timer by default.
|
||
|
||
In addition to these event symbols, the string may contain "S" and
|
||
"L" inter-event timing specifiers and the "Z" duration modifier. "S"
|
||
and "L" respectively indicate that the MG should use the short (S)
|
||
timer or the long (L) timer for subsequent events, overriding the
|
||
timing rules described above. If an explicit timing specifier is in
|
||
effect in one alternative event sequence, but none is given in any
|
||
other candidate alternative, the timer value set by the explicit
|
||
timing specifier must be used. If all sequences with explicit timing
|
||
controls are dropped from the candidate set, timing reverts to the
|
||
default rules given above. Finally, if conflicting timing specifiers
|
||
are in effect in different alternative sequences, the long timer
|
||
shall be used.
|
||
|
||
A "Z" designates a long duration event: placed in front of the
|
||
symbol(s) designating the event(s) which satisfy a given digit
|
||
position, it indicates that that position is satisfied only if the
|
||
duration of the event exceeds the long-duration threshold. The value
|
||
of this threshold is assumed to be provisioned in the MG.
|
||
|
||
7.1.14.4 DigitMap Completion Event
|
||
|
||
A digit map is active while the Events descriptor which invoked it is
|
||
active and it has not completed. A digit map completes when:
|
||
|
||
- a timer has expired; or
|
||
|
||
- an alternative event sequence has been matched and no other
|
||
alternative event sequence in the digit map could be matched
|
||
through detection of an additional event (unambiguous match); or
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 43]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- an event has been detected such that a match to a complete
|
||
alternative event sequence of the digit map will be impossible no
|
||
matter what additional events are received.
|
||
|
||
Upon completion, a digit map completion event as defined in the
|
||
package providing the events being mapped into the digit map shall be
|
||
generated. At that point the digit map is deactivated. Subsequent
|
||
events in the package are processed as per the currently active event
|
||
processing mechanisms.
|
||
|
||
7.1.14.5 DigitMap Procedures
|
||
|
||
Pending completion, successive events shall be processed according to
|
||
the following rules:
|
||
|
||
1) The "current dial string", an internal variable, is initially
|
||
empty. The set of candidate alternative event sequences includes
|
||
all of the alternatives specified in the digit map.
|
||
|
||
2) At each step, a timer is set to wait for the next event, based
|
||
either on the default timing rules given above or on explicit
|
||
timing specified in one or more alternative event sequences. If
|
||
the timer expires and a member of the candidate set of
|
||
alternatives is fully satisfied, a timeout completion with full
|
||
match is reported. If the timer expires and part or none of any
|
||
candidate alternative is satisfied, a timeout completion with
|
||
partial match is reported.
|
||
|
||
3) If an event is detected before the timer expires, it is mapped to
|
||
a digit string symbol and provisionally added to the end of the
|
||
current dial string. The duration of the event (long or not long)
|
||
is noted if and only if this is relevant in the current symbol
|
||
position (because at least one of the candidate alternative event
|
||
sequences includes the "Z" modifier at this position in the
|
||
sequence).
|
||
|
||
4) The current dial string is compared to the candidate alternative
|
||
event sequences. If and only if a sequence expecting a
|
||
long-duration event at this position is matched (i.e., the event
|
||
had long duration and met the specification for this position),
|
||
then any alternative event sequences not specifying a long
|
||
duration event at this position are discarded, and the current
|
||
dial string is modified by inserting a "Z" in front of the symbol
|
||
representing the latest event. Any sequence expecting a long-
|
||
duration event at this position but not matching the observed
|
||
event is discarded from the candidate set. If alternative event
|
||
sequences not specifying a long duration event in the given
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 44]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
position remain in the candidate set after application of the
|
||
above rules, the observed event duration is treated as irrelevant
|
||
in assessing matches to them.
|
||
|
||
5) If exactly one candidate remains and it has been fully matched, a
|
||
completion event is generated indicating an unambiguous match. If
|
||
no candidates remain, the latest event is removed from the current
|
||
dial string and a completion event is generated indicating full
|
||
match if one of the candidates from the previous step was fully
|
||
satisfied before the latest event was detected, or partial match
|
||
otherwise. The event removed from the current dial string will
|
||
then be reported as per the currently active event processing
|
||
mechanisms.
|
||
|
||
6) If no completion event is reported out of step 5, processing
|
||
returns to step 2.
|
||
|
||
7.1.14.6 DigitMap Activation
|
||
|
||
A digit map is activated whenever a new Event descriptor is applied
|
||
to the Termination or embedded Event descriptor is activated, and
|
||
that Event descriptor contains a digit map completion event. The
|
||
digit map completion event contains an eventDM field in the requested
|
||
actions field. Each new activation of a digit map begins at step 1
|
||
of the above procedure, with a clear current dial string. Any
|
||
previous contents of the current dial string from an earlier
|
||
activation are lost.
|
||
|
||
A digit map completion event that does not contain an eventDM field
|
||
in its requested actions field is considered an error. Upon receipt
|
||
of such an event in an EventsDescriptor, a MG shall respond with an
|
||
error response, including Error 457 - Missing parameter in signal or
|
||
event.
|
||
|
||
7.1.14.7 Interaction Of DigitMap and Event Processing
|
||
|
||
While the digit map is activated, detection is enabled for all events
|
||
defined in the package containing the specified digit map completion
|
||
event. Normal event behaviour (e.g., stopping of signals unless the
|
||
digit completion event has the KeepActive flag enabled) continues to
|
||
apply for each such event detected, except that:
|
||
|
||
- the events in the package containing the specified digit map
|
||
completion event other than the completion event itself are not
|
||
individually notified and have no side-effects unless separately
|
||
enabled; and
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 45]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- an event that triggers a partial match completion event is not
|
||
recognized and therefore has no side effects until reprocessed
|
||
following the recognition of the digit map completion event.
|
||
|
||
7.1.14.8 Wildcards
|
||
|
||
Note that if a package contains a digit map completion event, then an
|
||
event specification consisting of the package name with a wildcarded
|
||
ItemID (Property Name) will activate a digit map; to that end, the
|
||
event specification must include an eventDM field according to
|
||
section 7.1.14.6. If the package also contains the digit events
|
||
themselves, this form of event specification will cause the
|
||
individual events to be reported to the MGC as they are detected.
|
||
|
||
7.1.14.9 Example
|
||
|
||
As an example, consider the following dial plan:
|
||
|
||
0 Local operator
|
||
|
||
00 Long-distance operator
|
||
|
||
xxxx Local extension number (starts with 1-7)
|
||
|
||
8xxxxxxx Local number
|
||
|
||
#xxxxxxx Off-site extension
|
||
|
||
*xx Star services
|
||
|
||
91xxxxxxxxxx Long-distance number
|
||
|
||
9011 + up to 15 digits International number
|
||
|
||
|
||
|
||
If the DTMF detection package described in E.6 is used to collect the
|
||
dialed digits, then the dialing plan shown above results in the
|
||
following digit map:
|
||
|
||
(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)
|
||
|
||
7.1.15 Statistics descriptor
|
||
|
||
The Statistics Descriptor provides information describing the status
|
||
and usage of a Termination during its existence within a specific
|
||
Context. There is a set of standard statistics kept for each
|
||
Termination where appropriate (number of octets sent and received for
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 46]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
example). The particular statistical properties that are reported
|
||
for a given Termination are determined by the Packages realized by
|
||
the Termination. By default, statistics are reported when the
|
||
Termination is Subtracted from the Context. This behaviour can be
|
||
overridden by including an empty AuditDescriptor in the Subtract
|
||
command. Statistics may also be returned from the AuditValue
|
||
command, or any Add/Move/Modify command using the Audit descriptor.
|
||
|
||
Statistics are cumulative; reporting Statistics does not reset them.
|
||
Statistics are reset when a Termination is Subtracted from a Context.
|
||
|
||
7.1.16 Packages descriptor
|
||
|
||
Used only with the AuditValue command, the PackageDescriptor returns
|
||
a list of Packages realized by the Termination.
|
||
|
||
7.1.17 ObservedEvents descriptor
|
||
|
||
ObservedEvents is supplied with the Notify command to inform the MGC
|
||
of which event(s) were detected. Used with the AuditValue command,
|
||
the ObservedEventsDescriptor returns events in the event buffer which
|
||
have not been Notified. ObservedEvents contains the
|
||
RequestIdentifier of the EventsDescriptor that triggered the
|
||
notification, the event(s) detected, optionally the detection time(s)
|
||
and any parameters of the observed event. Detection times are
|
||
reported with a precision of hundredths of a second.
|
||
|
||
7.1.18 Topology descriptor
|
||
|
||
A Topology descriptor is used to specify flow directions between
|
||
Terminations in a Context. Contrary to the descriptors in previous
|
||
subclauses, the Topology descriptor applies to a Context instead of a
|
||
Termination. The default topology of a Context is that each
|
||
Termination's transmission is received by all other Terminations.
|
||
The Topology descriptor is optional to implement. An MG that does
|
||
not support Topology descriptors, but receives a command containing
|
||
one, returns Error 444 Unsupported or unknown descriptor, and
|
||
optionally includes a string containing the name of the unsupported
|
||
Descriptor ("Topology") in the error text in the error descriptor.
|
||
|
||
The Topology descriptor occurs before the commands in an action. It
|
||
is possible to have an action containing only a Topology descriptor,
|
||
provided that the Context to which the action applies already exists.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 47]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A Topology descriptor consists of a sequence of triples of the form
|
||
(T1, T2, association). T1 and T2 specify Terminations within the
|
||
Context, possibly using the ALL or CHOOSE wildcard. The association
|
||
specifies how media flows between these two Terminations as follows.
|
||
|
||
- (T1, T2, isolate) means that the Terminations matching T2 do not
|
||
receive media from the Terminations matching T1, nor vice versa.
|
||
|
||
- (T1, T2, oneway) means that the Terminations that match T2 receive
|
||
media from the Terminations matching T1, but not vice versa. In
|
||
this case use of the ALL wildcard such that there are Terminations
|
||
that match both T1 and T2 is not allowed.
|
||
|
||
- (T1, T2, bothway) means that the Terminations matching T2 receive
|
||
media from the Terminations matching T1, and vice versa. In this
|
||
case it is allowed to use wildcards such that there are
|
||
Terminations that match both T1 and T2. However, if there is a
|
||
Termination that matches both, no loopback is introduced.
|
||
|
||
CHOOSE wildcards may be used in T1 and T2 as well, under the
|
||
following restrictions:
|
||
|
||
- the action (see clause 8) of which the topology descriptor is part
|
||
contains an Add command in which a CHOOSE wildcard is used;
|
||
|
||
- if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL
|
||
NOT be specified.
|
||
|
||
The CHOOSE wildcard in a Topology descriptor matches the
|
||
TerminationID that the MG assigns in the first Add command that uses
|
||
a CHOOSE wildcard in the same action. An existing Termination that
|
||
matches T1 or T2 in the Context to which a Termination is added, is
|
||
connected to the newly added Termination as specified by the Topology
|
||
descriptor.
|
||
|
||
If a termination is not mentioned within a Topology Descriptor, any
|
||
topology associated with it remains unchanged. If, however, a new
|
||
termination is added into a context its association with the other
|
||
terminations within the context defaults to bothway, unless a
|
||
Topology Descriptor is given to change this (e.g., if T3 is added to
|
||
a context with T1 and T2 with topology (T3, T1, oneway) it will be
|
||
connected bothway to T2).
|
||
|
||
Figure 7 and the table following it show some examples of the effect
|
||
of including topology descriptors in actions. In these examples it
|
||
is assumed that the topology descriptors are applied in sequence.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 48]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
+------------------+ +------------------+ +------------------+
|
||
| +----+ | | +----+ | | +----+ |
|
||
| | T2 | | | | T2 | | | | T2 | |
|
||
| +----+ | | +----+ | | +----+ |
|
||
| ^ ^ | | ^ | | ^ |
|
||
| | | | | | | | | |
|
||
| +--+ +--+ | | +---+ | | +--+ |
|
||
| | | | | | | | | |
|
||
| v v | | v | | | |
|
||
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
|
||
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
|
||
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
|
||
+------------------+ +------------------+ +------------------+
|
||
1. No Topology Desc. 2. T1, T2, Isolate 3. T3, T2, Oneway
|
||
|
||
+------------------+ +------------------+ +------------------+
|
||
| +----+ | | +----+ | | +----+ |
|
||
| | T2 | | | | T2 | | | | T2 | |
|
||
| +----+ | | +----+ | | +----+ |
|
||
| | | | ^ | | ^ ^ |
|
||
| | | | | | | | | |
|
||
| +--+ | | +---+ | | +--+ +--+ |
|
||
| | | | | | | | | |
|
||
| v | | v | | v v |
|
||
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
|
||
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
|
||
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
|
||
+------------------+ +------------------+ +------------------+
|
||
4. T2, T3 oneway 5. T2, T3 bothway 6. T1, T2 bothway
|
||
|
||
Note: the direction of the arrow indicates the direction of flow.
|
||
|
||
Figure 7: Example topologies
|
||
|
||
Topology Description
|
||
|
||
1 No topology descriptors When no topology descriptors are
|
||
included, all Terminations have a
|
||
bothway connection to all other
|
||
Terminations.
|
||
|
||
2 T1, T2 Isolate Removes the connection between T1 and
|
||
T2. T3 has a bothway connection with
|
||
both T1 and T2. T1 and T2 have bothway
|
||
connection to T3.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 49]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
3 T3, T2 oneway A oneway connection from T3 to T2 (i.e.,
|
||
T2 receives media flow from T3). A
|
||
bothway connection between T1 and T3.
|
||
|
||
4 T2, T3 oneway A oneway connection between T2 to T3.
|
||
T1 and T3 remain bothway connected.
|
||
|
||
5 T2, T3 bothway T2 is bothway connected to T3. This
|
||
results in the same as 2.
|
||
|
||
6 T1, T2 bothway (T2, T3 All Terminations have a bothway
|
||
bothway and T1, T3 connection to all other Terminations.
|
||
bothway may be implied or
|
||
explicit).
|
||
|
||
A oneway connection must be implemented in such a way that the other
|
||
Terminations in the Context are not aware of the change in topology.
|
||
|
||
7.1.19 Error Descriptor
|
||
|
||
If a responder encounters an error when processing a transaction
|
||
request, it must include an error descriptor in its response. A
|
||
Notify request may contain an error descriptor as well.
|
||
|
||
An error descriptor consists of an IANA-registered error code,
|
||
optionally accompanied by an error text. H.248.8 contains a list of
|
||
valid error codes and error descriptions.
|
||
|
||
An error descriptor shall be specified at the "deepest level" that is
|
||
semantically appropriate for the error being described and that is
|
||
possible given any parsing problems with the original request. An
|
||
error descriptor may refer to a syntactical construct other than
|
||
where it appears. For example, Error descriptor 422 - Syntax Error
|
||
in Action, could appear within a command even though it refers to the
|
||
larger construct - the action - and not the particular command within
|
||
which it appears.
|
||
|
||
7.2 Command Application Programming Interface
|
||
|
||
Following is an Application Programming Interface (API) describing
|
||
the Commands of the protocol. This API is shown to illustrate the
|
||
Commands and their parameters and is not intended to specify
|
||
implementation (e.g., via use of blocking function calls). It
|
||
describes the input parameters in parentheses after the command name
|
||
and the return values in front of the Command. This is only for
|
||
descriptive purposes; the actual Command syntax and encoding are
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 50]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
specified in later subclauses. The order of parameters to commands
|
||
is not fixed. Descriptors may appear as parameters to commands in
|
||
any order. The descriptors SHALL be processed in the order in which
|
||
they appear.
|
||
|
||
Any reply to a command may contain an error descriptor; the API does
|
||
not specifically show this.
|
||
|
||
All parameters enclosed by square brackets ([. . .]) are considered
|
||
optional.
|
||
|
||
7.2.1 Add
|
||
|
||
The Add Command adds a Termination to a Context.
|
||
|
||
TerminationID
|
||
[,MediaDescriptor]
|
||
[,ModemDescriptor]
|
||
[,MuxDescriptor]
|
||
[,EventsDescriptor]
|
||
[,SignalsDescriptor]
|
||
[,DigitMapDescriptor]
|
||
[,ObservedEventsDescriptor]
|
||
[,EventBufferDescriptor]
|
||
[,StatisticsDescriptor]
|
||
[,PackagesDescriptor]
|
||
Add( TerminationID
|
||
[, MediaDescriptor]
|
||
[, ModemDescriptor]
|
||
[, MuxDescriptor]
|
||
[, EventsDescriptor]
|
||
[, EventBufferDescriptor]
|
||
[, SignalsDescriptor]
|
||
[, DigitMapDescriptor]
|
||
[, AuditDescriptor]
|
||
)
|
||
|
||
The TerminationID specifies the Termination to be added to the
|
||
Context. The Termination is either created, or taken from the null
|
||
Context. If a CHOOSE wildcard is used in the TerminationID, the
|
||
selected TerminationID will be returned. Wildcards may be used in an
|
||
Add, but such usage would be unusual. If the wildcard matches more
|
||
than one TerminationID, all possible matches are attempted, with
|
||
results reported for each one. The order of attempts when multiple
|
||
TerminationIDs match is not specified.
|
||
|
||
The optional MediaDescriptor describes all media streams.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 51]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The optional ModemDescriptor and MuxDescriptor specify a modem and
|
||
multiplexer if applicable. For convenience, if a Multiplex
|
||
descriptor is present in an Add command and lists any Terminations
|
||
that are not currently in the Context, such Terminations are added to
|
||
the Context as if individual Add commands listing the Terminations
|
||
were invoked. If an error occurs on such an implied Add, error 471 -
|
||
Implied Add for Multiplex failure shall be returned and further
|
||
processing of the command shall cease.
|
||
|
||
The EventsDescriptor parameter is optional. If present, it provides
|
||
the list of events that should be detected on the Termination.
|
||
|
||
The EventBufferDescriptor parameter is optional. If present, it
|
||
provides the list of events that the MG is requested to detect and
|
||
buffer when EventBufferControl equals LockStep.
|
||
|
||
The SignalsDescriptor parameter is optional. If present, it provides
|
||
the list of signals that should be applied to the Termination.
|
||
|
||
The DigitMapDescriptor parameter is optional. If present, it defines
|
||
a DigitMap definition that may be used in an EventsDescriptor.
|
||
|
||
The AuditDescriptor is optional. If present, the command will return
|
||
descriptors as specified in the AuditDescriptor.
|
||
|
||
All descriptors that can be modified could be returned by MG if a
|
||
parameter was underspecified or overspecified. ObservedEvents,
|
||
Statistics, and Packages, and the EventBuffer descriptors are
|
||
returned only if requested in the AuditDescriptor.
|
||
|
||
Add SHALL NOT be used on a Termination with a serviceState of
|
||
"OutofService".
|
||
|
||
7.2.2 Modify
|
||
|
||
The Modify Command modifies the properties of a Termination.
|
||
|
||
TerminationID
|
||
[,MediaDescriptor]
|
||
[,ModemDescriptor]
|
||
[,MuxDescriptor]
|
||
[,EventsDescriptor]
|
||
[,SignalsDescriptor]
|
||
[,DigitMapDescriptor]
|
||
[,ObservedEventsDescriptor]
|
||
[,EventBufferDescriptor]
|
||
[,StatisticsDescriptor]
|
||
[,PackagesDescriptor]
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 52]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Modify( TerminationID
|
||
[, MediaDescriptor]
|
||
[, ModemDescriptor]
|
||
[, MuxDescriptor]
|
||
[, EventsDescriptor]
|
||
[, EventBufferDescriptor]
|
||
[, SignalsDescriptor]
|
||
[, DigitMapDescriptor]
|
||
[, AuditDescriptor]
|
||
)
|
||
|
||
The TerminationID may be specific if a single Termination in the
|
||
Context is to be modified. Use of wildcards in the TerminationID may
|
||
be appropriate for some operations. If the wildcard matches more
|
||
than one TerminationID, all possible matches are attempted, with
|
||
results reported for each one. The order of attempts when multiple
|
||
TerminationIDs match is not specified. The CHOOSE option is an
|
||
error, as the Modify command may only be used on existing
|
||
Terminations.
|
||
|
||
For convenience, if a Multiplex Descriptor is present in a Modify
|
||
command, then:
|
||
|
||
- if the new Multiplex Descriptor lists any Terminations that are
|
||
not currently in the Context, such Terminations are added to the
|
||
context as if individual commands listing the Terminations were
|
||
invoked.
|
||
|
||
- if any Terminations listed previously in the Multiplex Descriptor
|
||
are no longer present in the new Multiplex Descriptor, they are
|
||
subtracted from the context as if individual Subtract commands
|
||
listing the Terminations were invoked.
|
||
|
||
The remaining parameters to Modify are the same as those to Add.
|
||
Possible return values are the same as those to Add.
|
||
|
||
7.2.3 Subtract
|
||
|
||
The Subtract Command disconnects a Termination from its Context and
|
||
returns statistics on the Termination's participation in the Context.
|
||
|
||
TerminationID
|
||
[,MediaDescriptor]
|
||
[,ModemDescriptor]
|
||
[,MuxDescriptor]
|
||
[,EventsDescriptor]
|
||
[,SignalsDescriptor]
|
||
[,DigitMapDescriptor]
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 53]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
[,ObservedEventsDescriptor]
|
||
[,EventBufferDescriptor]
|
||
[,StatisticsDescriptor]
|
||
[,PackagesDescriptor]
|
||
Subtract(TerminationID
|
||
[, AuditDescriptor]
|
||
)
|
||
|
||
TerminationID in the input parameters represents the Termination that
|
||
is being subtracted. The TerminationID may be specific or may be a
|
||
wildcard value indicating that all (or a set of related) Terminations
|
||
in the Context of the Subtract Command are to be subtracted. If the
|
||
wildcard matches more than one TerminationID, all possible matches
|
||
are attempted, with results reported for each one. The order of
|
||
attempts when multiple TerminationIDs match is not specified.
|
||
|
||
The use of CHOOSE in the TerminationID is an error, as the Subtract
|
||
command may only be used on existing Terminations.
|
||
|
||
ALL may be used as the ContextID as well as the TerminationId in a
|
||
Subtract, which would have the effect of deleting all Contexts,
|
||
deleting all ephemeral Terminations, and returning all physical
|
||
Terminations to Null Context. Subtract of a termination from the
|
||
Null Context is not allowed.
|
||
|
||
For convenience, if a multiplexing Termination is the object of a
|
||
Subtract command, then any bearer Terminations listed in its
|
||
Multiplex Descriptor are subtracted from the context as if individual
|
||
Subtract commands listing the Terminations were invoked.
|
||
|
||
By default, the Statistics parameter is returned to report
|
||
information collected on the Termination or Terminations specified in
|
||
the Command. The information reported applies to the Termination's
|
||
or Terminations' existence in the Context from which it or they are
|
||
being subtracted.
|
||
|
||
The AuditDescriptor is optional. If present, the command will return
|
||
only those descriptors as specified in the AuditDescriptor, which may
|
||
be empty. If omitted, the Statistics descriptor is returned, by
|
||
default. Possible return values are the same as those to Add.
|
||
|
||
When a provisioned Termination is Subtracted from a Context, its
|
||
property values shall revert to:
|
||
|
||
- the default value, if specified for the property and not
|
||
overridden by provisioning;
|
||
|
||
- otherwise, the provisioned value.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 54]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.2.4 Move
|
||
|
||
The Move Command moves a Termination to another Context from its
|
||
current Context in one atomic operation. The Move command is the
|
||
only command that refers to a Termination in a Context different from
|
||
that to which the command is applied. The Move command shall not be
|
||
used to move Terminations to or from the null Context.
|
||
|
||
TerminationID
|
||
[,MediaDescriptor]
|
||
[,ModemDescriptor]
|
||
[,MuxDescriptor]
|
||
[,EventsDescriptor]
|
||
[,SignalsDescriptor]
|
||
[,DigitMapDescriptor]
|
||
[,ObservedEventsDescriptor]
|
||
[,EventBufferDescriptor]
|
||
[,StatisticsDescriptor]
|
||
[,PackagesDescriptor]
|
||
Move( TerminationID
|
||
[, MediaDescriptor]
|
||
[, ModemDescriptor]
|
||
[, MuxDescriptor]
|
||
[, EventsDescriptor]
|
||
[, EventBufferDescriptor]
|
||
[, SignalsDescriptor]
|
||
[, DigitMapDescriptor]
|
||
[, AuditDescriptor]
|
||
)
|
||
|
||
The TerminationID specifies the Termination to be moved. It may be
|
||
wildcarded, but CHOOSE shall not be used in the TerminationID. If
|
||
the wildcard matches more than one TerminationID, all possible
|
||
matches are attempted, with results reported for each one. The order
|
||
of attempts when multiple TerminationIDs match is not specified. The
|
||
Context to which the Termination is moved is indicated by the target
|
||
ContextId in the Action. If the last remaining Termination is moved
|
||
out of a Context, the Context is deleted.
|
||
|
||
The Move command does not affect the properties of the Termination on
|
||
which it operates, except those properties explicitly modified by
|
||
descriptors included in the Move command. The AuditDescriptor with
|
||
the Statistics option, for example, would return statistics on the
|
||
Termination just prior to the Move. Possible descriptors returned
|
||
from Move are the same as for Add.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 55]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
For convenience, if a multiplexing Termination is the object of a
|
||
Move command, then any bearer Terminations listed in its Multiplex
|
||
Descriptor are also moved as if individual Move commands listing the
|
||
Terminations were invoked.
|
||
|
||
Move SHALL NOT be used on a Termination with a serviceState of
|
||
"OutofService".
|
||
|
||
7.2.5 AuditValue
|
||
|
||
The AuditValue Command returns the current values of properties,
|
||
events, signals and statistics associated with Terminations.
|
||
|
||
TerminationID
|
||
[,MediaDescriptor]
|
||
[,ModemDescriptor]
|
||
[,MuxDescriptor]
|
||
[,EventsDescriptor]
|
||
[,SignalsDescriptor]
|
||
[,DigitMapDescriptor]
|
||
[,ObservedEventsDescriptor]
|
||
[,EventBufferDescriptor]
|
||
[,StatisticsDescriptor]
|
||
[,PackagesDescriptor]
|
||
AuditValue(TerminationID,
|
||
AuditDescriptor
|
||
)
|
||
|
||
TerminationID may be specific or wildcarded. If the wildcard matches
|
||
more than one TerminationID, all possible matches are attempted, with
|
||
results reported for each one. The order of attempts when multiple
|
||
TerminationIDs match is not specified. If a wildcarded response is
|
||
requested, only one command return is generated, with the contents
|
||
containing the union of the values of all Terminations matching the
|
||
wildcard. This convention may reduce the volume of data required to
|
||
audit a group of Terminations. Use of CHOOSE is an error.
|
||
|
||
The appropriate descriptors, with the current values for the
|
||
Termination, are returned from AuditValue. Values appearing in
|
||
multiple instances of a descriptor are defined to be alternate values
|
||
supported, with each parameter in a descriptor considered
|
||
independent.
|
||
|
||
ObservedEvents returns a list of events in the EventBuffer. If the
|
||
ObservedEventsDescriptor is audited while a DigitMap is active, the
|
||
returned ObservedEvents descriptor also includes a digit map
|
||
completion event that shows the current dial string but does not show
|
||
a Termination method.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 56]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
EventBuffer returns the set of events and associated parameter values
|
||
currently enabled in the EventBufferDescriptor. PackagesDescriptor
|
||
returns a list of packages realized by the Termination.
|
||
DigitMapDescriptor returns the name or value of the current DigitMap
|
||
for the Termination. DigitMap requested in an AuditValue command
|
||
with TerminationID ALL returns all DigitMaps in the gateway.
|
||
Statistics returns the current values of all statistics being kept on
|
||
the Termination. Specifying an empty Audit descriptor results in
|
||
only the TerminationID being returned. This may be useful to get a
|
||
list of TerminationIDs when used with wildcard. Annexes A and B
|
||
provide a special syntax for presenting such a list in condensed
|
||
form, such that the AuditValue command tag does not have to be
|
||
repeated for each TerminationID.
|
||
|
||
AuditValue results depend on the Context, viz. specific, null, or
|
||
wildcarded. (Note that ContextID ALL does not include the null
|
||
Context.) The TerminationID may be specific, or wildcarded.
|
||
|
||
The following are examples of what is returned in case the context
|
||
and/or the termination is wildcarded and a wildcarded response has
|
||
been specified.
|
||
|
||
Assume that the gateway has 4 terminations: t1/1, t1/2, t2/1 and
|
||
t2/2. Assume that terminations t1/* have implemented packages aaa
|
||
and bbb and that terminations t2/* have implemented packages ccc and
|
||
ddd. Assume that Context 1 has t1/1 and t2/1 in it and that Context
|
||
2 has t1/2 and t2/2 in it.
|
||
|
||
The command:
|
||
|
||
Context=1{AuditValue=t1/1{Audit{Packages}}}
|
||
|
||
Returns:
|
||
|
||
Context=1{AuditValue=t1/1{Packages{aaa,bbb}}}
|
||
|
||
The command:
|
||
|
||
Context=*{AuditValue=t2/*{Audit{Packages}}}
|
||
|
||
Returns:
|
||
|
||
Context=1{AuditValue=t2/1{Packages{ccc,ddd}}},
|
||
Context=2{AuditValue=t2/2{Packages{ccc,ddd}}}
|
||
|
||
The command:
|
||
|
||
Context=*{W-AuditValue=t1/*{Audit{Packages}}}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 57]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Returns:
|
||
|
||
Context=*{W-AuditValue=t1/*{Packages{aaa,bbb}}}
|
||
|
||
Note: A wildcard response may also be used for other commands such as
|
||
Subtract.
|
||
|
||
The following illustrates other information that can be obtained with
|
||
the AuditValue Command:
|
||
|
||
ContextID TerminationID Information Obtained
|
||
|
||
Specific wildcard Audit of matching Terminations in a Context
|
||
|
||
Specific specific Audit of a single Termination in a Context
|
||
|
||
Null Root Audit of Media Gateway state and events
|
||
|
||
Null wildcard Audit of all matching Terminations in the
|
||
null Context
|
||
|
||
Null specific Audit of a single Termination outside of any
|
||
Context
|
||
|
||
All wildcard Audit of all matching Terminations and the
|
||
Context to which they are associated
|
||
|
||
All Root List of all ContextIds (the ContextID list
|
||
should be returned by using multiple action
|
||
replies, each containing a ContextID from
|
||
the list)
|
||
|
||
All Specific (Non-null) ContextID in which the
|
||
Termination currently exists
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 58]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.2.6 AuditCapabilities
|
||
|
||
The AuditCapabilities Command returns the possible values of
|
||
properties, events, signals and statistics associated with
|
||
Terminations.
|
||
|
||
TerminationID
|
||
[,MediaDescriptor]
|
||
[,ModemDescriptor]
|
||
[,MuxDescriptor]
|
||
[,EventsDescriptor]
|
||
[,SignalsDescriptor]
|
||
[,ObservedEventsDescriptor]
|
||
[,EventBufferDescriptor]
|
||
[,StatisticsDescriptor]
|
||
AuditCapabilities(TerminationID,
|
||
AuditDescriptor
|
||
)
|
||
|
||
The appropriate descriptors, with the possible values for the
|
||
Termination are returned from AuditCapabilities. Descriptors may be
|
||
repeated where there are multiple possible values. If a wildcarded
|
||
response is requested, only one command return is generated, with the
|
||
contents containing the union of the values of all Terminations
|
||
matching the wildcard. This convention may reduce the volume of data
|
||
required to audit a group of Terminations.
|
||
|
||
Interpretation of what capabilities are requested for various values
|
||
of ContextID and TerminationID is the same as in AuditValue.
|
||
|
||
The EventsDescriptor returns the list of possible events on the
|
||
Termination together with the list of all possible values for the
|
||
EventsDescriptor Parameters. EventBufferDescriptor returns the same
|
||
information as EventsDescriptor. The SignalsDescriptor returns the
|
||
list of possible signals that could be applied to the Termination
|
||
together with the list of all possible values for the Signals
|
||
Parameters. StatisticsDescriptor returns the names of the statistics
|
||
being kept on the termination. ObservedEventsDescriptor returns the
|
||
names of active events on the Termination. DigitMap and Packages are
|
||
not legal in AuditCapability.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 59]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The following illustrates other information that can be obtained with
|
||
the AuditCapabilties Command:
|
||
|
||
ContextID TerminationID Information Obtained
|
||
|
||
Specific wildcard Audit of matching Terminations in a Context
|
||
|
||
Specific specific Audit of a single Termination in a Context
|
||
|
||
Null Root Audit of MG state and events
|
||
|
||
Null wildcard Audit of all matching Terminations in the
|
||
Null Context
|
||
|
||
Null specific Audit of a single Termination outside of any
|
||
Context
|
||
|
||
All wildcard Audit of all matching Terminations and the
|
||
Context to which they are associated
|
||
|
||
All Root Same as for AuditValue
|
||
|
||
All Specific Same as for AuditValue
|
||
|
||
7.2.7 Notify
|
||
|
||
The Notify Command allows the Media Gateway to notify the Media
|
||
Gateway Controller of events occurring within the Media Gateway.
|
||
|
||
TerminationID
|
||
Notify(TerminationID,
|
||
ObservedEventsDescriptor,
|
||
[ErrorDescriptor]
|
||
)
|
||
|
||
The TerminationID parameter specifies the Termination issuing the
|
||
Notify Command. The TerminationID shall be a fully qualified name.
|
||
|
||
The ObservedEventsDescriptor contains the RequestID and a list of
|
||
events that the Media Gateway detected in the order that they were
|
||
detected. Each event in the list is accompanied by parameters
|
||
associated with the event and optionally an indication of the time
|
||
that the event was detected. Procedures for sending Notify commands
|
||
with RequestID equal to 0 are for further study.
|
||
|
||
Notify Commands with RequestID not equal to 0 shall occur only as the
|
||
result of detection of an event specified by an Events descriptor
|
||
which is active on the Termination concerned.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 60]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The RequestID returns the RequestID parameter of the EventsDescriptor
|
||
that triggered the Notify Command. It is used to correlate the
|
||
notification with the request that triggered it. The events in the
|
||
list must have been requested via the triggering EventsDescriptor or
|
||
embedded events descriptor unless the RequestID is 0 (which is for
|
||
further study).
|
||
|
||
The ErrorDescriptor may be sent in the Notify Command as a result of
|
||
Error 518 - Event buffer full.
|
||
|
||
7.2.8 ServiceChange
|
||
|
||
The ServiceChange Command allows the Media Gateway to notify the
|
||
Media Gateway Controller that a Termination or group of Terminations
|
||
is about to be taken out of service or has just been returned to
|
||
service. The Media Gateway Controller may indicate that
|
||
Termination(s) shall be taken out of or returned to service. The
|
||
Media Gateway may notify the MGC that the capability of a Termination
|
||
has changed. It also allows a MGC to hand over control of a MG to
|
||
another MGC.
|
||
|
||
TerminationID,
|
||
|
||
[ServiceChangeDescriptor]
|
||
ServiceChange ( TerminationID,
|
||
ServiceChangeDescriptor
|
||
)
|
||
|
||
The TerminationID parameter specifies the Termination(s) that are
|
||
taken out of or returned to service. Wildcarding of Termination
|
||
names is permitted, with the exception that the CHOOSE mechanism
|
||
shall not be used. Use of the "Root" TerminationID indicates a
|
||
ServiceChange affecting the entire Media Gateway.
|
||
|
||
The ServiceChangeDescriptor contains the following parameters as
|
||
required:
|
||
|
||
- ServiceChangeMethod
|
||
- ServiceChangeReason
|
||
- ServiceChangeDelay
|
||
- ServiceChangeAddress
|
||
- ServiceChangeProfile
|
||
- ServiceChangeVersion
|
||
- ServiceChangeMgcId
|
||
- TimeStamp
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 61]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The ServiceChangeMethod parameter specifies the type of ServiceChange
|
||
that will or has occurred:
|
||
|
||
1) Graceful - indicates that the specified Terminations will be taken
|
||
out of service after the specified ServiceChangeDelay; established
|
||
connections are not yet affected, but the Media Gateway Controller
|
||
should refrain from establishing new connections and should
|
||
attempt to gracefully tear down existing connections on the
|
||
Termination(s) affected by the serviceChange command. The MG
|
||
should set Termination serviceState at the expiry of
|
||
ServiceChangeDelay or the removal of the Termination from an
|
||
active Context (whichever is first), to "out of service".
|
||
|
||
2) Forced - indicates that the specified Terminations were taken
|
||
abruptly out of service and any established connections associated
|
||
with them may be lost. For non-Root terminations, the MGC is
|
||
responsible for cleaning up the Context (if any) with which the
|
||
failed Termination is associated. At a minimum the Termination
|
||
shall be subtracted from the Context. The Termination
|
||
serviceState should be "out of service". For the root
|
||
termination, the MGC can assume that all connections are lost on
|
||
the MG and thus can consider that all the terminations have been
|
||
subtracted.
|
||
|
||
3) Restart - indicates that service will be restored on the specified
|
||
Terminations after expiration of the ServiceChangeDelay. The
|
||
serviceState should be set to "inService" upon expiry of
|
||
ServiceChangeDelay.
|
||
|
||
4) Disconnected - always applied with the Root TerminationID,
|
||
indicates that the MG lost communication with the MGC, but it was
|
||
subsequently restored to the same MGC (possibly after trying other
|
||
MGCs on a pre-provisioned list). Since MG state may have changed,
|
||
the MGC may wish to use the Audit command to resynchronize its
|
||
state with the MG's.
|
||
|
||
5) Handoff - sent from the MGC to the MG, this reason indicates that
|
||
the MGC is going out of service and a new MGC association must be
|
||
established. Sent from the MG to the MGC, this indicates that the
|
||
MG is attempting to establish a new association in accordance with
|
||
a Handoff received from the MGC with which it was previously
|
||
associated.
|
||
|
||
6) Failover - sent from MG to MGC to indicate the primary MG is out
|
||
of service and a secondary MG is taking over. This serviceChange
|
||
method is also sent from the MG to the MGC when the MG detects
|
||
that MGC has failed.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 62]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7) Another value whose meaning is mutually understood between the MG
|
||
and the MGC.
|
||
|
||
The ServiceChangeReason parameter specifies the reason why the
|
||
ServiceChange has or will occur. It consists of an alphanumeric
|
||
token (IANA registered) and, optionally, an explanatory string.
|
||
|
||
The optional ServiceChangeAddress parameter specifies the address
|
||
(e.g., IP port number for IP networks) to be used for subsequent
|
||
communications. It can be specified in the input parameter
|
||
descriptor or the returned result descriptor. ServiceChangeAddress
|
||
and ServiceChangeMgcId parameters must not both be present in the
|
||
ServiceChangeDescriptor or the ServiceChangeResultDescriptor. The
|
||
ServiceChangeAddress provides an address to be used within the
|
||
Context of the association currently being negotiated, while the
|
||
ServiceChangeMgcId provides an alternate address where the MG should
|
||
seek to establish another association. Note that the use of
|
||
ServiceChangeAddress is not encouraged. MGCs and MGs must be able to
|
||
cope with the ServiceChangeAddress being either a full address or
|
||
just a port number in the case of TCP transports.
|
||
|
||
The optional ServiceChangeDelay parameter is expressed in seconds.
|
||
If the delay is absent or set to zero, the delay value should be
|
||
considered to be null. In the case of a "graceful"
|
||
ServiceChangeMethod, a null delay indicates that the Media Gateway
|
||
Controller should wait for the natural removal of existing
|
||
connections and should not establish new connections. For "graceful"
|
||
only, a null delay means the MG must not set serviceState "out of
|
||
service" until the Termination is in the null Context.
|
||
|
||
The optional ServiceChangeProfile parameter specifies the Profile (if
|
||
any) of the protocol supported. The ServiceChangeProfile includes
|
||
the version of the profile supported.
|
||
|
||
The optional ServiceChangeVersion parameter contains the protocol
|
||
version and is used if protocol version negotiation occurs (see
|
||
11.3).
|
||
|
||
The optional TimeStamp parameter specifies the actual time as kept by
|
||
the sender. As such, it is not necessarily absolute time according
|
||
to, for example, a local time zone - it merely establishes an
|
||
arbitrary starting time against which all future timestamps
|
||
transmitted by a sender during this association shall be compared.
|
||
It can be used by the responder to determine how its notion of time
|
||
differs from that of its correspondent. TimeStamp is sent with a
|
||
precision of hundredths of a second.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 63]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The optional Extension parameter may contain any value whose meaning
|
||
is mutually understood by the MG and MGC.
|
||
|
||
A ServiceChange Command specifying the "Root" for the TerminationID
|
||
and ServiceChangeMethod equal to Restart is a registration command by
|
||
which a Media Gateway announces its existence to the Media Gateway
|
||
Controller. The Media Gateway may also announce a registration
|
||
command by specifying the "Root" for the TerminationID and
|
||
ServiceChangeMethod equal to Failover when the MG detects MGC
|
||
failures. The Media Gateway is expected to be provisioned with the
|
||
name of one primary and optionally some number of alternate Media
|
||
Gateway Controllers. Acknowledgement of the ServiceChange Command
|
||
completes the registration process, except when the MGC has returned
|
||
an alternative ServiceChangeMgcId as described in the following
|
||
paragraph. The MG may specify the transport ServiceChangeAddress to
|
||
be used by the MGC for sending messages in the ServiceChangeAddress
|
||
parameter in the input ServiceChangeDescriptor. The MG may specify
|
||
an address in the ServiceChangeAddress parameter of the ServiceChange
|
||
request, and the MGC may also do so in the ServiceChange reply. In
|
||
either case, the recipient must use the supplied address as the
|
||
destination for all subsequent transaction requests within the
|
||
association. At the same time, as indicated in clause 9, transaction
|
||
replies and pending indications must be sent to the address from
|
||
which the corresponding requests originated. This must be done even
|
||
if it implies extra messaging because commands and responses cannot
|
||
be packed together. The TimeStamp parameter shall be sent with a
|
||
registration command and its response.
|
||
|
||
The Media Gateway Controller may return a ServiceChangeMgcId
|
||
parameter that describes the Media Gateway Controller that should
|
||
preferably be contacted for further service by the Media Gateway. In
|
||
this case the Media Gateway shall reissue the ServiceChange command
|
||
to the new Media Gateway Controller. The MGC specified in a
|
||
ServiceChangeMgcId, if provided, shall be contacted before any
|
||
further alternate MGCs. On a HandOff message from MGC to MG, the
|
||
ServiceChangeMgcId is the new MGC that will take over from the
|
||
current MGC.
|
||
|
||
The return from ServiceChange is empty except when the Root
|
||
terminationID is used. In that case it includes the following
|
||
parameters as required:
|
||
|
||
- ServiceChangeAddress, if the responding MGC wishes to specify a
|
||
new destination for messages from the MG for the remainder of the
|
||
association;
|
||
|
||
- ServiceChangeMgcId, if the responding MGC does not wish to sustain
|
||
an association with the MG;
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 64]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
- ServiceChangeProfile, if the responder wishes to negotiate the
|
||
profile to be used for the association;
|
||
|
||
- ServiceChangeVersion, if the responder wishes to negotiate the
|
||
version of the protocol to be used for the association.
|
||
|
||
The following ServiceChangeReasons are defined. This list may be
|
||
extended by an IANA registration as outlined in 13.3.
|
||
|
||
900 Service Restored
|
||
901 Cold Boot
|
||
902 Warm Boot
|
||
903 MGC Directed Change
|
||
904 Termination malfunctioning
|
||
905 Termination taken out of service
|
||
906 Loss of lower layer connectivity (e.g., downstream sync)
|
||
907 Transmission Failure
|
||
908 MG Impending Failure
|
||
909 MGC Impending Failure
|
||
910 Media Capability Failure
|
||
911 Modem Capability Failure
|
||
912 Mux Capability Failure
|
||
913 Signal Capability Failure
|
||
914 Event Capability Failure
|
||
915 State Loss
|
||
|
||
7.2.9 Manipulating and Auditing Context Attributes
|
||
|
||
The commands of the protocol as discussed in the preceding subclauses
|
||
apply to Terminations. This subclause specifies how Contexts are
|
||
manipulated and audited.
|
||
|
||
Commands are grouped into actions (see clause 8). An action applies
|
||
to one Context. In addition to commands, an action may contain
|
||
Context manipulation and auditing instructions.
|
||
|
||
An action request sent to a MG may include a request to audit
|
||
attributes of a Context. An action may also include a request to
|
||
change the attributes of a Context.
|
||
|
||
The Context properties that may be included in an action reply are
|
||
used to return information to a MGC. This can be information
|
||
requested by an audit of Context attributes or details of the effect
|
||
of manipulation of a Context.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 65]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
If a MG receives an action which contains both a request to audit
|
||
context attributes and a request to manipulate those attributes, the
|
||
response SHALL include the values of the attributes after processing
|
||
the manipulation request.
|
||
|
||
7.2.10 Generic Command Syntax
|
||
|
||
The protocol can be encoded in a binary format or in a text format.
|
||
MGCs should support both encoding formats. MGs may support both
|
||
formats.
|
||
|
||
The protocol syntax for the binary format of the protocol is defined
|
||
in Annex A. Annex C specifies the encoding of the Local and Remote
|
||
descriptors for use with the binary format.
|
||
|
||
A complete ABNF of the text encoding of the protocol per RFC 2234 is
|
||
given in Annex B. SDP is used as the encoding of the Local and
|
||
Remote descriptors for use with the text encoding as modified in
|
||
7.1.8.
|
||
|
||
7.3 Command Error Codes
|
||
|
||
Errors consist of an IANA registered error code and an explanatory
|
||
string. Sending the explanatory string is optional. Implementations
|
||
are encouraged to append diagnostic information to the end of the
|
||
string.
|
||
|
||
When a MG reports an error to a MGC, it does so in an error
|
||
descriptor. An error descriptor consists of an error code and
|
||
optionally the associated explanatory string.
|
||
|
||
H.248.8 contains the error codes supported by Recommendations in the
|
||
H.248 sub-series.
|
||
|
||
8 Transactions
|
||
|
||
Commands between the Media Gateway Controller and the Media Gateway
|
||
are grouped into Transactions, each of which is identified by a
|
||
TransactionID. Transactions consist of one or more Actions. An
|
||
Action consists of a non-empty series of Commands, Context property
|
||
modifications, or Context property audits that are limited to
|
||
operating within a single Context. Consequently, each Action
|
||
typically specifies a ContextID. However, there are two
|
||
circumstances where a specific ContextID is not provided with an
|
||
Action. One is the case of modification of a Termination outside of
|
||
a Context. The other is where the controller requests the gateway to
|
||
create a new Context. Figure 8 is a graphic representation of the
|
||
Transaction, Action and Command relationships.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 66]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
+----------------------------------------------------------+
|
||
| Transaction x |
|
||
| +----------------------------------------------------+ |
|
||
| | Action 1 | |
|
||
| | +---------+ +---------+ +---------+ +---------+ | |
|
||
| | | Command | | Command | | Command | | Command | | |
|
||
| | | 1 | | 2 | | 3 | | 4 | | |
|
||
| | +---------+ +---------+ +---------+ +---------+ | |
|
||
| +----------------------------------------------------+ |
|
||
| |
|
||
| +----------------------------------------------------+ |
|
||
| | Action 2 | |
|
||
| | +---------+ | |
|
||
| | | Command | | |
|
||
| | | 1 | | |
|
||
| | +---------+ | |
|
||
| +----------------------------------------------------+ |
|
||
| |
|
||
| +----------------------------------------------------+ |
|
||
| | Action 3 | |
|
||
| | +---------+ +---------+ +---------+ | |
|
||
| | | Command | | Command | | Command | | |
|
||
| | | 1 | | 2 | | 3 | | |
|
||
| | +---------+ +---------+ +---------+ | |
|
||
| +----------------------------------------------------+ |
|
||
+----------------------------------------------------------+
|
||
|
||
Figure 8: Transactions, Actions and Commands
|
||
|
||
Transactions are presented as TransactionRequests. Corresponding
|
||
responses to a TransactionRequest are received in a single reply,
|
||
possibly preceded by a number of TransactionPending messages (see
|
||
8.2.3).
|
||
|
||
Transactions guarantee ordered Command processing. That is, Commands
|
||
within a Transaction are executed sequentially. Ordering of
|
||
Transactions is NOT guaranteed - transactions may be executed in any
|
||
order, or simultaneously.
|
||
|
||
At the first failing Command in a Transaction, processing of the
|
||
remaining Commands in that Transaction stops. If a command contains
|
||
a wildcarded TerminationID, the command is attempted with each of the
|
||
actual TerminationIDs matching the wildcard. A response within the
|
||
TransactionReply is included for each matching TerminationID, even if
|
||
one or more instances generated an error. If any TerminationID
|
||
matching a wildcard results in an error when executed, any commands
|
||
following the wildcarded command are not attempted.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 67]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Commands may be marked as "Optional" which can override this
|
||
behaviour - if a command marked as Optional results in an error,
|
||
subsequent commands in the Transaction will be executed. If a
|
||
command fails, the MG shall as far as possible restore the state that
|
||
existed prior to the attempted execution of the command before
|
||
continuing with command processing.
|
||
|
||
A TransactionReply includes the results for all of the Commands in
|
||
the corresponding TransactionRequest. The TransactionReply includes
|
||
the return values for the Commands that were executed successfully,
|
||
and the Command and error descriptor for any Command that failed.
|
||
|
||
TransactionPending is used to periodically notify the receiver that a
|
||
Transaction has not completed yet, but is actively being processed.
|
||
|
||
Applications SHOULD implement an application level timer per
|
||
transaction. Expiration of the timer should cause a retransmission
|
||
of the request. Receipt of a Reply should cancel the timer. Receipt
|
||
of Pending should restart the timer.
|
||
|
||
8.1 Common parameters
|
||
|
||
8.1.1 Transaction Identifiers
|
||
|
||
Transactions are identified by a TransactionID, which is assigned by
|
||
sender and is unique within the scope of the sender. A response
|
||
containing an error descriptor to indicate that the TransactionID is
|
||
missing in a request shall use TransactionID 0 in the corresponding
|
||
TransactionReply.
|
||
|
||
8.1.2 Context Identifiers
|
||
|
||
Contexts are identified by a ContextID, which is assigned by the
|
||
Media Gateway and is unique within the scope of the Media Gateway.
|
||
The Media Gateway Controller shall use the ContextID supplied by the
|
||
Media Gateway in all subsequent Transactions relating to that
|
||
Context. The protocol makes reference to a distinguished value that
|
||
may be used by the Media Gateway Controller when referring to a
|
||
Termination that is currently not associated with a Context, namely
|
||
the null ContextID.
|
||
|
||
The CHOOSE wildcard is used to request that the Media Gateway create
|
||
a new Context.
|
||
|
||
The MGC may use the ALL wildcard to address all Contexts on the MG.
|
||
The null Context is not included when the ALL wildcard is used.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 68]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The MGC shall not use partially specified ContextIDs containing the
|
||
CHOOSE or ALL wildcards.
|
||
|
||
8.2 Transaction Application Programming Interface
|
||
|
||
Following is an Application Programming Interface (API) describing
|
||
the Transactions of the protocol. This API is shown to illustrate
|
||
the Transactions and their parameters and is not intended to specify
|
||
implementation (e.g., via use of blocking function calls). It will
|
||
describe the input parameters and return values expected to be used
|
||
by the various Transactions of the protocol from a very high level.
|
||
Transaction syntax and encodings are specified in later subclauses.
|
||
|
||
8.2.1 TransactionRequest
|
||
|
||
The TransactionRequest is invoked by the sender. There is one
|
||
Transaction per request invocation. A request contains one or more
|
||
Actions, each of which specifies its target Context and one or more
|
||
Commands per Context.
|
||
|
||
TransactionRequest(TransactionId {
|
||
ContextID {Command ... Command},
|
||
. . .
|
||
ContextID {Command ... Command } })
|
||
|
||
The TransactionID parameter must specify a value for later
|
||
correlation with the TransactionReply or TransactionPending response
|
||
from the receiver.
|
||
|
||
The ContextID parameter must specify a value to pertain to all
|
||
Commands that follow up to either the next specification of a
|
||
ContextID parameter or the end of the TransactionRequest, whichever
|
||
comes first.
|
||
|
||
The Command parameter represents one of the Commands mentioned in 7.2
|
||
(Command Application Programming Interface).
|
||
|
||
8.2.2 TransactionReply
|
||
|
||
The TransactionReply is invoked by the receiver. There is one reply
|
||
invocation per transaction. A reply contains one or more Actions,
|
||
each of which must specify its target Context and one or more
|
||
Responses per Context. The TransactionReply is invoked by the
|
||
responder when it has processed the TransactionRequest.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 69]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A TransactionRequest has been processed:
|
||
|
||
- when all actions in that TransactionRequest have been processed;
|
||
or
|
||
|
||
- when an error is encountered in processing that
|
||
TransactionRequest, except when the error is in an optional
|
||
command.
|
||
|
||
A command has been processed when all descriptors in that command
|
||
have been processed.
|
||
|
||
A SignalsDescriptor is considered to have been processed when it has
|
||
been established that the descriptor is syntactically valid, the
|
||
requested signals are supported and they have been queued to be
|
||
applied.
|
||
|
||
An EventsDescriptor or EventBufferDescriptor is considered to have
|
||
been processed when it has been established that the descriptor is
|
||
syntactically valid, the requested events can be observed, any
|
||
embedded signals can be generated, any embedded events can be
|
||
detected, and the MG has been brought into a state in which the
|
||
events will be detected.
|
||
|
||
TransactionReply(TransactionID {
|
||
ContextID { Response ... Response },
|
||
. . .
|
||
ContextID { Response ... Response } })
|
||
|
||
The TransactionID parameter must be the same as that of the
|
||
corresponding TransactionRequest.
|
||
|
||
The ContextID parameter must specify a value to pertain to all
|
||
Responses for the action. The ContextID may be specific, all or
|
||
null.
|
||
|
||
Each of the Response parameters represents a return value as
|
||
mentioned in 7.2, or an error descriptor if the command execution
|
||
encountered an error. Commands after the point of failure are not
|
||
processed and, therefore, Responses are not issued for them.
|
||
|
||
An exception to this occurs if a command has been marked as optional
|
||
in the Transaction request. If the optional command generates an
|
||
error, the transaction still continues to execute, so the Reply
|
||
would, in this case, have Responses after an Error.
|
||
|
||
Section 7.1.19 Error Descriptor specifies the generation of error
|
||
descriptors. The text below discusses several individual cases.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 70]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
If the receiver encounters an error in processing a ContextID, the
|
||
requested Action response will consist of the Context ID and a single
|
||
error descriptor, 422 - Syntax Error in Action.
|
||
|
||
If the receiver encounters an error such that it cannot determine a
|
||
legal Action, it will return a TransactionReply consisting of the
|
||
TransactionID and a single error descriptor, 422 - Syntax Error in
|
||
Action. If the end of an action cannot be reliably determined but
|
||
one or more commands can be parsed, it will process them and then
|
||
send 422 - Syntax Error in Action as the last action for the
|
||
transaction. If the receiver encounters an error such that is cannot
|
||
determine a legal Transaction, it will return a TransactionReply with
|
||
a null TransactionID and a single error descriptor (403 - Syntax
|
||
Error in TransactionRequest).
|
||
|
||
If the end of a transaction cannot be reliably determined and one or
|
||
more Actions can be parsed, it will process them and then return 403
|
||
- Syntax Error in Transaction as the last action reply for the
|
||
transaction. If no Actions can be parsed, it will return 403 -
|
||
Syntax Error in TransactionRequest as the only reply.
|
||
|
||
If the terminationID cannot be reliably determined, it will send 442
|
||
- Syntax Error in Command as the action reply.
|
||
|
||
If the end of a command cannot be reliably determined, it will return
|
||
442 - Syntax Error in Command as the reply to the last action it can
|
||
parse.
|
||
|
||
8.2.3 TransactionPending
|
||
|
||
The receiver invokes the TransactionPending. A TransactionPending
|
||
indicates that the Transaction is actively being processed, but has
|
||
not been completed. It is used to prevent the sender from assuming
|
||
the TransactionRequest was lost where the Transaction will take some
|
||
time to complete.
|
||
|
||
TransactionPending(TransactionID { } )
|
||
|
||
The TransactionID parameter must be the same as that of the
|
||
corresponding TransactionRequest. A property of root
|
||
(normalMGExecutionTime) is settable by the MGC to indicate the
|
||
interval within which the MGC expects a response to any transaction
|
||
from the MG. Another property (normalMGCExecutionTime) is settable
|
||
by the MGC to indicate the interval within which the MG should expect
|
||
a response to any transaction from the MGC. Senders may receive more
|
||
than one TransactionPending for a command. If a duplicate request is
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 71]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
received when pending, the responder may send a duplicate pending
|
||
immediately, or continue waiting for its timer to trigger another
|
||
TransactionPending.
|
||
|
||
8.3 Messages
|
||
|
||
Multiple Transactions can be concatenated into a Message. Messages
|
||
have a header, which includes the identity of the sender. The
|
||
Message Identifier (MID) of a message is set to a provisioned name
|
||
(e.g., domain address/domain name/device name) of the entity
|
||
transmitting the message. Domain name is a suggested default. An
|
||
H.248.1 entity (MG/MGC) must consistently use the same MID in all
|
||
messages it originates for the duration of control association with
|
||
the peer (MGC/MG).
|
||
|
||
Every Message contains a Version Number identifying the version of
|
||
the protocol the message conforms to. Versions consist of one or two
|
||
digits, beginning with version 1 for the present version of the
|
||
protocol.
|
||
|
||
The transactions in a message are treated independently. There is no
|
||
order implied; there is no application or protocol acknowledgement of
|
||
a message. A message is essentially a transport mechanism. For
|
||
example, message X containing transaction requests A, B, and C may be
|
||
responded to with message Y containing replies to A and C and message
|
||
Z containing the reply to B. Likewise, message L containing request
|
||
D and message M containing request E may be responded to with message
|
||
N containing replies to both D and E.
|
||
|
||
9 Transport
|
||
|
||
The transport mechanism for the protocol should allow the reliable
|
||
transport of transactions between a MGC and MG. The transport shall
|
||
remain independent of what particular commands are being sent and
|
||
shall be applicable to all application states. There are several
|
||
transports defined for the protocol, which are defined in Annexes to
|
||
this RFC and other Recommendations of the H.248
|
||
sub-series. Additional Transports may be defined as additional
|
||
|
||
Recommendations of the H.248 sub-series. For transport of the
|
||
protocol over IP, MGCs shall implement both TCP and UDP/ALF, a MG
|
||
shall implement TCP or UDP/ALF or both.
|
||
|
||
The MG is provisioned with a name or address (such as DNS name or IP
|
||
address) of a primary and zero or more secondary MGCs (see 7.2.8)
|
||
that is the address the MG uses to send messages to the MGC. If TCP
|
||
or UDP is used as the protocol transport and the port to which the
|
||
initial ServiceChange request is to be sent is not otherwise known,
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 72]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
that request should be sent to the default port number for the
|
||
protocol. This port number is 2944 for text-encoded operation or
|
||
2945 for binary-encoded operation, for either UDP or TCP. The MGC
|
||
receives the message containing the ServiceChange request from the MG
|
||
and can determine the MG's address from it. As described in 7.2.8,
|
||
either the MG or the MGC may supply an address in the
|
||
ServiceChangeAddress parameter to which subsequent transaction
|
||
requests must be addressed, but responses (including the response to
|
||
the initial ServiceChange request) must always be sent back to the
|
||
address which was the source of the corresponding request. For
|
||
example, in IP networks, this is the source address in the IP header
|
||
and the source port number in the TCP/UDP/SCTP header.
|
||
|
||
9.1 Ordering of Commands
|
||
|
||
This RFC does not mandate that the underlying transport protocol
|
||
guarantees the sequencing of transactions sent to an entity. This
|
||
property tends to maximize the timeliness of actions, but it has a
|
||
few drawbacks. For example:
|
||
|
||
- Notify commands may be delayed and arrive at the MGC after the
|
||
transmission of a new command changing the EventsDescriptor.
|
||
|
||
- If a new command is transmitted before a previous one is
|
||
acknowledged, there is no guarantee that prior command will be
|
||
executed before the new one.
|
||
|
||
Media Gateway Controllers that want to guarantee consistent operation
|
||
of the Media Gateway may use the following rules. These rules are
|
||
with respect to commands that are in different transactions.
|
||
Commands that are in the same transaction are executed in order (see
|
||
clause 8).
|
||
|
||
1) When a Media Gateway handles several Terminations, commands
|
||
pertaining to the different Terminations may be sent in parallel,
|
||
for example following a model where each Termination (or group of
|
||
Terminations) is controlled by its own process or its own thread.
|
||
|
||
2) On a Termination, there should normally be at most one outstanding
|
||
command (Add or Modify or Move), unless the outstanding commands
|
||
are in the same transaction. However, a Subtract command may be
|
||
issued at any time. In consequence, a Media Gateway may sometimes
|
||
receive a Modify command that applies to a previously subtracted
|
||
Termination. Such commands should be ignored, and an error code
|
||
should be returned.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 73]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
3) For transports that do not guarantee in-sequence delivery of
|
||
messages (i.e., UDP), there should normally be on a given
|
||
Termination at most one outstanding Notify command at any time.
|
||
|
||
4) In some cases, an implicitly or explicitly wildcarded Subtract
|
||
command that applies to a group of Terminations may step in front
|
||
of a pending Add command. The Media Gateway Controller should
|
||
individually delete all Terminations for which an Add command was
|
||
pending at the time of the global Subtract command. Also, new Add
|
||
commands for Terminations named by the wildcarding (or implied in
|
||
a Multiplex descriptor) should not be sent until the wildcarded
|
||
Subtract command is acknowledged.
|
||
|
||
5) AuditValue and AuditCapability are not subject to any sequencing.
|
||
|
||
6) ServiceChange shall always be the first command sent by a MG as
|
||
defined by the restart procedure. Any other command or response
|
||
must be delivered after this ServiceChange command.
|
||
|
||
These rules do not affect the command responder, which should always
|
||
respond to commands.
|
||
|
||
9.2 Protection against Restart Avalanche
|
||
|
||
In the event that a large number of Media Gateways are powered on
|
||
simultaneously and they were to all initiate a ServiceChange
|
||
transaction, the Media Gateway Controller would very likely be
|
||
swamped, leading to message losses and network congestion during the
|
||
critical period of service restoration. In order to prevent such
|
||
avalanches, the following behaviour is suggested:
|
||
|
||
1) When a Media Gateway is powered on, it should initiate a restart
|
||
timer to a random value, uniformly distributed between 0 and a
|
||
maximum waiting delay (MWD). Care should be taken to avoid
|
||
synchronicity of the random number generation between multiple
|
||
Media Gateways that would use the same algorithm.
|
||
|
||
2) The Media Gateway should then wait for either the end of this
|
||
timer or the detection of a local user activity, such as for
|
||
example an off-hook transition on a residential Media Gateway.
|
||
|
||
3) When the timer elapses, or when an activity is detected, the Media
|
||
Gateway should initiate the restart procedure.
|
||
|
||
The restart procedure simply requires the MG to guarantee that the
|
||
first message that the Media Gateway Controller sees from this MG is
|
||
a ServiceChange message informing the Media Gateway Controller about
|
||
the restart.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 74]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
NOTE - The value of MWD is a configuration parameter that depends
|
||
on the type of the Media Gateway. The following reasoning may be
|
||
used to determine the value of this delay on residential gateways.
|
||
|
||
Media Gateway Controllers are typically dimensioned to handle the
|
||
peak hour traffic load, during which, in average, 10% of the lines
|
||
will be busy, placing calls whose average duration is typically 3
|
||
minutes. The processing of a call typically involves 5 to 6 Media
|
||
Gateway Controller transactions between each Media Gateway and the
|
||
Media Gateway Controller. This simple calculation shows that the
|
||
Media Gateway Controller is expected to handle 5 to 6 transactions
|
||
for each Termination, every 30 minutes on average, or, to put it
|
||
otherwise, about one transaction per Termination every 5 to 6 minutes
|
||
on average. This suggests that a reasonable value of MWD for a
|
||
residential gateway would be 10 to 12 minutes. In the absence of
|
||
explicit configuration, residential gateways should adopt a value of
|
||
600 seconds for MWD.
|
||
|
||
The same reasoning suggests that the value of MWD should be much
|
||
shorter for trunking gateways or for business gateways, because they
|
||
handle a large number of Terminations, and also because the usage
|
||
rate of these Terminations is much higher than 10% during the peak
|
||
busy hour, a typical value being 60%. These Terminations, during the
|
||
peak hour, are this expected to contribute about one transaction per
|
||
minute to the Media Gateway Controller load. A reasonable algorithm
|
||
is to make the value of MWD per "trunk" Termination six times shorter
|
||
than the MWD per residential gateway, and also inversely proportional
|
||
to the number of Terminations that are being restarted. For example
|
||
MWD should be set to 2.5 seconds for a gateway that handles a T1
|
||
line, or to 60 milliseconds for a gateway that handles a T3 line.
|
||
|
||
10 Security Considerations
|
||
|
||
This clause covers security when using the protocol in an IP
|
||
environment.
|
||
|
||
10.1 Protection of Protocol Connections
|
||
|
||
A security mechanism is clearly needed to prevent unauthorized
|
||
entities from using the protocol defined in this RFC for setting up
|
||
unauthorized calls or interfering with authorized calls. The
|
||
security mechanism for the protocol when transported over IP networks
|
||
is IPsec [RFC 2401 to RFC 2411].
|
||
|
||
The AH header [RFC 2402] affords data origin authentication,
|
||
connectionless integrity and optional anti-replay protection of
|
||
messages passed between the MG and the MGC. The ESP header [RFC
|
||
2406] provides confidentiality of messages, if desired. For
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 75]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
instance, the ESP encryption service should be requested if the
|
||
session descriptions are used to carry session keys, as defined in
|
||
SDP.
|
||
|
||
Implementations of the protocol defined in this RFC employing the ESP
|
||
header SHALL comply with section 5 of [RFC 2406], which defines a
|
||
minimum set of algorithms for integrity checking and encryption.
|
||
Similarly, implementations employing the AH header SHALL comply with
|
||
section 5 of [RFC 2402], which defines a minimum set of algorithms
|
||
for integrity checking using manual keys.
|
||
|
||
Implementations SHOULD use IKE [RFC 2409] to permit more robust
|
||
keying options. Implementations employing IKE SHOULD support
|
||
authentication with RSA signatures and RSA public key encryption.
|
||
|
||
10.2 Interim AH scheme
|
||
|
||
Implementation of IPsec requires that the AH or ESP header be
|
||
inserted immediately after the IP header. This cannot be easily done
|
||
at the application level. Therefore, this presents a deployment
|
||
problem for the protocol defined in this RFC where the underlying
|
||
network implementation does not support IPsec.
|
||
|
||
As an interim solution, an optional AH header is defined within the
|
||
H.248.1 protocol header. The header fields are exactly those of the
|
||
SPI, SEQUENCE NUMBER and DATA fields as defined in [RFC 2402]. The
|
||
semantics of the header fields are the same as the "transport mode"
|
||
of [RFC 2402], except for the calculation of the Integrity Check
|
||
Value (ICV). In IPsec, the ICV is calculated over the entire IP
|
||
packet including the IP header. This prevents spoofing of the IP
|
||
addresses. To retain the same functionality, the ICV calculation
|
||
should be performed across all the transactions (concatenated) in the
|
||
message prepended by a synthesized IP header consisting of a 32-bit
|
||
source IP address, a 32-bit destination address and a 16-bit UDP
|
||
destination port encoded as 20 hex digits. When the interim AH
|
||
mechanism is employed when TCP is the transport Layer, the UDP Port
|
||
above becomes the TCP port, and all other operations are the same.
|
||
|
||
Implementations of the H.248.1 protocol SHALL implement IPsec where
|
||
the underlying operating system and the transport network supports
|
||
IPsec. Implementations of the protocol using IPv4 SHALL implement
|
||
the interim AH scheme. However, this interim scheme SHALL NOT be
|
||
used when the underlying network layer supports IPsec. IPv6
|
||
implementations are assumed to support IPsec and SHALL NOT use the
|
||
interim AH scheme.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 76]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
All implementations of the interim AH mechanism SHALL comply with
|
||
section 5 of RFC 2402 which defines a minimum set of algorithms for
|
||
integrity checking using manual keys.
|
||
|
||
The interim AH interim scheme does not provide protection against
|
||
eavesdropping, thus forbidding third parties from monitoring the
|
||
connections set up by a given Termination. Also, it does not provide
|
||
protection against replay attacks. These procedures do not
|
||
necessarily protect against denial of service attacks by misbehaving
|
||
MGs or misbehaving MGCs. However, they will provide an
|
||
identification of these misbehaving entities, which should then be
|
||
deprived of their authorization through maintenance procedures.
|
||
|
||
10.3 Protection of Media Connections
|
||
|
||
The protocol allows the MGC to provide MGs with "session keys" that
|
||
can be used to encrypt the audio messages, protecting against
|
||
eavesdropping.
|
||
|
||
A specific problem of packet networks is "uncontrolled barge-in".
|
||
This attack can be performed by directing media packets to the IP
|
||
address and UDP port used by a connection. If no protection is
|
||
implemented, the packets must be decompressed and the signals must be
|
||
played on the "line side".
|
||
|
||
A basic protection against this attack is to only accept packets from
|
||
known sources, checking for example that the IP source address and
|
||
UDP source port match the values announced in the Remote descriptor.
|
||
This has two inconveniences: it slows down connection establishment
|
||
and it can be fooled by source spoofing:
|
||
|
||
- To enable the address-based protection, the MGC must obtain the
|
||
remote session description of the egress MG and pass it to the
|
||
ingress MG. This requires at least one network round trip, and
|
||
leaves us with a dilemma: either allow the call to proceed without
|
||
waiting for the round trip to complete, and risk for example,
|
||
"clipping" a remote announcement, or wait for the full round trip
|
||
and settle for slower call-set up procedures.
|
||
|
||
- Source spoofing is only effective if the attacker can obtain valid
|
||
pairs of source destination addresses and ports, for example by
|
||
listening to a fraction of the traffic. To fight source spoofing,
|
||
one could try to control all access points to the network. But
|
||
this is in practice very hard to achieve.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 77]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
An alternative to checking the source address is to encrypt and
|
||
authenticate the packets, using a secret key that is conveyed during
|
||
the call set-up procedure. This will not slow down the call set-up,
|
||
and provides strong protection against address spoofing.
|
||
|
||
11 MG-MGC Control Interface
|
||
|
||
The control association between MG and MGC is initiated at MG cold
|
||
start, and announced by a ServiceChange message, but can be changed
|
||
by subsequent events, such as failures or manual service events.
|
||
While the protocol does not have an explicit mechanism to support
|
||
multiple MGCs controlling a physical MG, it has been designed to
|
||
support the multiple logical MG (within a single physical MG) that
|
||
can be associated with different MGCs.
|
||
|
||
11.1 Multiple Virtual MGs
|
||
|
||
A physical Media Gateway may be partitioned into one or more Virtual
|
||
MGs. A virtual MG consists of a set of statically partitioned
|
||
physical Terminations and/or sets of ephemeral Terminations. A
|
||
physical Termination is controlled by one MGC. The model does not
|
||
require that other resources be statically allocated, just
|
||
Terminations. The mechanism for allocating Terminations to virtual
|
||
MGs is a management method outside the scope of the protocol. Each
|
||
of the virtual MGs appears to the MGC as a complete MG client.
|
||
|
||
A physical MG may have only one network interface, which must be
|
||
shared across virtual MGs. In such a case, the packet/cell side
|
||
Termination is shared. It should be noted however, that in use, such
|
||
interfaces require an ephemeral instance of the Termination to be
|
||
created per flow, and thus sharing the Termination is
|
||
straightforward. This mechanism does lead to a complication, namely
|
||
that the MG must always know which of its controlling MGCs should be
|
||
notified if an event occurs on the interface.
|
||
|
||
In normal operation, the Virtual MG will be instructed by the MGC to
|
||
create network flows (if it is the originating side), or to expect
|
||
flow requests (if it is the terminating side), and no confusion will
|
||
arise. However, if an unexpected event occurs, the Virtual MG must
|
||
know what to do with respect to the physical resources it is
|
||
controlling.
|
||
|
||
If recovering from the event requires manipulation of a physical
|
||
interface's state, only one MGC should do so. These issues are
|
||
resolved by allowing any of the MGCs to create EventsDescriptors to
|
||
be notified of such events, but only one MGC can have read/write
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 78]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
access to the physical interface properties; all other MGCs have
|
||
read-only access. The management mechanism is used to designate
|
||
which MGC has read/write capability, and is designated the Master
|
||
MGC.
|
||
|
||
Each virtual MG has its own Root Termination. In most cases the
|
||
values for the properties of the Root Termination are independently
|
||
settable by each MGC. Where there can only be one value, the
|
||
parameter is read-only to all but the Master MGC.
|
||
|
||
ServiceChange may only be applied to a Termination or set of
|
||
Terminations partitioned to the Virtual MG or created (in the case of
|
||
ephemeral Terminations) by that Virtual MG.
|
||
|
||
11.2 Cold start
|
||
|
||
A MG is pre-provisioned by a management mechanism outside the scope
|
||
of this protocol with a primary and (optionally) an ordered list of
|
||
secondary MGCs. Upon a cold start of the MG, it will issue a
|
||
ServiceChange command with a "Restart" method, on the Root
|
||
Termination to its primary MGC. If the MGC accepts the MG, it sends
|
||
a Transaction Reply not including a ServiceChangeMgcId parameter. If
|
||
the MGC does not accept the MG's registration, it sends a Transaction
|
||
Reply, providing the address of an alternate MGC to be contacted by
|
||
including a ServiceChangeMgcId parameter.
|
||
|
||
If the MG receives a Transaction Reply that includes a
|
||
ServiceChangeMgcId parameter, it sends a ServiceChange to the MGC
|
||
specified in the ServiceChangeMgcId. It continues this process until
|
||
it gets a controlling MGC to accept its registration, or it fails to
|
||
get a reply. Upon failure to obtain a reply, either from the primary
|
||
MGC, or a designated successor, the MG tries its pre-provisioned
|
||
secondary MGCs, in order. If the MG is unable to establish a control
|
||
relationship with any MGC, it shall wait a random amount of time as
|
||
described in 9.2 and then start contacting its primary, and if
|
||
necessary, its secondary MGCs again.
|
||
|
||
It is possible that the reply to a ServiceChange with Restart will be
|
||
lost, and a command will be received by the MG prior to the receipt
|
||
of the ServiceChange response. The MG shall issue Error 505 -
|
||
Command Received before a ServiceChange Reply has been received.
|
||
|
||
11.3 Negotiation of protocol version
|
||
|
||
The first ServiceChange command from a MG shall contain the version
|
||
number of the protocol supported by the MG in the
|
||
ServiceChangeVersion parameter. Upon receiving such a message, if
|
||
the MGC supports only a lower version, then the MGC shall send a
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 79]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ServiceChangeReply with the lower version and thereafter all the
|
||
messages between MG and MGC shall conform to the lower version of the
|
||
protocol. If the MG is unable to comply and it has established a
|
||
transport connection to the MGC, it should close that connection. In
|
||
any event, it should reject all subsequent requests from the MGC with
|
||
error 406 - Version Not Supported.
|
||
|
||
If the MGC supports a higher version than the MG but is able to
|
||
support the lower version proposed by the MG, it shall send a
|
||
ServiceChangeReply with the lower version and thereafter all the
|
||
messages between MG and MGC shall conform to the lower version of the
|
||
protocol. If the MGC is unable to comply, it shall reject the
|
||
association, with error 406 - Version Not Supported.
|
||
|
||
Protocol version negotiation may also occur at "handoff" and
|
||
"failover" ServiceChanges.
|
||
|
||
When extending the protocol with new versions, the following rules
|
||
should be followed:
|
||
|
||
1) Existing protocol elements, i.e., procedures, parameters,
|
||
descriptor, property, values, should not be changed unless a
|
||
protocol error needs to be corrected or it becomes necessary to
|
||
change the operation of the service that is being supported by the
|
||
protocol.
|
||
|
||
2) The semantics of a command, a parameter, a descriptor, a property,
|
||
or a value should not be changed.
|
||
|
||
3) Established rules for formatting and encoding messages and
|
||
parameters should not be modified.
|
||
|
||
4) When information elements are found to be obsolete they can be
|
||
marked as not used. However, the identifier for that information
|
||
element will be marked as reserved. In that way it can not be
|
||
used in future versions.
|
||
|
||
11.4 Failure of a MG
|
||
|
||
If a MG fails, but is capable of sending a message to the MGC, it
|
||
sends a ServiceChange with an appropriate method (graceful or forced)
|
||
and specifies the Root TerminationID. When it returns to service, it
|
||
sends a ServiceChange with a "Restart" method.
|
||
|
||
Allowing the MGC to send duplicate messages to both MGs accommodates
|
||
pairs of MGs that are capable of redundant failover of one of the
|
||
MGs. Only the Working MG shall accept or reject transactions. Upon
|
||
failover, the primary MG sends a ServiceChange command with a
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 80]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
"Failover" method and a "MG Impending Failure" reason. The MGC then
|
||
uses the secondary MG as the active MG. When the error condition is
|
||
repaired, the Working MG can send a "ServiceChange" with a "Restart"
|
||
method.
|
||
|
||
Note: Redundant failover MGs require a reliable transport, because
|
||
the protocol provides no means for a secondary MG running ALF to
|
||
acknowledge messages sent from the MGC.
|
||
|
||
11.5 Failure of an MGC
|
||
|
||
If the MG detects a failure of its controlling MGC, it attempts to
|
||
contact the next MGC on its pre-provisioned list. It starts its
|
||
attempts at the beginning (primary MGC), unless that was the MGC that
|
||
failed, in which case it starts at its first secondary MGC. It sends
|
||
a ServiceChange message with a "Failover" method and a "MGC Impending
|
||
Failure" reason. If the MG is unable to establish a control
|
||
relationship with any MGC, it shall wait a random amount of time as
|
||
described in section 9.2 and then start again contacting its primary,
|
||
and (if necessary) its secondary MGCs. When contacting its
|
||
previously controlling MGC, the MG sends the ServiceChange message
|
||
with "Disconnected" method.
|
||
|
||
In partial failure, or for manual maintenance reasons, an MGC may
|
||
wish to direct its controlled MGs to use a different MGC. To do so,
|
||
it sends a ServiceChange method to the MG with a "HandOff" method,
|
||
and its designated replacement in ServiceChangeMgcId. If "HandOff"
|
||
is supported, the MG shall send a ServiceChange message with a
|
||
"Handoff" method and a "MGC directed change" reason to the designated
|
||
MGC. If it fails to get a reply from the designated MGC, the MG
|
||
shall behave as if its MGC failed, and start contacting secondary
|
||
MGCs as specified in the previous paragraph. If the MG is unable to
|
||
establish a control relationship with any MGC, it shall wait a random
|
||
amount of time as described in 9.2 and then start contacting its
|
||
primary, and if necessary, its secondary MGCs again.
|
||
|
||
No recommendation is made on how the MGCs involved in the Handoff
|
||
maintain state information; this is considered to be out of scope of
|
||
this RFC. The MGC and MG may take the following steps when Handoff
|
||
occurs. When the MGC initiates a HandOff, the handover should be
|
||
transparent to Operations on the Media Gateway. Transactions can be
|
||
executed in any order, and could be in progress when the
|
||
ServiceChange is executed. Accordingly, commands in progress
|
||
continue and replies to all commands from the original MGC must be
|
||
sent to the transport address from which they were sent. If the
|
||
service relationship with the sending MGC has ended, the replies
|
||
should be discarded. The MG may receive outstanding transaction
|
||
replies from the new MGC. No new messages shall be sent to the new
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 81]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
MGC until the control association is established. Repeated
|
||
transaction requests shall be directed to the new MGC. The MG shall
|
||
maintain state on all Terminations and Contexts.
|
||
|
||
It is possible that the MGC could be implemented in such a way that a
|
||
failed MGC is replaced by a working MGC where the identity of the new
|
||
MGC is the same as the failed one. In such a case,
|
||
ServiceChangeMgcId would be specified with the previous value and the
|
||
MG shall behave as if the value was changed, and send a ServiceChange
|
||
message, as above.
|
||
|
||
Pairs of MGCs that are capable of redundant failover can notify the
|
||
controlled MGs of the failover by the above mechanism.
|
||
|
||
12 Package definition
|
||
|
||
The primary mechanism for extension is by means of Packages.
|
||
Packages define additional Properties, Events, Signals and Statistics
|
||
that may occur on Terminations.
|
||
|
||
Packages defined by IETF will appear in separate RFCs.
|
||
|
||
Packages defined by ITU-T may appear in the relevant Recommendations
|
||
(e.g., as Recommendations of the H.248 sub-series).
|
||
|
||
1) A public document or a standard forum document, which can be
|
||
referenced as the document that describes the package following
|
||
the guideline above, should be specified.
|
||
|
||
2) The document shall specify the version of the Package that it
|
||
describes.
|
||
|
||
3) The document should be available on a public web server and should
|
||
have a stable URL. The site should provide a mechanism to provide
|
||
comments and appropriate responses should be returned.
|
||
|
||
12.1 Guidelines for defining packages
|
||
|
||
Packages define Properties, Events, Signals, and Statistics.
|
||
|
||
Packages may also define new error codes according to the guidelines
|
||
given in 13.2. This is a matter of documentary convenience: the
|
||
package documentation is submitted to IANA in support of the error
|
||
code registration. If a package is modified, it is unnecessary to
|
||
provide IANA with a new document reference in support of the error
|
||
code unless the description of the error code itself is modified.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 82]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Names of all such defined constructs shall consist of the PackageID
|
||
(which uniquely identifies the package) and the ID of the item (which
|
||
uniquely identifies the item in that package). In the text encoding
|
||
the two shall be separated by a forward slash ("/") character.
|
||
Example: togen/playtone is the text encoding to refer to the play
|
||
tone signal in the tone generation package.
|
||
|
||
A Package will contain the following sections:
|
||
|
||
12.1.1 Package
|
||
|
||
Overall description of the package, specifying:
|
||
|
||
Package Name: only descriptive
|
||
|
||
PackageID: is an identifier
|
||
|
||
Description:
|
||
|
||
Version:
|
||
|
||
A new version of a package can only add additional Properties,
|
||
Events, Signals, Statistics and new possible values for an
|
||
existing parameter described in the original package. No
|
||
deletions or modifications shall be allowed. A version is an
|
||
integer in the range from 1 to 99.
|
||
|
||
Designed to be extended only (Optional):
|
||
|
||
This indicates that the package has been expressly designed to
|
||
be extended by others, not to be directly referenced. For
|
||
example, the package may not have any function on its own or be
|
||
nonsensical on its own. The MG SHOULD NOT publish this
|
||
PackageID when reporting packages.
|
||
|
||
Extends (Optional): existing package Descriptor
|
||
|
||
A package may extend an existing package. The version of the
|
||
original package must be specified. When a package extends
|
||
another package it shall only add additional Properties,
|
||
Events, Signals, Statistics and new possible values for an
|
||
existing parameter described in the original package. An
|
||
extended package shall not redefine or overload an identifier
|
||
defined in the original package and packages it may have
|
||
extended (multiple levels of extension). Hence, if package B
|
||
version 1 extends package A version 1, version 2 of B will not
|
||
be able to extend the A version 2 if A version 2 defines a name
|
||
already in B version 1.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 83]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
12.1.2 Properties
|
||
|
||
Properties defined by the package, specifying:
|
||
|
||
Property Name: only descriptive
|
||
|
||
PropertyID: is an identifier
|
||
|
||
Description:
|
||
|
||
Type: One of:
|
||
|
||
Boolean
|
||
|
||
String: UTF-8 string
|
||
|
||
Octet String: A number of octets. See Annex A and Annex B.3
|
||
for encoding
|
||
|
||
Integer: 4 byte signed integer
|
||
|
||
Double: 8 byte signed integer
|
||
|
||
Character: unicode UTF-8 encoding of a single letter. Could be
|
||
more than one octet.
|
||
|
||
Enumeration: one of a list of possible unique values (see 12.3)
|
||
|
||
Sub-list: a list of several values from a list. The type of
|
||
sub-list SHALL also be specified. The type shall be chosen
|
||
from the types specified in this section (with the exception of
|
||
sub-list). For example, Type: sub-list of enumeration. The
|
||
encoding of sub-lists is specified in Annexes A and B.3.
|
||
|
||
Possible values:
|
||
|
||
A package MUST specify either a specific set of values or a
|
||
description of how values are determined. A package MUST also
|
||
specify a default value or the default behaviour when the value
|
||
is omitted from its descriptor. For example, a package may
|
||
specify that procedures related to the property are suspended
|
||
when its value is omitted. A default value (but not
|
||
procedures)
|
||
may be specified as provisionable.
|
||
|
||
Defined in:
|
||
|
||
Which H.248.1 descriptor the property is defined in.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 84]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
LocalControl is for stream dependent properties.
|
||
TerminationState is for stream independent properties. These
|
||
are expected to be the most common cases, but it is possible
|
||
for properties to be defined in other descriptors.
|
||
|
||
Characteristics: Read/Write or both, and (optionally), global:
|
||
|
||
Indicates whether a property is read-only, or read-write, and
|
||
if it is global. If Global is omitted, the property is not
|
||
global. If a property is declared as global, the value of the
|
||
property is shared by all Terminations realizing the package.
|
||
|
||
12.1.3 Events
|
||
|
||
Events defined by the package, specifying:
|
||
|
||
Event name: only descriptive
|
||
|
||
EventID: is an identifier
|
||
|
||
Description:
|
||
|
||
EventsDescriptor Parameters:
|
||
|
||
Parameters used by the MGC to configure the event, and found in
|
||
the EventsDescriptor. See 12.2.
|
||
|
||
ObservedEventsDescriptor Parameters:
|
||
|
||
Parameters returned to the MGC in Notify requests and in
|
||
replies to command requests from the MGC that audit
|
||
ObservedEventsDescriptor, and found in the
|
||
ObservedEventsDescriptor. See 12.2.
|
||
|
||
12.1.4 Signals
|
||
|
||
Signals defined by the package, specifying:
|
||
|
||
Signal Name: only descriptive
|
||
|
||
SignalID: is an identifier. SignalID is used in a
|
||
SignalsDescriptor
|
||
|
||
Description
|
||
|
||
SignalType: one of:
|
||
|
||
OO (On/Off)
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 85]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
TO (TimeOut)
|
||
|
||
BR (Brief)
|
||
|
||
NOTE - SignalType may be defined such that it is dependent on the
|
||
value of one or more parameters. The package MUST specify a
|
||
default signal type. If the default type is TO, the package MUST
|
||
specify a default duration which may be provisioned. A default
|
||
duration is meaningless for BR.
|
||
|
||
Duration: in hundredths of seconds
|
||
|
||
Additional Parameters: see 12.2
|
||
|
||
12.1.5 Statistics
|
||
|
||
Statistics defined by the package, specifying:
|
||
|
||
Statistic name: only descriptive
|
||
|
||
StatisticID: is an identifier
|
||
|
||
StatisticID is used in a StatisticsDescriptor
|
||
|
||
Description:
|
||
|
||
Units: unit of measure, e.g., milliseconds, packets
|
||
|
||
12.1.6 Procedures
|
||
|
||
Additional guidance on the use of the package.
|
||
|
||
12.2 Guidelines to defining Parameters to Events and Signals
|
||
|
||
Parameter Name: only descriptive
|
||
|
||
ParameterID: is an identifier. The textual ParameterID of parameters
|
||
to Events and Signals shall not start with "EPA" and "SPA",
|
||
respectively. The textual ParameterID shall also not be "ST",
|
||
"Stream", "SY", "SignalType", "DR", "Duration", "NC",
|
||
"NotifyCompletion", "KA", "Keepactive", "EB", "Embed", "DM" or
|
||
"DigitMap".
|
||
|
||
Type: One of:
|
||
|
||
Boolean
|
||
|
||
String: UTF-8 octet string
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 86]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Octet String: A number of octets. See Annex A and Annex B.3 for
|
||
encoding
|
||
|
||
Integer: 4-octet signed integer
|
||
|
||
Double: 8-octet signed integer
|
||
|
||
Character: unicode UTF-8 encoding of a single letter. Could be
|
||
more than one octet.
|
||
|
||
Enumeration: one of a list of possible unique values (see 12.3)
|
||
|
||
Sub-list: a list of several values from a list (not supported for
|
||
statistics). The type of sub-list SHALL also be specified. The
|
||
type shall be chosen from the types specified in this section
|
||
(with the exception of sub-list). For example, Type: sub-list of
|
||
enumeration. The encoding of sub-lists is specified in Annexes A
|
||
and B.3.
|
||
|
||
Possible values:
|
||
|
||
A package MUST specify either a specific set of values or a
|
||
description of how values are determined. A package MUST also
|
||
specify a default value or the default behavior when the value is
|
||
omitted from its descriptor. For example, a package may specify
|
||
that procedures related to the parameter are suspended when it
|
||
value is omitted. A default value (but not procedures) may be
|
||
specified as provisionable.
|
||
|
||
Description:
|
||
|
||
12.3 Lists
|
||
|
||
Possible values for parameters include enumerations. Enumerations
|
||
may be defined in a list. It is recommended that the list be IANA
|
||
registered so that packages that extend the list can be defined
|
||
without concern for conflicting names.
|
||
|
||
12.4 Identifiers
|
||
|
||
Identifiers in text encoding shall be strings of up to 64 characters,
|
||
containing no spaces, starting with an alphabetic character and
|
||
consisting of alphanumeric characters and/or digits, and possibly
|
||
including the special character underscore ("_").
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 87]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Identifiers in binary encoding are 2 octets long.
|
||
|
||
Both text and binary values shall be specified for each identifier,
|
||
including identifiers used as values in enumerated types.
|
||
|
||
12.5 Package registration
|
||
|
||
A package can be registered with IANA for interoperability reasons.
|
||
See clause 13 for IANA Considerations.
|
||
|
||
13 IANA Considerations
|
||
|
||
13.1 Packages
|
||
|
||
The following considerations SHALL be met to register a package with
|
||
IANA:
|
||
|
||
1) A unique string name, unique serial number and version number is
|
||
registered for each package. The string name is used with text
|
||
encoding. The serial number shall be used with binary encoding.
|
||
Serial Numbers 0x8000 to 0xFFFF are reserved for private use.
|
||
Serial number 0 is reserved.
|
||
|
||
2) A contact name, email and postal addresses for that contact shall
|
||
be specified. The contact information shall be updated by the
|
||
defining organization as necessary.
|
||
|
||
3) A reference to a document that describes the package, which should
|
||
be public:
|
||
|
||
The document shall specify the version of the Package that it
|
||
describes.
|
||
|
||
If the document is public, it should be located on a public web
|
||
server and should have a stable URL. The site should provide a
|
||
mechanism to provide comments and appropriate responses should be
|
||
returned.
|
||
|
||
4) Packages registered by other than recognized standards bodies
|
||
shall have a minimum package name length of 8 characters.
|
||
|
||
5) All other package names are first come-first served if all other
|
||
conditions are met.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 88]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
13.2 Error codes
|
||
|
||
The following considerations SHALL be met to register an error code
|
||
with IANA:
|
||
|
||
1) An error number and a one-line (80-character maximum) string is
|
||
registered for each error.
|
||
|
||
2) A complete description of the conditions under which the error is
|
||
detected shall be included in a publicly available document. The
|
||
description shall be sufficiently clear to differentiate the error
|
||
from all other existing error codes.
|
||
|
||
3) The document should be available on a public web server and should
|
||
have a stable URL.
|
||
|
||
4) Error numbers registered by recognized standards bodies shall have
|
||
3- or 4-character error numbers.
|
||
|
||
5) Error numbers registered by all other organizations or individuals
|
||
shall have 4-character error numbers.
|
||
|
||
6) An error number shall not be redefined nor modified except by the
|
||
organization or individual that originally defined it, or their
|
||
successors or assigns.
|
||
|
||
13.3 ServiceChange reasons
|
||
|
||
The following considerations SHALL be met to register service change
|
||
reason with IANA:
|
||
|
||
1) A one-phrase, 80-character maximum, unique reason code is
|
||
registered for each reason.
|
||
|
||
2) A complete description of the conditions under which the reason is
|
||
used is detected shall be included in a publicly available
|
||
document. The description shall be sufficiently clear to
|
||
differentiate the reason from all other existing reasons.
|
||
|
||
3) The document should be available on a public web server and should
|
||
have a stable URL.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 89]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ANNEX A - Binary encoding of the protocol
|
||
|
||
This annex specifies the syntax of messages using the notation
|
||
defined in Recommendation X.680; Information technology - Abstract
|
||
Syntax Notation One (ASN.1): Specification of basic notation.
|
||
Messages shall be encoded for transmission by applying the basic
|
||
encoding rules specified in Recommendation X.690, Information
|
||
Technology - ASN.1 Encoding Rules: Specification of Basic Encoding
|
||
Rules (BER), Canonical Encoding Rules (CER) and Distinguished
|
||
Encoding Rules.
|
||
|
||
A.1 Coding of wildcards
|
||
|
||
The use of wildcards ALL and CHOOSE is allowed in the protocol. This
|
||
allows a MGC to partially specify Termination IDs and to let the MG
|
||
choose from the values that conform to the partial specification.
|
||
Termination IDs may encode a hierarchy of names. This hierarchy is
|
||
provisioned. For instance, a TerminationID may consist of a trunk
|
||
group, a trunk within the group and a circuit. Wildcarding must be
|
||
possible at all levels. The following paragraphs explain how this is
|
||
achieved.
|
||
|
||
The ASN.1 description uses octet strings of up to 8 octets in length
|
||
for Termination IDs. This means that Termination IDs consist of at
|
||
most 64 bits. A fully specified Termination ID may be preceded by a
|
||
sequence of wildcarding fields. A wildcarding field is one octet in
|
||
length. Bit 7 (the most significant bit) of this octet specifies
|
||
what type of wildcarding is invoked: if the bit value equals 1, then
|
||
the ALL wildcard is used; if the bit value if 0, then the CHOOSE
|
||
wildcard is used. Bit 6 of the wildcarding field specifies whether
|
||
the wildcarding pertains to one level in the hierarchical naming
|
||
scheme (bit value 0) or to the level of the hierarchy specified in
|
||
the wildcarding field plus all lower levels (bit value 1). Bits 0
|
||
through 5 of the wildcarding field specify the bit position in the
|
||
Termination ID at which the wildcarding starts.
|
||
|
||
We illustrate this scheme with some examples. In these examples, the
|
||
most significant bit in a string of bits appears on the left hand
|
||
side.
|
||
|
||
Assume that Termination IDs are three octets long and that each octet
|
||
represents a level in a hierarchical naming scheme. A valid
|
||
Termination ID is:
|
||
|
||
00000001 00011110 01010101.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 90]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Addressing ALL names with prefix 00000001 00011110 is done as
|
||
follows:
|
||
|
||
wildcarding field: 10000111
|
||
|
||
Termination ID: 00000001 00011110 xxxxxxxx.
|
||
|
||
The values of the bits labeled "x" is irrelevant and shall be ignored
|
||
by the receiver.
|
||
|
||
Indicating to the receiver that it must choose a name with 00011110
|
||
as the second octet is done as follows:
|
||
|
||
wildcarding fields: 00010111 followed by 00000111
|
||
|
||
Termination ID: xxxxxxxx 00011110 xxxxxxxx.
|
||
|
||
The first wildcard field indicates a CHOOSE wildcard for the level in
|
||
the naming hierarchy starting at bit 23, the highest level in our
|
||
assumed naming scheme. The second wildcard field indicates a CHOOSE
|
||
wildcard for the level in the naming hierarchy starting at bit 7, the
|
||
lowest level in our assumed naming scheme.
|
||
|
||
Finally, a CHOOSE-wildcarded name with the highest level of the name
|
||
equal to 00000001 is specified as follows:
|
||
|
||
wildcard field: 01001111
|
||
|
||
Termination ID: 0000001 xxxxxxxx xxxxxxxx .
|
||
|
||
Bit value 1 at bit position 6 of the first octet of the wildcard
|
||
field indicates that the wildcarding pertains to the specified level
|
||
in the naming hierarchy and all lower levels.
|
||
|
||
Context IDs may also be wildcarded. In the case of Context IDs,
|
||
however, specifying partial names is not allowed. Context ID 0x0
|
||
SHALL be used to indicate the NULL Context, Context ID 0xFFFFFFFE
|
||
SHALL be used to indicate a CHOOSE wildcard, and Context ID
|
||
0xFFFFFFFF SHALL be used to indicate an ALL wildcard.
|
||
|
||
TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
|
||
Termination.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 91]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A.2 ASN.1 syntax specification
|
||
|
||
This subclause contains the ASN.1 specification of the H.248.1
|
||
protocol syntax.
|
||
|
||
NOTE 1 - In case a transport mechanism is used that employs
|
||
application level framing, the definition of Transaction below
|
||
changes. Refer to the annex or to the Recommendation of the H.248
|
||
sub-series defining the transport mechanism for the definition that
|
||
applies in that case.
|
||
|
||
NOTE 2 - The ASN.1 specification below contains a clause defining
|
||
TerminationIDList as a sequence of TerminationIDs. The length of
|
||
this sequence SHALL be one, except possibly when used in
|
||
contextAuditResult.
|
||
|
||
NOTE 3 - This syntax specification does not enforce all
|
||
restrictions on element inclusions and values. Some additional
|
||
restrictions are stated in comments and other restrictions appear
|
||
in the text of this RFC. These additional restrictions
|
||
are part of the protocol even though not enforced by this
|
||
specification.
|
||
|
||
NOTE 4 - The ASN.1 module in this Annex uses octet string types to
|
||
encode values for property parameter, signal parameter and event
|
||
parameter values and statistics. The actual types of these values
|
||
vary and are specified in Annex C or the relevant package
|
||
definition.
|
||
|
||
A value is first BER-encoded based on its type using the table below.
|
||
The result of this BER-encoding is then encoded as an ASN.1 octet
|
||
string, "double wrapping" the value. The format specified in Annex C
|
||
or the package relates to BER encoding according to the following
|
||
table:
|
||
|
||
Type Specified in Package ASN.1 BER Type
|
||
|
||
String IA5String or UTF8String (Note 4)
|
||
|
||
Integer (4 Octet) INTEGER
|
||
|
||
Double (8 octet signed int) INTEGER (Note 3)
|
||
|
||
Character (UTF-8, Note 1) IA5String
|
||
|
||
Enumeration ENUMERATED
|
||
|
||
Boolean BOOLEAN
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 92]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Unsigned Integer (Note 2) INTEGER (Note 3)
|
||
|
||
Octet (String) OCTET STRING
|
||
|
||
Note 1: Can be more than one byte
|
||
|
||
Note 2: Unsigned integer is referenced in Annex C
|
||
|
||
Note 3: The BER encoding of INTEGER does not imply the use of 4
|
||
bytes.
|
||
|
||
Note 4: String should be encoded as IA5String when the contents
|
||
are all ASCII characters, but as UTF8String if it contains any
|
||
Non-ASCII characters.
|
||
|
||
See ITU-T Rec. X.690, 8.7, for the definition of the encoding of an
|
||
octet string value.
|
||
|
||
MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=
|
||
BEGIN
|
||
|
||
MegacoMessage ::= SEQUENCE
|
||
{
|
||
authHeader AuthenticationHeader OPTIONAL,
|
||
mess Message
|
||
}
|
||
|
||
AuthenticationHeader ::= SEQUENCE
|
||
{
|
||
secParmIndex SecurityParmIndex,
|
||
seqNum SequenceNum,
|
||
ad AuthData
|
||
}
|
||
|
||
SecurityParmIndex ::= OCTET STRING(SIZE(4))
|
||
|
||
SequenceNum ::= OCTET STRING(SIZE(4))
|
||
|
||
AuthData ::= OCTET STRING (SIZE (12..32))
|
||
|
||
Message ::= SEQUENCE
|
||
{
|
||
version INTEGER(0..99),
|
||
-- The version of the protocol defined here is equal to 1.
|
||
mId MId, -- Name/address of message originator
|
||
messageBody CHOICE
|
||
{
|
||
messageError ErrorDescriptor,
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 93]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
transactions SEQUENCE OF Transaction
|
||
},
|
||
...
|
||
}
|
||
|
||
MId ::= CHOICE
|
||
{
|
||
ip4Address IP4Address,
|
||
ip6Address IP6Address,
|
||
domainName DomainName,
|
||
deviceName PathName,
|
||
mtpAddress OCTET STRING(SIZE(2..4)),
|
||
-- Addressing structure of mtpAddress:
|
||
-- 25 - 15 0
|
||
-- | PC | NI |
|
||
-- 24 - 14 bits 2 bits
|
||
-- Note: 14 bits are defined for international use.
|
||
-- Two national options exist where the point code is 16 or 24
|
||
-- bits.
|
||
-- To octet align the mtpAddress, the MSBs shall be encoded as 0s.
|
||
...
|
||
}
|
||
|
||
DomainName ::= SEQUENCE
|
||
{
|
||
name IA5String,
|
||
-- The name starts with an alphanumeric digit followed by a
|
||
-- sequence of alphanumeric digits, hyphens and dots. No two
|
||
-- dots shall occur consecutively.
|
||
portNumber INTEGER(0..65535) OPTIONAL
|
||
}
|
||
|
||
IP4Address ::= SEQUENCE
|
||
{
|
||
address OCTET STRING (SIZE(4)),
|
||
portNumber INTEGER(0..65535) OPTIONAL
|
||
}
|
||
|
||
IP6Address ::= SEQUENCE
|
||
{
|
||
address OCTET STRING (SIZE(16)),
|
||
portNumber INTEGER(0..65535) OPTIONAL
|
||
}
|
||
|
||
PathName ::= IA5String(SIZE (1..64))
|
||
-- See A.3
|
||
|
||
Transaction ::= CHOICE
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 94]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
{
|
||
transactionRequest TransactionRequest,
|
||
transactionPending TransactionPending,
|
||
transactionReply TransactionReply,
|
||
transactionResponseAck TransactionResponseAck,
|
||
-- use of response acks is dependent on underlying transport
|
||
...
|
||
}
|
||
|
||
TransactionId ::= INTEGER(0..4294967295) -- 32-bit unsigned integer
|
||
|
||
TransactionRequest ::= SEQUENCE
|
||
{
|
||
transactionId TransactionId,
|
||
actions SEQUENCE OF ActionRequest,
|
||
...
|
||
}
|
||
|
||
TransactionPending ::= SEQUENCE
|
||
{
|
||
transactionId TransactionId,
|
||
...
|
||
}
|
||
|
||
TransactionReply ::= SEQUENCE
|
||
{
|
||
transactionId TransactionId,
|
||
immAckRequired NULL OPTIONAL,
|
||
transactionResult CHOICE
|
||
{
|
||
transactionError ErrorDescriptor,
|
||
actionReplies SEQUENCE OF ActionReply
|
||
},
|
||
...
|
||
}
|
||
|
||
TransactionResponseAck ::= SEQUENCE OF TransactionAck
|
||
TransactionAck ::= SEQUENCE
|
||
{
|
||
firstAck TransactionId,
|
||
lastAck TransactionId OPTIONAL
|
||
}
|
||
|
||
ErrorDescriptor ::= SEQUENCE
|
||
{
|
||
errorCode ErrorCode,
|
||
errorText ErrorText OPTIONAL
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 95]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
ErrorCode ::= INTEGER(0..65535)
|
||
-- See clause 13 for IANA Considerations with respect to error codes
|
||
|
||
ErrorText ::= IA5String
|
||
|
||
ContextID ::= INTEGER(0..4294967295)
|
||
|
||
-- Context NULL Value: 0
|
||
-- Context CHOOSE Value: 4294967294 (0xFFFFFFFE)
|
||
-- Context ALL Value: 4294967295 (0xFFFFFFFF)
|
||
|
||
|
||
ActionRequest ::= SEQUENCE
|
||
{
|
||
contextId ContextID,
|
||
contextRequest ContextRequest OPTIONAL,
|
||
contextAttrAuditReq ContextAttrAuditRequest OPTIONAL,
|
||
commandRequests SEQUENCE OF CommandRequest
|
||
}
|
||
|
||
ActionReply ::= SEQUENCE
|
||
{
|
||
contextId ContextID,
|
||
errorDescriptor ErrorDescriptor OPTIONAL,
|
||
contextReply ContextRequest OPTIONAL,
|
||
commandReply SEQUENCE OF CommandReply
|
||
}
|
||
|
||
ContextRequest ::= SEQUENCE
|
||
{
|
||
priority INTEGER(0..15) OPTIONAL,
|
||
emergency BOOLEAN OPTIONAL,
|
||
topologyReq SEQUENCE OF TopologyRequest OPTIONAL,
|
||
...
|
||
}
|
||
|
||
ContextAttrAuditRequest ::= SEQUENCE
|
||
{
|
||
topology NULL OPTIONAL,
|
||
emergency NULL OPTIONAL,
|
||
priority NULL OPTIONAL,
|
||
...
|
||
}
|
||
|
||
CommandRequest ::= SEQUENCE
|
||
{
|
||
command Command,
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 96]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
optional NULL OPTIONAL,
|
||
wildcardReturn NULL OPTIONAL,
|
||
...
|
||
}
|
||
|
||
Command ::= CHOICE
|
||
{
|
||
addReq AmmRequest,
|
||
moveReq AmmRequest,
|
||
modReq AmmRequest,
|
||
-- Add, Move, Modify requests have the same parameters
|
||
subtractReq SubtractRequest,
|
||
auditCapRequest AuditRequest,
|
||
auditValueRequest AuditRequest,
|
||
notifyReq NotifyRequest,
|
||
serviceChangeReq ServiceChangeRequest,
|
||
...
|
||
}
|
||
|
||
CommandReply ::= CHOICE
|
||
{
|
||
addReply AmmsReply,
|
||
moveReply AmmsReply,
|
||
modReply AmmsReply,
|
||
subtractReply AmmsReply,
|
||
-- Add, Move, Modify, Subtract replies have the same parameters
|
||
auditCapReply AuditReply,
|
||
auditValueReply AuditReply,
|
||
notifyReply NotifyReply,
|
||
serviceChangeReply ServiceChangeReply,
|
||
...
|
||
}
|
||
|
||
TopologyRequest ::= SEQUENCE
|
||
{
|
||
terminationFrom TerminationID,
|
||
terminationTo TerminationID,
|
||
topologyDirection ENUMERATED
|
||
{
|
||
bothway(0),
|
||
isolate(1),
|
||
oneway(2)
|
||
},
|
||
...
|
||
}
|
||
|
||
AmmRequest ::= SEQUENCE
|
||
{
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 97]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
terminationID TerminationIDList,
|
||
descriptors SEQUENCE OF AmmDescriptor,
|
||
-- At most one descriptor of each type (see AmmDescriptor)
|
||
-- allowed in the sequence.
|
||
...
|
||
}
|
||
|
||
AmmDescriptor ::= CHOICE
|
||
{
|
||
mediaDescriptor MediaDescriptor,
|
||
modemDescriptor ModemDescriptor,
|
||
muxDescriptor MuxDescriptor,
|
||
eventsDescriptor EventsDescriptor,
|
||
eventBufferDescriptor EventBufferDescriptor,
|
||
signalsDescriptor SignalsDescriptor,
|
||
digitMapDescriptor DigitMapDescriptor,
|
||
auditDescriptor AuditDescriptor,
|
||
...
|
||
}
|
||
|
||
AmmsReply ::= SEQUENCE
|
||
{
|
||
terminationID TerminationIDList,
|
||
terminationAudit TerminationAudit OPTIONAL,
|
||
...
|
||
}
|
||
|
||
SubtractRequest ::= SEQUENCE
|
||
{
|
||
terminationID TerminationIDList,
|
||
auditDescriptor AuditDescriptor OPTIONAL,
|
||
...
|
||
}
|
||
|
||
AuditRequest ::= SEQUENCE
|
||
{
|
||
terminationID TerminationID,
|
||
auditDescriptor AuditDescriptor,
|
||
...
|
||
}
|
||
|
||
AuditReply ::= CHOICE
|
||
{
|
||
contextAuditResult TerminationIDList,
|
||
error ErrorDescriptor,
|
||
auditResult AuditResult,
|
||
...
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 98]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
AuditResult ::= SEQUENCE
|
||
{
|
||
|
||
terminationID TerminationID,
|
||
terminationAuditResult TerminationAudit
|
||
}
|
||
|
||
TerminationAudit ::= SEQUENCE OF AuditReturnParameter
|
||
|
||
AuditReturnParameter ::= CHOICE
|
||
{
|
||
errorDescriptor ErrorDescriptor,
|
||
mediaDescriptor MediaDescriptor,
|
||
modemDescriptor ModemDescriptor,
|
||
muxDescriptor MuxDescriptor,
|
||
eventsDescriptor EventsDescriptor,
|
||
eventBufferDescriptor EventBufferDescriptor,
|
||
signalsDescriptor SignalsDescriptor,
|
||
digitMapDescriptor DigitMapDescriptor,
|
||
observedEventsDescriptor ObservedEventsDescriptor,
|
||
statisticsDescriptor StatisticsDescriptor,
|
||
packagesDescriptor PackagesDescriptor,
|
||
emptyDescriptors AuditDescriptor,
|
||
...
|
||
}
|
||
|
||
AuditDescriptor ::= SEQUENCE
|
||
{
|
||
auditToken BIT STRING
|
||
{
|
||
muxToken(0), modemToken(1), mediaToken(2),
|
||
eventsToken(3), signalsToken(4),
|
||
digitMapToken(5), statsToken(6),
|
||
observedEventsToken(7),
|
||
packagesToken(8), eventBufferToken(9)
|
||
} OPTIONAL,
|
||
...
|
||
}
|
||
|
||
NotifyRequest ::= SEQUENCE
|
||
{
|
||
terminationID TerminationIDList,
|
||
observedEventsDescriptor ObservedEventsDescriptor,
|
||
errorDescriptor ErrorDescriptor OPTIONAL,
|
||
...
|
||
}
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 99]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
NotifyReply ::= SEQUENCE
|
||
{
|
||
terminationID TerminationIDList,
|
||
errorDescriptor ErrorDescriptor OPTIONAL,
|
||
...
|
||
}
|
||
|
||
ObservedEventsDescriptor ::= SEQUENCE
|
||
{
|
||
requestId RequestID,
|
||
observedEventLst SEQUENCE OF ObservedEvent
|
||
}
|
||
|
||
ObservedEvent ::= SEQUENCE
|
||
{
|
||
eventName EventName,
|
||
streamID StreamID OPTIONAL,
|
||
eventParList SEQUENCE OF EventParameter,
|
||
timeNotation TimeNotation OPTIONAL,
|
||
...
|
||
}
|
||
|
||
EventName ::= PkgdName
|
||
|
||
EventParameter ::= SEQUENCE
|
||
{
|
||
eventParameterName Name,
|
||
value Value,
|
||
-- For use of extraInfo see the comment related to PropertyParm
|
||
extraInfo CHOICE
|
||
{
|
||
relation Relation,
|
||
range BOOLEAN,
|
||
sublist BOOLEAN
|
||
} OPTIONAL,
|
||
...
|
||
}
|
||
|
||
ServiceChangeRequest ::= SEQUENCE
|
||
{
|
||
terminationID TerminationIDList,
|
||
serviceChangeParms ServiceChangeParm,
|
||
...
|
||
}
|
||
|
||
ServiceChangeReply ::= SEQUENCE
|
||
{
|
||
terminationID TerminationIDList,
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 100]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
serviceChangeResult ServiceChangeResult,
|
||
...
|
||
}
|
||
|
||
-- For ServiceChangeResult, no parameters are mandatory. Hence the
|
||
-- distinction between ServiceChangeParm and ServiceChangeResParm.
|
||
|
||
ServiceChangeResult ::= CHOICE
|
||
{
|
||
errorDescriptor ErrorDescriptor,
|
||
serviceChangeResParms ServiceChangeResParm
|
||
}
|
||
|
||
WildcardField ::= OCTET STRING(SIZE(1))
|
||
|
||
TerminationID ::= SEQUENCE
|
||
{
|
||
wildcard SEQUENCE OF WildcardField,
|
||
id OCTET STRING(SIZE(1..8)),
|
||
...
|
||
}
|
||
-- See A.1 for explanation of wildcarding mechanism.
|
||
-- Termination ID 0xFFFFFFFFFFFFFFFF indicates the ROOT Termination.
|
||
|
||
TerminationIDList ::= SEQUENCE OF TerminationID
|
||
|
||
MediaDescriptor ::= SEQUENCE
|
||
{
|
||
|
||
termStateDescr TerminationStateDescriptor OPTIONAL,
|
||
streams CHOICE
|
||
{
|
||
oneStream StreamParms,
|
||
multiStream SEQUENCE OF StreamDescriptor
|
||
} OPTIONAL,
|
||
...
|
||
}
|
||
|
||
StreamDescriptor ::= SEQUENCE
|
||
{
|
||
streamID StreamID,
|
||
streamParms StreamParms
|
||
}
|
||
|
||
StreamParms ::= SEQUENCE
|
||
{
|
||
localControlDescriptor LocalControlDescriptor OPTIONAL,
|
||
localDescriptor LocalRemoteDescriptor OPTIONAL,
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 101]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
remoteDescriptor LocalRemoteDescriptor OPTIONAL,
|
||
...
|
||
}
|
||
|
||
LocalControlDescriptor ::= SEQUENCE
|
||
{
|
||
|
||
streamMode StreamMode OPTIONAL,
|
||
reserveValue BOOLEAN OPTIONAL,
|
||
reserveGroup BOOLEAN OPTIONAL,
|
||
propertyParms SEQUENCE OF PropertyParm,
|
||
...
|
||
}
|
||
|
||
StreamMode ::= ENUMERATED
|
||
{
|
||
sendOnly(0),
|
||
recvOnly(1),
|
||
sendRecv(2),
|
||
inactive(3),
|
||
loopBack(4),
|
||
...
|
||
}
|
||
|
||
-- In PropertyParm, value is a SEQUENCE OF octet string. When sent
|
||
-- by an MGC the interpretation is as follows:
|
||
-- empty sequence means CHOOSE
|
||
-- one element sequence specifies value
|
||
-- If the sublist field is not selected, a longer sequence means
|
||
-- "choose one of the values" (i.e., value1 OR value2 OR ...)
|
||
-- If the sublist field is selected,
|
||
-- a sequence with more than one element encodes the value of a
|
||
-- list-valued property (i.e., value1 AND value2 AND ...).
|
||
-- The relation field may only be selected if the value sequence
|
||
-- has length 1. It indicates that the MG has to choose a value
|
||
-- for the property. E.g., x > 3 (using the greaterThan
|
||
-- value for relation) instructs the MG to choose any value larger
|
||
-- than 3 for property x.
|
||
-- The range field may only be selected if the value sequence
|
||
-- has length 2. It indicates that the MG has to choose a value
|
||
-- in the range between the first octet in the value sequence and
|
||
-- the trailing octet in the value sequence, including the
|
||
-- boundary values.
|
||
-- When sent by the MG, only responses to an AuditCapability request
|
||
-- may contain multiple values, a range, or a relation field.
|
||
|
||
PropertyParm ::= SEQUENCE
|
||
{
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 102]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
name PkgdName,
|
||
value SEQUENCE OF OCTET STRING,
|
||
extraInfo CHOICE
|
||
{
|
||
relation Relation,
|
||
range BOOLEAN,
|
||
sublist BOOLEAN
|
||
} OPTIONAL,
|
||
...
|
||
}
|
||
|
||
Name ::= OCTET STRING(SIZE(2))
|
||
|
||
PkgdName ::= OCTET STRING(SIZE(4))
|
||
-- represents Package Name (2 octets) plus Property, Event,
|
||
-- Signal Names or Statistics ID. (2 octets)
|
||
-- To wildcard a package use 0xFFFF for first two octets, choose
|
||
-- is not allowed. To reference native property tag specified in
|
||
-- Annex C, use 0x0000 as first two octets.
|
||
-- To wildcard a Property, Event, Signal, or Statistics ID, use
|
||
-- 0xFFFF for last two octets, choose is not allowed.
|
||
-- Wildcarding of Package Name is permitted only if Property,
|
||
-- Event, Signal, or Statistics ID are
|
||
-- also wildcarded.
|
||
|
||
Relation ::= ENUMERATED
|
||
{
|
||
greaterThan(0),
|
||
smallerThan(1),
|
||
unequalTo(2),
|
||
...
|
||
}
|
||
|
||
LocalRemoteDescriptor ::= SEQUENCE
|
||
{
|
||
propGrps SEQUENCE OF PropertyGroup,
|
||
...
|
||
}
|
||
|
||
PropertyGroup ::= SEQUENCE OF PropertyParm
|
||
|
||
TerminationStateDescriptor ::= SEQUENCE
|
||
{
|
||
propertyParms SEQUENCE OF PropertyParm,
|
||
eventBufferControl EventBufferControl OPTIONAL,
|
||
serviceState ServiceState OPTIONAL,
|
||
...
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 103]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
EventBufferControl ::= ENUMERATED
|
||
{
|
||
off(0),
|
||
lockStep(1),
|
||
...
|
||
}
|
||
|
||
ServiceState ::= ENUMERATED
|
||
|
||
{
|
||
test(0),
|
||
outOfSvc(1),
|
||
inSvc(2),
|
||
...
|
||
}
|
||
|
||
MuxDescriptor ::= SEQUENCE
|
||
{
|
||
muxType MuxType,
|
||
termList SEQUENCE OF TerminationID,
|
||
nonStandardData NonStandardData OPTIONAL,
|
||
...
|
||
}
|
||
|
||
MuxType ::= ENUMERATED
|
||
{
|
||
h221(0),
|
||
h223(1),
|
||
h226(2),
|
||
v76(3),
|
||
...
|
||
}
|
||
|
||
StreamID ::= INTEGER(0..65535) -- 16-bit unsigned integer
|
||
|
||
EventsDescriptor ::= SEQUENCE
|
||
{
|
||
requestID RequestID OPTIONAL,
|
||
-- RequestID must be present if eventList
|
||
-- is non empty
|
||
eventList SEQUENCE OF RequestedEvent,
|
||
...
|
||
}
|
||
|
||
RequestedEvent ::= SEQUENCE
|
||
{
|
||
pkgdName PkgdName,
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 104]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
streamID StreamID OPTIONAL,
|
||
eventAction RequestedActions OPTIONAL,
|
||
evParList SEQUENCE OF EventParameter,
|
||
...
|
||
}
|
||
|
||
RequestedActions ::= SEQUENCE
|
||
{
|
||
keepActive BOOLEAN OPTIONAL,
|
||
eventDM EventDM OPTIONAL,
|
||
secondEvent SecondEventsDescriptor OPTIONAL,
|
||
signalsDescriptor SignalsDescriptor OPTIONAL,
|
||
...
|
||
}
|
||
|
||
EventDM ::= CHOICE
|
||
{ digitMapName DigitMapName,
|
||
digitMapValue DigitMapValue
|
||
}
|
||
|
||
SecondEventsDescriptor ::= SEQUENCE
|
||
{
|
||
requestID RequestID OPTIONAL,
|
||
eventList SEQUENCE OF SecondRequestedEvent,
|
||
...
|
||
}
|
||
|
||
SecondRequestedEvent ::= SEQUENCE
|
||
{
|
||
pkgdName PkgdName,
|
||
streamID StreamID OPTIONAL,
|
||
eventAction SecondRequestedActions OPTIONAL,
|
||
evParList SEQUENCE OF EventParameter,
|
||
...
|
||
}
|
||
|
||
SecondRequestedActions ::= SEQUENCE
|
||
{
|
||
keepActive BOOLEAN OPTIONAL,
|
||
eventDM EventDM OPTIONAL,
|
||
signalsDescriptor SignalsDescriptor OPTIONAL,
|
||
...
|
||
}
|
||
|
||
EventBufferDescriptor ::= SEQUENCE OF EventSpec
|
||
|
||
EventSpec ::= SEQUENCE
|
||
{
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 105]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
eventName EventName,
|
||
streamID StreamID OPTIONAL,
|
||
eventParList SEQUENCE OF EventParameter,
|
||
...
|
||
}
|
||
|
||
SignalsDescriptor ::= SEQUENCE OF SignalRequest
|
||
|
||
SignalRequest ::=CHOICE
|
||
{
|
||
signal Signal,
|
||
seqSigList SeqSigList,
|
||
...
|
||
}
|
||
|
||
SeqSigList ::= SEQUENCE
|
||
{
|
||
id INTEGER(0..65535),
|
||
signalList SEQUENCE OF Signal
|
||
}
|
||
|
||
Signal ::= SEQUENCE
|
||
{
|
||
signalName SignalName,
|
||
streamID StreamID OPTIONAL,
|
||
sigType SignalType OPTIONAL,
|
||
duration INTEGER (0..65535) OPTIONAL,
|
||
notifyCompletion NotifyCompletion OPTIONAL,
|
||
keepActive BOOLEAN OPTIONAL,
|
||
sigParList SEQUENCE OF SigParameter,
|
||
...
|
||
}
|
||
|
||
SignalType ::= ENUMERATED
|
||
{
|
||
brief(0),
|
||
onOff(1),
|
||
timeOut(2),
|
||
...
|
||
}
|
||
|
||
SignalName ::= PkgdName
|
||
|
||
NotifyCompletion ::= BIT STRING
|
||
{
|
||
onTimeOut(0), onInterruptByEvent(1),
|
||
onInterruptByNewSignalDescr(2), otherReason(3)
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 106]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
SigParameter ::= SEQUENCE
|
||
{
|
||
sigParameterName Name,
|
||
value Value,
|
||
-- For use of extraInfo see the comment related to PropertyParm
|
||
extraInfo CHOICE
|
||
{
|
||
relation Relation,
|
||
range BOOLEAN,
|
||
sublist BOOLEAN
|
||
|
||
} OPTIONAL,
|
||
...
|
||
}
|
||
|
||
-- For an AuditCapReply with all events, the RequestID SHALL be ALL.
|
||
-- ALL is represented by 0xffffffff.
|
||
|
||
RequestID ::= INTEGER(0..4294967295) -- 32-bit unsigned integer
|
||
|
||
ModemDescriptor ::= SEQUENCE
|
||
{
|
||
mtl SEQUENCE OF ModemType,
|
||
mpl SEQUENCE OF PropertyParm,
|
||
nonStandardData NonStandardData OPTIONAL
|
||
}
|
||
|
||
ModemType ::= ENUMERATED
|
||
{
|
||
v18(0),
|
||
v22(1),
|
||
v22bis(2),
|
||
v32(3),
|
||
v32bis(4),
|
||
v34(5),
|
||
v90(6),
|
||
v91(7),
|
||
synchISDN(8),
|
||
...
|
||
}
|
||
|
||
DigitMapDescriptor ::= SEQUENCE
|
||
{
|
||
digitMapName DigitMapName OPTIONAL,
|
||
digitMapValue DigitMapValue OPTIONAL
|
||
}
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 107]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
DigitMapName ::= Name
|
||
|
||
DigitMapValue ::= SEQUENCE
|
||
{
|
||
startTimer INTEGER(0..99) OPTIONAL,
|
||
shortTimer INTEGER(0..99) OPTIONAL,
|
||
longTimer INTEGER(0..99) OPTIONAL,
|
||
digitMapBody IA5String,
|
||
-- Units are seconds for start, short and long timers, and
|
||
-- hundreds of milliseconds for duration timer. Thus start,
|
||
-- short, and long range from 1 to 99 seconds and duration
|
||
-- from 100 ms to 9.9 s
|
||
-- See A.3 for explanation of digit map syntax
|
||
...
|
||
}
|
||
|
||
ServiceChangeParm ::= SEQUENCE
|
||
{
|
||
serviceChangeMethod ServiceChangeMethod,
|
||
serviceChangeAddress ServiceChangeAddress OPTIONAL,
|
||
serviceChangeVersion INTEGER(0..99) OPTIONAL,
|
||
serviceChangeProfile ServiceChangeProfile OPTIONAL,
|
||
serviceChangeReason Value,
|
||
-- A serviceChangeReason consists of a numeric reason code
|
||
-- and an optional text description.
|
||
-- The serviceChangeReason SHALL be a string consisting of
|
||
-- a decimal reason code, optionally followed by a single
|
||
-- space character and a textual description string.
|
||
-- This string is first BER-encoded as an IA5String.
|
||
-- The result of this BER-encoding is then encoded as
|
||
-- an ASN.1 OCTET STRING type, "double wrapping" the
|
||
-- value as was done for package elements.
|
||
serviceChangeDelay INTEGER(0..4294967295) OPTIONAL,
|
||
-- 32-bit unsigned integer
|
||
serviceChangeMgcId MId OPTIONAL,
|
||
timeStamp TimeNotation OPTIONAL,
|
||
nonStandardData NonStandardData OPTIONAL,
|
||
...
|
||
}
|
||
|
||
ServiceChangeAddress ::= CHOICE
|
||
{
|
||
portNumber INTEGER(0..65535), -- TCP/UDP port number
|
||
ip4Address IP4Address,
|
||
ip6Address IP6Address,
|
||
domainName DomainName,
|
||
deviceName PathName,
|
||
mtpAddress OCTET STRING(SIZE(2..4)),
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 108]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
...
|
||
}
|
||
|
||
ServiceChangeResParm ::= SEQUENCE
|
||
{
|
||
serviceChangeMgcId MId OPTIONAL,
|
||
serviceChangeAddress ServiceChangeAddress OPTIONAL,
|
||
serviceChangeVersion INTEGER(0..99) OPTIONAL,
|
||
serviceChangeProfile ServiceChangeProfile OPTIONAL,
|
||
timestamp TimeNotation OPTIONAL,
|
||
...
|
||
}
|
||
|
||
ServiceChangeMethod ::= ENUMERATED
|
||
|
||
{
|
||
failover(0),
|
||
forced(1),
|
||
graceful(2),
|
||
restart(3),
|
||
disconnected(4),
|
||
handOff(5),
|
||
...
|
||
}
|
||
|
||
ServiceChangeProfile ::= SEQUENCE
|
||
{
|
||
profileName IA5String(SIZE (1..67))
|
||
-- 64 characters for name, 1 for "/", 2 for version to match ABNF
|
||
}
|
||
|
||
PackagesDescriptor ::= SEQUENCE OF PackagesItem
|
||
|
||
PackagesItem ::= SEQUENCE
|
||
{
|
||
packageName Name,
|
||
packageVersion INTEGER(0..99),
|
||
...
|
||
}
|
||
|
||
StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter
|
||
|
||
StatisticsParameter ::= SEQUENCE
|
||
{
|
||
statName PkgdName,
|
||
statValue Value OPTIONAL
|
||
}
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 109]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
NonStandardData ::= SEQUENCE
|
||
{
|
||
nonStandardIdentifier NonStandardIdentifier,
|
||
data OCTET STRING
|
||
}
|
||
|
||
NonStandardIdentifier ::= CHOICE
|
||
{
|
||
object OBJECT IDENTIFIER,
|
||
h221NonStandard H221NonStandard,
|
||
experimental IA5String(SIZE(8)),
|
||
-- first two characters should be "X-" or "X+"
|
||
...
|
||
}
|
||
|
||
H221NonStandard ::= SEQUENCE
|
||
{ t35CountryCode1 INTEGER(0..255),
|
||
t35CountryCode2 INTEGER(0..255), -- country, as per T.35
|
||
t35Extension INTEGER(0..255), -- assigned nationally
|
||
manufacturerCode INTEGER(0..65535), -- assigned nationally
|
||
...
|
||
}
|
||
|
||
TimeNotation ::= SEQUENCE
|
||
{
|
||
date IA5String(SIZE(8)), -- yyyymmdd format
|
||
time IA5String(SIZE(8)) -- hhmmssss format
|
||
-- per ISO 8601:1988
|
||
}
|
||
|
||
Value ::= SEQUENCE OF OCTET STRING
|
||
|
||
END
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 110]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A.3 Digit maps and path names
|
||
|
||
From a syntactic viewpoint, digit maps are strings with syntactic
|
||
restrictions imposed upon them. The syntax of valid digit maps is
|
||
specified in ABNF [RFC 2234]. The syntax for digit maps presented in
|
||
this subclause is for illustrative purposes only. The definition of
|
||
digitMap in Annex B takes precedence in the case of differences
|
||
between the two.
|
||
|
||
digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")"
|
||
LWSP)
|
||
|
||
digitStringList = digitString *( LWSP "|" LWSP digitString )
|
||
digitString = 1*(digitStringElement)
|
||
digitStringElement = digitPosition [DOT]
|
||
digitPosition = digitMapLetter / digitMapRange
|
||
digitMapRange = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
|
||
digitLetter = *((DIGIT "-" DIGIT) /digitMapLetter)
|
||
digitMapLetter = DIGIT ;digits 0-9
|
||
/ %x41-4B / %x61-6B ;a-k and A-K
|
||
/ "L"/ "S" ;Inter-event timers
|
||
;(long, short)
|
||
/ "Z" ;Long duration event
|
||
DOT = %x2E ; "."
|
||
LWSP = *(WSP / COMMENT / EOL)
|
||
WSP = SP / HTAB
|
||
COMMENT = ";" *(SafeChar / RestChar / WSP) EOL
|
||
EOL = (CR [LF]) / LF
|
||
SP = %x20
|
||
HTAB = %x09
|
||
CR = %x0D
|
||
LF = %x0A
|
||
SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" /
|
||
"'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "\" /
|
||
"(" / ")" / "%" / "."
|
||
RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
|
||
"<" / ">" / "=" / %x22
|
||
DIGIT = %x30-39 ; digits 0 through 9
|
||
ALPHA = %x41-5A / %x61-7A; A-Z, a-z
|
||
|
||
A path name is also a string with syntactic restrictions imposed upon
|
||
it. The ABNF production defining it is copied from Annex B.
|
||
|
||
; Total length of pathNAME must not exceed 64 chars.
|
||
pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
|
||
["@" pathDomainName ]
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 111]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
; ABNF allows two or more consecutive "." although it is
|
||
; meaningless in a path domain name.
|
||
pathDomainName = (ALPHA / DIGIT / "*" )
|
||
*63(ALPHA / DIGIT / "-"
|
||
NAME = ALPHA *63(ALPHA / DIGIT / "_" )
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 112]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ANNEX B - Text encoding of the protocol
|
||
|
||
B.1 Coding of wildcards
|
||
|
||
In a text encoding of the protocol, while TerminationIDs are
|
||
arbitrary, by judicious choice of names, the wildcard character, "*"
|
||
may be made more useful. When the wildcard character is encountered,
|
||
it will "match" all TerminationIDs having the same previous and
|
||
following characters (if appropriate). For example, if there were
|
||
TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
|
||
R13/3/* would match all of them. There are some circumstances where
|
||
ALL Terminations must be referred to. The TerminationID "*"
|
||
suffices, and is referred to as ALL. The CHOOSE TerminationID "$"
|
||
may be used to signal to the MG that it has to create an ephemeral
|
||
Termination or select an idle physical Termination.
|
||
|
||
B.2 ABNF specification
|
||
|
||
The protocol syntax is presented in ABNF according to RFC 2234.
|
||
|
||
Note 1 - This syntax specification does not enforce all
|
||
restrictions on element inclusions and values. Some additional
|
||
restrictions are stated in comments and other restrictions appear
|
||
in the text of this RFC. These additional restrictions are part
|
||
of the protocol even though not enforced by this specification.
|
||
|
||
Note 2 - The syntax is context-dependent. For example, "Add" can
|
||
be the AddToken or a NAME depending on the context in which it
|
||
occurs.
|
||
|
||
Everything in the ABNF and text encoding is case insensitive. This
|
||
includes TerminationIDs, digitmap Ids etc. SDP is case sensitive as
|
||
per RFC 2327.
|
||
|
||
; NOTE -- The ABNF in this section uses the VALUE construct (or lists
|
||
; of VALUE constructs) to encode various package element values
|
||
; (properties, signal parameters, etc.). The types of these values
|
||
; vary and are specified the relevant package definition. Several
|
||
; such types are described in section 12.2.
|
||
;
|
||
; The ABNF specification for VALUE allows a quotedString form or a
|
||
; collection of SafeChars. The encoding of package element values
|
||
; into ABNF VALUES is specified below. If a type's encoding allows
|
||
; characters other than SafeChars, the quotedString form MUST be used
|
||
; for all values of that type, even for specific values that consist
|
||
; only of SafeChars.
|
||
;
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 113]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
; String: A string MUST use the quotedString form of VALUE and can
|
||
; contain anything allowable in the quotedString form.
|
||
;
|
||
; Integer, Double, and Unsigned Integer: Decimal values can be
|
||
; encoded using characters 0-9. Hexadecimal values must be prefixed
|
||
; with '0x' and can use characters 0-9,a-f,A-F. An octal format is
|
||
; not supported. Negative integers start with '-' and MUST be
|
||
; Decimal. The SafeChar form of VALUE MUST be used.
|
||
;
|
||
; Character: A UTF-8 encoding of a single letter surrounded by
|
||
; double quotes.
|
||
;
|
||
; Enumeration: An enumeration MUST use the SafeChar form of VALUE
|
||
; and can contain anything allowable in the SafeChar form.
|
||
;
|
||
; Boolean: Boolean values are encoded as "on" and "off" and are
|
||
; case insensitive. The SafeChar form of VALUE MUST be used.
|
||
;
|
||
; Future types: Any defined types MUST fit within
|
||
; the ABNF specification of VALUE. Specifically, if a type's
|
||
; encoding allows characters other than SafeChars, the quotedString
|
||
; form MUST be used for all values of that type, even for specific
|
||
; values that consist only of SafeChars.
|
||
;
|
||
; Note that there is no way to use the double quote character within
|
||
; a value.
|
||
;
|
||
; Note that SDP disallows whitespace at the beginning of a line,
|
||
; Megaco ABNF allows whitespace before the beginning of the SDP in
|
||
; the Local/Remote descriptor. Parsers should accept whitespace
|
||
; between the LBRKT following the Local/Remote token and the
|
||
; beginning of the SDP.
|
||
|
||
megacoMessage = LWSP [authenticationHeader SEP ] message
|
||
|
||
authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
|
||
SequenceNum COLON AuthData
|
||
|
||
SecurityParmIndex = "0x" 8(HEXDIG)
|
||
SequenceNum = "0x" 8(HEXDIG)
|
||
AuthData = "0x" 24*64(HEXDIG)
|
||
|
||
message = MegacopToken SLASH Version SEP mId SEP
|
||
messageBody
|
||
; The version of the protocol defined here is equal to 1.
|
||
|
||
messageBody = ( errorDescriptor / transactionList )
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 114]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
transactionList = 1*( transactionRequest / transactionReply /
|
||
transactionPending / transactionResponseAck )
|
||
;Use of response acks is dependent on underlying transport
|
||
|
||
|
||
transactionPending = PendingToken EQUAL TransactionID LBRKT
|
||
RBRKT
|
||
|
||
transactionResponseAck = ResponseAckToken LBRKT transactionAck
|
||
*(COMMA transactionAck) RBRKT
|
||
transactionAck = transactionID / (transactionID "-" transactionID)
|
||
|
||
transactionRequest = TransToken EQUAL TransactionID LBRKT
|
||
actionRequest *(COMMA actionRequest) RBRKT
|
||
|
||
actionRequest = CtxToken EQUAL ContextID LBRKT ((
|
||
contextRequest [COMMA commandRequestList])
|
||
/ commandRequestList) RBRKT
|
||
|
||
contextRequest = ((contextProperties [COMMA contextAudit])
|
||
/ contextAudit)
|
||
|
||
contextProperties = contextProperty *(COMMA contextProperty)
|
||
|
||
; at-most-once
|
||
contextProperty = (topologyDescriptor / priority / EmergencyToken)
|
||
|
||
contextAudit = ContextAuditToken LBRKT contextAuditProperties
|
||
*(COMMA contextAuditProperties) RBRKT
|
||
|
||
; at-most-once
|
||
contextAuditProperties = ( TopologyToken / EmergencyToken /
|
||
PriorityToken )
|
||
|
||
; "O-" indicates an optional command
|
||
; "W-" indicates a wildcarded response to a command
|
||
commandRequestList = ["O-"] ["W-"] commandRequest
|
||
*(COMMA ["O-"] ["W-"]commandRequest)
|
||
|
||
commandRequest = ( ammRequest / subtractRequest / auditRequest /
|
||
notifyRequest / serviceChangeRequest)
|
||
|
||
transactionReply = ReplyToken EQUAL TransactionID LBRKT
|
||
[ ImmAckRequiredToken COMMA]
|
||
( errorDescriptor / actionReplyList ) RBRKT
|
||
|
||
actionReplyList = actionReply *(COMMA actionReply )
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 115]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
actionReply = CtxToken EQUAL ContextID LBRKT
|
||
( errorDescriptor / commandReply ) /
|
||
(commandReply COMMA errorDescriptor) ) RBRKT
|
||
|
||
commandReply = (( contextProperties [COMMA commandReplyList] ) /
|
||
commandReplyList )
|
||
|
||
|
||
commandReplyList = commandReplys *(COMMA commandReplys )
|
||
|
||
commandReplys = (serviceChangeReply / auditReply / ammsReply /
|
||
notifyReply )
|
||
|
||
;Add Move and Modify have the same request parameters
|
||
ammRequest = (AddToken / MoveToken / ModifyToken ) EQUAL
|
||
TerminationID [LBRKT ammParameter *(COMMA
|
||
ammParameter) RBRKT]
|
||
|
||
;at-most-once
|
||
ammParameter = (mediaDescriptor / modemDescriptor /
|
||
muxDescriptor / eventsDescriptor /
|
||
signalsDescriptor / digitMapDescriptor /
|
||
eventBufferDescriptor / auditDescriptor)
|
||
|
||
ammsReply = (AddToken / MoveToken / ModifyToken /
|
||
SubtractToken ) EQUAL TerminationID [ LBRKT
|
||
terminationAudit RBRKT ]
|
||
|
||
subtractRequest = SubtractToken EQUAL TerminationID
|
||
[ LBRKT auditDescriptor RBRKT]
|
||
|
||
auditRequest = (AuditValueToken / AuditCapToken ) EQUAL
|
||
TerminationID LBRKT auditDescriptor RBRKT
|
||
|
||
auditReply = (AuditValueToken / AuditCapToken )
|
||
( contextTerminationAudit / auditOther)
|
||
|
||
auditOther = EQUAL TerminationID [LBRKT
|
||
terminationAudit RBRKT]
|
||
|
||
terminationAudit = auditReturnParameter *(COMMA auditReturnParameter)
|
||
|
||
contextTerminationAudit = EQUAL CtxToken ( terminationIDList /
|
||
LBRKT errorDescriptor RBRKT )
|
||
|
||
auditReturnParameter = (mediaDescriptor / modemDescriptor /
|
||
muxDescriptor / eventsDescriptor /
|
||
signalsDescriptor / digitMapDescriptor /
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 116]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
observedEventsDescriptor / eventBufferDescriptor /
|
||
statisticsDescriptor / packagesDescriptor /
|
||
errorDescriptor / auditItem)
|
||
|
||
auditDescriptor = AuditToken LBRKT [ auditItem
|
||
*(COMMA auditItem) ] RBRKT
|
||
|
||
notifyRequest = NotifyToken EQUAL TerminationID
|
||
LBRKT ( observedEventsDescriptor
|
||
[ COMMA errorDescriptor ] ) RBRKT
|
||
|
||
notifyReply = NotifyToken EQUAL TerminationID
|
||
[ LBRKT errorDescriptor RBRKT ]
|
||
|
||
serviceChangeRequest = ServiceChangeToken EQUAL TerminationID
|
||
LBRKT serviceChangeDescriptor RBRKT
|
||
|
||
serviceChangeReply = ServiceChangeToken EQUAL TerminationID
|
||
[LBRKT (errorDescriptor /
|
||
serviceChangeReplyDescriptor) RBRKT]
|
||
|
||
errorDescriptor = ErrorToken EQUAL ErrorCode
|
||
LBRKT [quotedString] RBRKT
|
||
|
||
ErrorCode = 1*4(DIGIT) ; could be extended
|
||
|
||
TransactionID = UINT32
|
||
|
||
mId = (( domainAddress / domainName )
|
||
[":" portNumber]) / mtpAddress / deviceName
|
||
|
||
; ABNF allows two or more consecutive "." although it is meaningless
|
||
; in a domain name.
|
||
domainName = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" /
|
||
".") ">"
|
||
deviceName = pathNAME
|
||
|
||
;The values 0x0, 0xFFFFFFFE and 0xFFFFFFFF are reserved.
|
||
ContextID = (UINT32 / "*" / "-" / "$")
|
||
|
||
domainAddress = "[" (IPv4address / IPv6address) "]"
|
||
;RFC2373 contains the definition of IP6Addresses.
|
||
IPv6address = hexpart [ ":" IPv4address ]
|
||
IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex
|
||
V4hex = 1*3(DIGIT) ; "0".."255"
|
||
; this production, while occurring in RFC2373, is not referenced
|
||
; IPv6prefix = hexpart SLASH 1*2DIGIT
|
||
hexpart = hexseq "::" [ hexseq ] / "::" [ hexseq ] / hexseq
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 117]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
hexseq = hex4 *( ":" hex4)
|
||
hex4 = 1*4HEXDIG
|
||
|
||
portNumber = UINT16
|
||
|
||
; Addressing structure of mtpAddress:
|
||
; 25 - 15 0
|
||
; | PC | NI |
|
||
; 24 - 14 bits 2 bits
|
||
; Note: 14 bits are defined for international use.
|
||
; Two national options exist where the point code is 16 or 24 bits.
|
||
; To octet align the mtpAddress the MSBs shall be encoded as 0s.
|
||
; An octet shall be represented by 2 hex digits.
|
||
mtpAddress = MTPToken LBRKT 4*8 (HEXDIG) RBRKT
|
||
|
||
terminationIDList = LBRKT TerminationID *(COMMA TerminationID) RBRKT
|
||
|
||
; Total length of pathNAME must not exceed 64 chars.
|
||
pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
|
||
["@" pathDomainName ]
|
||
|
||
; ABNF allows two or more consecutive "." although it is meaningless
|
||
; in a path domain name.
|
||
pathDomainName = (ALPHA / DIGIT / "*" )
|
||
*63(ALPHA / DIGIT / "-" / "*" / ".")
|
||
|
||
TerminationID = "ROOT" / pathNAME / "$" / "*"
|
||
|
||
mediaDescriptor = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT
|
||
|
||
; at-most one terminationStateDescriptor
|
||
; and either streamParm(s) or streamDescriptor(s) but not both
|
||
mediaParm = (streamParm / streamDescriptor /
|
||
terminationStateDescriptor)
|
||
|
||
; at-most-once per item
|
||
streamParm = ( localDescriptor / remoteDescriptor /
|
||
localControlDescriptor )
|
||
|
||
streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm
|
||
*(COMMA streamParm) RBRKT
|
||
|
||
localControlDescriptor = LocalControlToken LBRKT localParm
|
||
*(COMMA localParm) RBRKT
|
||
|
||
; at-most-once per item except for propertyParm
|
||
localParm = ( streamMode / propertyParm / reservedValueMode
|
||
/ reservedGroupMode )
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 118]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
reservedValueMode = ReservedValueToken EQUAL ( "ON" / "OFF" )
|
||
reservedGroupMode = ReservedGroupToken EQUAL ( "ON" / "OFF" )
|
||
|
||
streamMode = ModeToken EQUAL streamModes
|
||
|
||
streamModes = (SendonlyToken / RecvonlyToken / SendrecvToken /
|
||
InactiveToken / LoopbackToken )
|
||
|
||
propertyParm = pkgdName parmValue
|
||
parmValue = (EQUAL alternativeValue/ INEQUAL VALUE)
|
||
alternativeValue = ( VALUE
|
||
/ LSBRKT VALUE *(COMMA VALUE) RSBRKT
|
||
; sublist (i.e., A AND B AND ...)
|
||
/ LBRKT VALUE *(COMMA VALUE) RBRKT
|
||
; alternatives (i.e., A OR B OR ...)
|
||
/ LSBRKT VALUE COLON VALUE RSBRKT )
|
||
; range
|
||
|
||
INEQUAL = LWSP (">" / "<" / "#" ) LWSP
|
||
LSBRKT = LWSP "[" LWSP
|
||
RSBRKT = LWSP "]" LWSP
|
||
|
||
; Note - The octet zero is not among the permitted characters in
|
||
; octet string. As the current definition is limited to SDP, and a
|
||
; zero octet would not be a legal character in SDP, this is not a
|
||
; concern.
|
||
|
||
localDescriptor = LocalToken LBRKT octetString RBRKT
|
||
|
||
remoteDescriptor = RemoteToken LBRKT octetString RBRKT
|
||
|
||
eventBufferDescriptor= EventBufferToken [ LBRKT eventSpec
|
||
*( COMMA eventSpec) RBRKT ]
|
||
|
||
eventSpec = pkgdName [ LBRKT eventSpecParameter
|
||
*(COMMA eventSpecParameter) RBRKT ]
|
||
eventSpecParameter = (eventStream / eventOther)
|
||
|
||
eventBufferControl = BufferToken EQUAL ( "OFF" / LockStepToken )
|
||
|
||
terminationStateDescriptor = TerminationStateToken LBRKT
|
||
terminationStateParm *( COMMA terminationStateParm ) RBRKT
|
||
|
||
; at-most-once per item except for propertyParm
|
||
terminationStateParm = (propertyParm / serviceStates /
|
||
eventBufferControl )
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 119]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
serviceStates = ServiceStatesToken EQUAL ( TestToken /
|
||
OutOfSvcToken / InSvcToken )
|
||
|
||
muxDescriptor = MuxToken EQUAL MuxType terminationIDList
|
||
|
||
MuxType = ( H221Token / H223Token / H226Token / V76Token
|
||
/ extensionParameter )
|
||
|
||
StreamID = UINT16
|
||
pkgdName = (PackageName SLASH ItemID) ;specific item
|
||
/ (PackageName SLASH "*") ;all items in package
|
||
/ ("*" SLASH "*") ; all items supported by the MG
|
||
PackageName = NAME
|
||
ItemID = NAME
|
||
|
||
eventsDescriptor = EventsToken [ EQUAL RequestID LBRKT
|
||
requestedEvent *( COMMA requestedEvent ) RBRKT ]
|
||
|
||
requestedEvent = pkgdName [ LBRKT eventParameter
|
||
*( COMMA eventParameter ) RBRKT ]
|
||
|
||
; at-most-once each of KeepActiveToken , eventDM and eventStream
|
||
;at most one of either embedWithSig or embedNoSig but not both
|
||
;KeepActiveToken and embedWithSig must not both be present
|
||
eventParameter = ( embedWithSig / embedNoSig / KeepActiveToken
|
||
/eventDM / eventStream / eventOther )
|
||
|
||
embedWithSig = EmbedToken LBRKT signalsDescriptor
|
||
[COMMA embedFirst ] RBRKT
|
||
embedNoSig = EmbedToken LBRKT embedFirst RBRKT
|
||
|
||
; at-most-once of each
|
||
embedFirst = EventsToken [ EQUAL RequestID LBRKT
|
||
secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT ]
|
||
|
||
secondRequestedEvent = pkgdName [ LBRKT secondEventParameter
|
||
*( COMMA secondEventParameter ) RBRKT ]
|
||
|
||
; at-most-once each of embedSig , KeepActiveToken, eventDM or
|
||
; eventStream
|
||
; KeepActiveToken and embedSig must not both be present
|
||
secondEventParameter = ( embedSig / KeepActiveToken / eventDM /
|
||
eventStream / eventOther )
|
||
|
||
embedSig = EmbedToken LBRKT signalsDescriptor RBRKT
|
||
|
||
eventStream = StreamToken EQUAL StreamID
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 120]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
eventOther = eventParameterName parmValue
|
||
|
||
eventParameterName = NAME
|
||
|
||
eventDM = DigitMapToken EQUAL(( digitMapName ) /
|
||
(LBRKT digitMapValue RBRKT ))
|
||
|
||
signalsDescriptor = SignalsToken LBRKT [ signalParm
|
||
*(COMMA signalParm)] RBRKT
|
||
|
||
signalParm = signalList / signalRequest
|
||
|
||
signalRequest = signalName [ LBRKT sigParameter
|
||
*(COMMA sigParameter) RBRKT ]
|
||
|
||
signalList = SignalListToken EQUAL signalListId LBRKT
|
||
signalListParm *(COMMA signalListParm) RBRKT
|
||
|
||
signalListId = UINT16
|
||
|
||
;exactly once signalType, at most once duration and every signal
|
||
;parameter
|
||
signalListParm = signalRequest
|
||
|
||
signalName = pkgdName
|
||
;at-most-once sigStream, at-most-once sigSignalType,
|
||
;at-most-once sigDuration, every signalParameterName at most once
|
||
sigParameter = sigStream / sigSignalType / sigDuration / sigOther
|
||
/ notifyCompletion / KeepActiveToken
|
||
sigStream = StreamToken EQUAL StreamID
|
||
sigOther = sigParameterName parmValue
|
||
sigParameterName = NAME
|
||
sigSignalType = SignalTypeToken EQUAL signalType
|
||
signalType = (OnOffToken / TimeOutToken / BriefToken)
|
||
sigDuration = DurationToken EQUAL UINT16
|
||
notifyCompletion = NotifyCompletionToken EQUAL (LBRKT
|
||
notificationReason *(COMMA notificationReason) RBRKT)
|
||
|
||
notificationReason = ( TimeOutToken / InterruptByEventToken
|
||
/ InterruptByNewSignalsDescrToken
|
||
/ OtherReasonToken )
|
||
observedEventsDescriptor = ObservedEventsToken EQUAL RequestID
|
||
LBRKT observedEvent *(COMMA observedEvent) RBRKT
|
||
|
||
;time per event, because it might be buffered
|
||
observedEvent = [ TimeStamp LWSP COLON] LWSP
|
||
pkgdName [ LBRKT observedEventParameter
|
||
*(COMMA observedEventParameter) RBRKT ]
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 121]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
;at-most-once eventStream, every eventParameterName at most once
|
||
observedEventParameter = eventStream / eventOther
|
||
|
||
; For an AuditCapReply with all events, the RequestID should be ALL.
|
||
RequestID = ( UINT32 / "*" )
|
||
|
||
modemDescriptor = ModemToken (( EQUAL modemType) /
|
||
(LSBRKT modemType *(COMMA modemType) RSBRKT))
|
||
[ LBRKT propertyParm *(COMMA propertyParm) RBRKT ]
|
||
|
||
|
||
; at-most-once except for extensionParameter
|
||
modemType = (V32bisToken / V22bisToken / V18Token /
|
||
V22Token / V32Token / V34Token / V90Token /
|
||
V91Token / SynchISDNToken / extensionParameter)
|
||
|
||
digitMapDescriptor = DigitMapToken EQUAL
|
||
( ( LBRKT digitMapValue RBRKT ) /
|
||
(digitMapName [ LBRKT digitMapValue RBRKT ]) )
|
||
digitMapName = NAME
|
||
digitMapValue = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA]
|
||
["L" COLON Timer COMMA] digitMap
|
||
Timer = 1*2DIGIT
|
||
; Units are seconds for T, S, and L timers, and hundreds of
|
||
; milliseconds for Z timer. Thus T, S, and L range from 1 to 99
|
||
; seconds and Z from 100 ms to 9.9 s
|
||
digitMap = (digitString /
|
||
LWSP "(" LWSP digitStringList LWSP ")" LWSP)
|
||
digitStringList = digitString *( LWSP "|" LWSP digitString )
|
||
digitString = 1*(digitStringElement)
|
||
digitStringElement = digitPosition [DOT]
|
||
digitPosition = digitMapLetter / digitMapRange
|
||
digitMapRange = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
|
||
digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter)
|
||
digitMapLetter = DIGIT ;Basic event symbols
|
||
/ %x41-4B / %x61-6B ; a-k, A-K
|
||
/ "L" / "S" ;Inter-event timers (long, short)
|
||
/ "Z" ;Long duration modifier
|
||
|
||
;at-most-once, and DigitMapToken and PackagesToken are not allowed
|
||
;in AuditCapabilities command
|
||
auditItem = ( MuxToken / ModemToken / MediaToken /
|
||
SignalsToken / EventBufferToken /
|
||
DigitMapToken / StatsToken / EventsToken /
|
||
ObservedEventsToken / PackagesToken )
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 122]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
|
||
*(COMMA serviceChangeParm) RBRKT
|
||
|
||
; each parameter at-most-once
|
||
; at most one of either serviceChangeAddress or serviceChangeMgcId
|
||
; but not both
|
||
; serviceChangeMethod and serviceChangeReason are REQUIRED
|
||
serviceChangeParm = (serviceChangeMethod / serviceChangeReason /
|
||
serviceChangeDelay / serviceChangeAddress /
|
||
serviceChangeProfile / extension / TimeStamp /
|
||
serviceChangeMgcId / serviceChangeVersion )
|
||
|
||
serviceChangeReplyDescriptor = ServicesToken LBRKT
|
||
servChgReplyParm *(COMMA servChgReplyParm) RBRKT
|
||
|
||
; at-most-once. Version is REQUIRED on first ServiceChange response
|
||
; at most one of either serviceChangeAddress or serviceChangeMgcId
|
||
; but not both
|
||
servChgReplyParm = (serviceChangeAddress / serviceChangeMgcId /
|
||
serviceChangeProfile / serviceChangeVersion /
|
||
TimeStamp)
|
||
serviceChangeMethod = MethodToken EQUAL (FailoverToken /
|
||
ForcedToken / GracefulToken / RestartToken /
|
||
DisconnectedToken / HandOffToken /
|
||
extensionParameter)
|
||
; A serviceChangeReason consists of a numeric reason code
|
||
; and an optional text description.
|
||
; A serviceChangeReason MUST be encoded using the quotedString
|
||
; form of VALUE.
|
||
; The quotedString SHALL contain a decimal reason code,
|
||
; optionally followed by a single space character and a
|
||
; textual description string.
|
||
|
||
|
||
serviceChangeReason = ReasonToken EQUAL VALUE
|
||
serviceChangeDelay = DelayToken EQUAL UINT32
|
||
serviceChangeAddress = ServiceChangeAddressToken EQUAL ( mId /
|
||
portNumber )
|
||
serviceChangeMgcId = MgcIdToken EQUAL mId
|
||
serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
|
||
serviceChangeVersion = VersionToken EQUAL Version
|
||
extension = extensionParameter parmValue
|
||
|
||
packagesDescriptor = PackagesToken LBRKT packagesItem
|
||
*(COMMA packagesItem) RBRKT
|
||
|
||
Version = 1*2(DIGIT)
|
||
packagesItem = NAME "-" UINT16
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 123]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
TimeStamp = Date "T" Time ; per ISO 8601:1988
|
||
; Date = yyyymmdd
|
||
Date = 8(DIGIT)
|
||
; Time = hhmmssss
|
||
Time = 8(DIGIT)
|
||
statisticsDescriptor = StatsToken LBRKT statisticsParameter
|
||
*(COMMA statisticsParameter ) RBRKT
|
||
|
||
;at-most-once per item
|
||
statisticsParameter = pkgdName [EQUAL VALUE]
|
||
|
||
topologyDescriptor = TopologyToken LBRKT topologyTriple
|
||
*(COMMA topologyTriple) RBRKT
|
||
topologyTriple = terminationA COMMA
|
||
terminationB COMMA topologyDirection
|
||
terminationA = TerminationID
|
||
terminationB = TerminationID
|
||
topologyDirection = BothwayToken / IsolateToken / OnewayToken
|
||
|
||
priority = PriorityToken EQUAL UINT16
|
||
|
||
extensionParameter = "X" ("-" / "+") 1*6(ALPHA / DIGIT)
|
||
|
||
; octetString is used to describe SDP defined in RFC2327.
|
||
; Caution should be taken if CRLF in RFC2327 is used.
|
||
; To be safe, use EOL in this ABNF.
|
||
; Whenever "}" appears in SDP, it is escaped by "\", e.g., "\}"
|
||
octetString = *(nonEscapeChar)
|
||
nonEscapeChar = ( "\}" / %x01-7C / %x7E-FF )
|
||
; Note - The double-quote character is not allowed in quotedString.
|
||
quotedString = DQUOTE *(SafeChar / RestChar/ WSP) DQUOTE
|
||
|
||
UINT16 = 1*5(DIGIT) ; %x0-FFFF
|
||
UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF
|
||
|
||
NAME = ALPHA *63(ALPHA / DIGIT / "_" )
|
||
VALUE = quotedString / 1*(SafeChar)
|
||
SafeChar = DIGIT / ALPHA / "+" / "-" / "&" /
|
||
"!" / "_" / "/" / "\'" / "?" / "@" /
|
||
"^" / "`" / "~" / "*" / "$" / "\" /
|
||
"(" / ")" / "%" / "|" / "."
|
||
|
||
EQUAL = LWSP %x3D LWSP ; "="
|
||
COLON = %x3A ; ":"
|
||
LBRKT = LWSP %x7B LWSP ; "{"
|
||
RBRKT = LWSP %x7D LWSP ; "}"
|
||
COMMA = LWSP %x2C LWSP ; ","
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 124]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
DOT = %x2E ; "."
|
||
SLASH = %x2F ; "/"
|
||
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
|
||
DIGIT = %x30-39 ; 0-9
|
||
DQUOTE = %x22 ; " (Double Quote)
|
||
HEXDIG = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )
|
||
SP = %x20 ; space
|
||
HTAB = %x09 ; horizontal tab
|
||
CR = %x0D ; Carriage return
|
||
LF = %x0A ; linefeed
|
||
LWSP = *( WSP / COMMENT / EOL )
|
||
EOL = (CR [LF] / LF )
|
||
WSP = SP / HTAB ; white space
|
||
SEP = ( WSP / EOL / COMMENT) LWSP
|
||
COMMENT = ";" *(SafeChar/ RestChar / WSP / %x22) EOL
|
||
RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
|
||
"<" / ">" / "="
|
||
|
||
; New Tokens added to sigParameter must take the format of SPA*
|
||
; * may be of any form i.e., SPAM
|
||
; New Tokens added to eventParameter must take the form of EPA*
|
||
; * may be of any form i.e., EPAD
|
||
|
||
AddToken = ("Add" / "A")
|
||
AuditToken = ("Audit" / "AT")
|
||
AuditCapToken = ("AuditCapability" / "AC")
|
||
AuditValueToken = ("AuditValue" / "AV")
|
||
AuthToken = ("Authentication" / "AU")
|
||
BothwayToken = ("Bothway" / "BW")
|
||
BriefToken = ("Brief" / "BR")
|
||
BufferToken = ("Buffer" / "BF")
|
||
CtxToken = ("Context" / "C")
|
||
ContextAuditToken = ("ContextAudit" / "CA")
|
||
DigitMapToken = ("DigitMap" / "DM")
|
||
DisconnectedToken = ("Disconnected" / "DC")
|
||
DelayToken = ("Delay" / "DL")
|
||
DurationToken = ("Duration" / "DR")
|
||
EmbedToken = ("Embed" / "EM")
|
||
EmergencyToken = ("Emergency" / "EG")
|
||
ErrorToken = ("Error" / "ER")
|
||
EventBufferToken = ("EventBuffer" / "EB")
|
||
EventsToken = ("Events" / "E")
|
||
FailoverToken = ("Failover" / "FL")
|
||
ForcedToken = ("Forced" / "FO")
|
||
GracefulToken = ("Graceful" / "GR")
|
||
H221Token = ("H221" )
|
||
H223Token = ("H223" )
|
||
H226Token = ("H226" )
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 125]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
HandOffToken = ("HandOff" / "HO")
|
||
ImmAckRequiredToken = ("ImmAckRequired" / "IA")
|
||
InactiveToken = ("Inactive" / "IN")
|
||
IsolateToken = ("Isolate" / "IS")
|
||
InSvcToken = ("InService" / "IV")
|
||
InterruptByEventToken = ("IntByEvent" / "IBE")
|
||
InterruptByNewSignalsDescrToken
|
||
= ("IntBySigDescr" / "IBS")
|
||
KeepActiveToken = ("KeepActive" / "KA")
|
||
LocalToken = ("Local" / "L")
|
||
LocalControlToken = ("LocalControl" / "O")
|
||
LockStepToken = ("LockStep" / "SP")
|
||
LoopbackToken = ("Loopback" / "LB")
|
||
MediaToken = ("Media" / "M")
|
||
MegacopToken = ("MEGACO" / "!")
|
||
MethodToken = ("Method" / "MT")
|
||
MgcIdToken = ("MgcIdToTry" / "MG")
|
||
ModeToken = ("Mode" / "MO")
|
||
ModifyToken = ("Modify" / "MF")
|
||
ModemToken = ("Modem" / "MD")
|
||
MoveToken = ("Move" / "MV")
|
||
MTPToken = ("MTP")
|
||
MuxToken = ("Mux" / "MX")
|
||
NotifyToken = ("Notify" / "N")
|
||
NotifyCompletionToken = ("NotifyCompletion" / "NC")
|
||
ObservedEventsToken = ("ObservedEvents" / "OE")
|
||
OnewayToken = ("Oneway" / "OW")
|
||
OnOffToken = ("OnOff" / "OO")
|
||
OtherReasonToken = ("OtherReason" / "OR")
|
||
OutOfSvcToken = ("OutOfService" / "OS")
|
||
PackagesToken = ("Packages" / "PG")
|
||
PendingToken = ("Pending" / "PN")
|
||
PriorityToken = ("Priority" / "PR")
|
||
ProfileToken = ("Profile" / "PF")
|
||
ReasonToken = ("Reason" / "RE")
|
||
RecvonlyToken = ("ReceiveOnly" / "RC")
|
||
ReplyToken = ("Reply" / "P")
|
||
RestartToken = ("Restart" / "RS")
|
||
RemoteToken = ("Remote" / "R")
|
||
ReservedGroupToken = ("ReservedGroup" / "RG")
|
||
ReservedValueToken = ("ReservedValue" / "RV")
|
||
SendonlyToken = ("SendOnly" / "SO")
|
||
SendrecvToken = ("SendReceive" / "SR")
|
||
ServicesToken = ("Services" / "SV")
|
||
ServiceStatesToken = ("ServiceStates" / "SI")
|
||
ServiceChangeToken = ("ServiceChange" / "SC")
|
||
ServiceChangeAddressToken = ("ServiceChangeAddress" / "AD")
|
||
SignalListToken = ("SignalList" / "SL")
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 126]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
SignalsToken = ("Signals" / "SG")
|
||
SignalTypeToken = ("SignalType" / "SY")
|
||
StatsToken = ("Statistics" / "SA")
|
||
StreamToken = ("Stream" / "ST")
|
||
SubtractToken = ("Subtract" / "S")
|
||
SynchISDNToken = ("SynchISDN" / "SN")
|
||
TerminationStateToken = ("TerminationState" / "TS")
|
||
TestToken = ("Test" / "TE")
|
||
TimeOutToken = ("TimeOut" / "TO")
|
||
TopologyToken = ("Topology" / "TP")
|
||
TransToken = ("Transaction" / "T")
|
||
ResponseAckToken = ("TransactionResponseAck" / "K")
|
||
V18Token = ("V18")
|
||
V22Token = ("V22")
|
||
V22bisToken = ("V22b")
|
||
V32Token = ("V32")
|
||
V32bisToken = ("V32b")
|
||
V34Token = ("V34")
|
||
V76Token = ("V76")
|
||
V90Token = ("V90")
|
||
V91Token = ("V91")
|
||
VersionToken = ("Version" / "V")
|
||
|
||
B.3 Hexadecimal octet coding
|
||
|
||
Hexadecimal octet coding is a means for representing a string of
|
||
octets as a string of hexadecimal digits, with two digits
|
||
representing each octet. This octet encoding should be used when
|
||
encoding octet strings in the text version of the protocol. For each
|
||
octet, the 8-bit sequence is encoded as two hexadecimal digits. Bit
|
||
0 is the first transmitted; bit 7 is the last. Bits 7-4 are encoded
|
||
as the first hexadecimal digit, with Bit 7 as MSB and Bit 4 as LSB.
|
||
Bits 3-0 are encoded as the second hexadecimal digit, with Bit 3 as
|
||
MSB and Bit 0 as LSB. Examples:
|
||
|
||
Octet bit pattern Hexadecimal coding
|
||
00011011 D8
|
||
11100100 27
|
||
10000011 10100010 11001000 00001001 C1451390
|
||
|
||
B.4 Hexadecimal octet sequence
|
||
|
||
A hexadecimal octet sequence is an even number of hexadecimal digits,
|
||
terminated by a <CR> character.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 127]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ANNEX C - Tags for media stream properties
|
||
|
||
Parameters for Local, Remote and LocalControl descriptors are
|
||
specified as tag-value pairs if binary encoding is used for the
|
||
protocol. This annex contains the property names (PropertyID), the
|
||
tags (Property tag), type of the property (Type) and the values
|
||
(Value). Values presented in the Value field when the field contains
|
||
references shall be regarded as "information". The reference
|
||
contains the normative values. If a value field does not contain a
|
||
reference, then the values in that field can be considered as
|
||
"normative".
|
||
|
||
Tags are given as hexadecimal numbers in this annex. When setting
|
||
the value of a property, a MGC may underspecify the value according
|
||
to one of the mechanisms specified in 7.1.1.
|
||
|
||
It is optional to support the properties in this Annex or any of its
|
||
sub-sections. For example, only three properties from C.3 and only
|
||
five properties from C.8 might be implemented.
|
||
|
||
For type "enumeration" the value is represented by the value in
|
||
brackets, e.g., Send(0), Receive(1). Annex C properties with the
|
||
types "N bits" or "M Octets" should be treated as octet strings when
|
||
encoding the protocol. Properties with "N bit integer" shall be
|
||
treated as an integers. "String" shall be treated as an IA5String
|
||
when encoding the protocol.
|
||
|
||
When a type is smaller than one octet, the value shall be stored in
|
||
the low-order bits of an octet string of size 1.
|
||
|
||
C.1 General media attributes
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
Media 1001 Enumeration Audio(0), Video(1), Data(2)
|
||
|
||
Transmission 1002 Enumeration Send(0), Receive(1),
|
||
mode Send&Receive(2)
|
||
|
||
Number of 1003 Unsigned 0-255
|
||
Channels integer
|
||
|
||
Sampling 1004 Unsigned 0-2^32
|
||
rate integer
|
||
|
||
Bitrate 1005 Integer (0..4294967295)NOTE - Units of
|
||
100 bit/s.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 128]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ACodec 1006 Octet string Audio Codec Type:
|
||
Ref.: ITU-T Q.765
|
||
Non-ITU-T codecs are defined
|
||
with the appropriate standards
|
||
organization under a defined
|
||
Organizational Identifier.
|
||
|
||
Samplepp 1007 Unsigned Maximum samples or frames per
|
||
integer packet: 0..65535
|
||
|
||
Silencesupp 1008 Boolean Silence Suppression: True/False
|
||
|
||
Encrypttype 1009 Octet string Ref.: ITU-T H.245
|
||
|
||
Encryptkey 100A Octet string Encryption key
|
||
size Ref.: ITU-T H.235
|
||
(0..65535)
|
||
|
||
Echocanc 100B Not Used. See H.248.1 E.13 for
|
||
an example of possible Echo
|
||
Control properties.
|
||
|
||
Gain 100C Unsigned Gain in dB: 0..65535
|
||
integer
|
||
|
||
Jitterbuff 100D Unsigned Jitter buffer size in ms:
|
||
integer 0..65535
|
||
|
||
PropDelay 100E Unsigned Propagation Delay: 0..65535
|
||
integer Maximum propagation delay in
|
||
milliseconds for the bearer
|
||
connection between two media
|
||
gateways. The maximum delay
|
||
will be dependent on the bearer
|
||
technology.
|
||
|
||
RTPpayload 100F Integer Payload type in RTP Profile for
|
||
Audio and Video Conferences
|
||
with Minimal Control
|
||
Ref.: RFC 1890
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 129]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
C.2 Mux properties
|
||
|
||
PropertyID Property tag Type Value
|
||
|
||
H222 2001 Octet string H222LogicalChannelParameters
|
||
Ref.: ITU-T H.245
|
||
|
||
H223 2002 Octet string H223LogicalChannelParameters
|
||
Ref.: ITU-T H.245
|
||
|
||
V76 2003 Octet string V76LogicalChannelParameters
|
||
Ref.: ITU-T H.245
|
||
|
||
H2250 2004 Octet string H2250LogicalChannelParameters
|
||
Ref.: ITU-T H.245
|
||
|
||
C.3 General bearer properties
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
Mediatx 3001 Enumeration Media Transport TypeTDM
|
||
Circuit(0), ATM(1), FR(2),
|
||
Ipv4(3), Ipv6(4), ...
|
||
|
||
BIR 3002 4 octets Value depends on transport
|
||
technology
|
||
|
||
NSAP 3003 1-20 octets See NSAP.
|
||
Ref.: Annex A/X.213
|
||
|
||
C.4 General ATM properties
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
AESA 4001 20 octets ATM End System Address
|
||
|
||
VPVC 4002 4 octets: VPCI VPCI/VCI
|
||
in first two
|
||
least Ref.: ITU-T Q.2931
|
||
significant
|
||
octets, VCI in
|
||
second two
|
||
octets
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 130]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
SC 4003 Enumeration Service Category: CBR(0),
|
||
nrt-VBR1(1), nrt VBR2(2),
|
||
nrt-VBR3(3), rt-VBR1(4),
|
||
rt VBR2(5), rt-VBR3(6),
|
||
UBR1(7), UBR2(8), ABR(9).
|
||
Ref.: ATM Forum UNI 4.0
|
||
|
||
BCOB 4004 5-bit integer Broadband Bearer Class
|
||
Ref.: ITU-T Q.2961.2
|
||
|
||
BBTC 4005 7-bit integer Broadband Transfer Capability
|
||
Ref.: ITU-T Q.2961.1
|
||
|
||
ATC 4006 Enumeration I.371 ATM Traffic
|
||
CapabilityDBR(0), SBR1(1),
|
||
SBR2(2), SBR3(3), ABT/IT(4),
|
||
ABT/DT(5), ABR(6)
|
||
Ref.: ITU-T I.371
|
||
|
||
STC 4007 2 bits Susceptibility to clipping:
|
||
Bits
|
||
2 1
|
||
---
|
||
0 0 not susceptible to
|
||
clipping
|
||
0 1 susceptible to
|
||
clipping
|
||
Ref.: ITU-T Q.2931
|
||
|
||
UPCC 4008 2 bits User Plane Connection
|
||
configuration:
|
||
Bits
|
||
2 1
|
||
---
|
||
0 0 point-to-point
|
||
0 1 point-to-multipoint
|
||
Ref.: ITU-T Q.2931
|
||
|
||
PCR0 4009 24-bit integer Peak Cell Rate (For CLP = 0)
|
||
Ref.: ITU-T Q.2931
|
||
|
||
SCR0 400A 24-bit integer Sustainable Cell Rate (For
|
||
CLP = 0)
|
||
Ref.: ITU-T Q.2961.1
|
||
|
||
MBS0 400B 24-bit integer Maximum Burst Size (For CLP =
|
||
0)
|
||
Ref.: ITU-T Q.2961.1
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 131]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
PCR1 400C 24-bit integer Peak Cell Rate (For CLP = 0 +
|
||
1)
|
||
Ref.: ITU-T Q.2931
|
||
|
||
SCR1 400D 24-bit integer Sustainable Cell Rate (For
|
||
CLP = 0 + 1)
|
||
Ref.: ITU-T Q.2961.1
|
||
|
||
MBS1 400E 24-bit integer Maximum Burst Size (For CLP =
|
||
0 + 1)
|
||
Ref.: ITU-T Q.2961.1
|
||
|
||
BEI 400F Boolean Best Effort Indicator
|
||
Value 1 indicates that BEI is
|
||
to be included in the ATM
|
||
signaling; value 0 indicates
|
||
that BEI is not to be
|
||
included in the ATM
|
||
signaling.
|
||
Ref.: ATM Forum UNI 4.0
|
||
|
||
TI 4010 Boolean Tagging Indicator
|
||
Value 0 indicates that
|
||
tagging is not allowed; value
|
||
1 indicates that tagging is
|
||
requested.
|
||
Ref.: ITU-T Q.2961.1
|
||
|
||
FD 4011 Boolean Frame Discard
|
||
Value 0 indicates that no
|
||
frame discard is allowed;
|
||
value 1 indicates that frame
|
||
discard is allowed.
|
||
Ref.: ATM Forum UNI 4.0
|
||
|
||
A2PCDV 4012 24-bit integer Acceptable 2-point CDV
|
||
Ref.: ITU-T Q.2965.2
|
||
|
||
C2PCDV 4013 24-bit integer Cumulative 2-point CDV
|
||
Ref.: ITU-T Q.2965.2
|
||
|
||
APPCDV 4014 24-bit integer Acceptable P-P CDV
|
||
Ref.: ATM Forum UNI 4.0
|
||
|
||
CPPCDV 4015 24-bit integer Cumulative P-P CDV
|
||
Ref.: ATM Forum UNI 4.0
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 132]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ACLR 4016 8-bit integer Acceptable Cell Loss Ratio
|
||
Ref.: ITU-T Q.2965.2, ATM
|
||
Forum UNI 4.0
|
||
|
||
MEETD 4017 16-bit integer Maximum End-to-end transit
|
||
delay
|
||
Ref.: ITU-T Q.2965.2, ATM
|
||
Forum UNI 4.0
|
||
|
||
CEETD 4018 16-bit integer Cumulative End-to-end transit
|
||
delay
|
||
Ref.: ITU-T Q.2965.2, ATM
|
||
Forum UNI 4.0
|
||
|
||
QosClass 4019 Integer 0-5 QoS Class
|
||
|
||
QoS Class Meaning
|
||
|
||
0 Default QoS
|
||
associated
|
||
with the ATC
|
||
as defined
|
||
in ITU-T
|
||
Q.2961.2
|
||
|
||
1 Stringent
|
||
|
||
2 Tolerant
|
||
|
||
3 Bi-level
|
||
|
||
4 Unbounded
|
||
|
||
5 Stringent
|
||
Bi-level
|
||
Ref.: ITU-T Q.2965.1
|
||
|
||
AALtype 401A 1 octet AAL Type
|
||
Bits
|
||
8 7 6 5 4 3 2 1
|
||
---------------
|
||
0 0 0 0 0 0 0 0 AAL for
|
||
voice
|
||
0 0 0 0 0 0 0 1 AAL type 1
|
||
0 0 0 0 0 0 1 0 AAL type 2
|
||
0 0 0 0 0 0 1 1 AAL type
|
||
3/4
|
||
0 0 0 0 0 1 0 1 AAL type 5
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 133]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
0 0 0 1 0 0 0 0 user-
|
||
defined AAL
|
||
Ref.: ITU-T Q.2931
|
||
|
||
C.5 Frame Relay
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
DLCI 5001 Unsigned Data link connection
|
||
integer id
|
||
|
||
CID 5002 Unsigned sub-channel id
|
||
integer
|
||
|
||
SID/Noiselevel 5003 Unsigned silence insertion
|
||
integer descriptor
|
||
|
||
Primary Payload 5004 Unsigned Primary Payload Type
|
||
type integer Covers FAX and codecs
|
||
|
||
C.6 IP
|
||
|
||
PropertyID Property tag Type Value
|
||
|
||
IPv4 6001 32 bits Ipv4Address Ipv4Address
|
||
Ref.: IETF RFC 791
|
||
|
||
IPv6 6002 128 bits IPv6 Address
|
||
Ref.: IETF RFC 2460
|
||
|
||
Port 6003 Unsigned integer 0..65535
|
||
|
||
Porttype 6004 Enumerated TCP(0), UDP(1), SCTP(2)
|
||
|
||
|
||
C.7 ATM AAL2
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
AESA 7001 20 octets AAL2 service endpoint
|
||
address as defined in
|
||
the referenced
|
||
Recommendation.
|
||
ESEANSEA
|
||
Ref.: ITU-T Q.2630.1
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 134]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
BIR See C.3 4 octets Served user generated
|
||
reference as defined in
|
||
the referenced
|
||
Recommendation.
|
||
SUGR
|
||
Ref.: ITU-T Q.2630.1
|
||
|
||
ALC 7002 12 octets AAL2 link
|
||
characteristics as
|
||
defined in the
|
||
referenced
|
||
Recommendation.
|
||
Maximum/Average CPS-SDU
|
||
bit rate;
|
||
Maximum/Average CPS-SDU
|
||
size
|
||
Ref.: ITU-T Q.2630.1
|
||
|
||
SSCS 7003 I.366.2: Audio (8 Service specific
|
||
octets); Multirate (3 convergence sublayer
|
||
octets), or I.366.1: information as defined
|
||
SAR-assured (14 in:
|
||
octets);SAR-unassured - ITU-T Q.2630.1,and
|
||
(7 octets). used in:
|
||
- ITU-T I.366.2:
|
||
Audio/Multirate;
|
||
- ITU-T I.366.1: SAR-
|
||
assured/unassured.
|
||
Ref.: ITU-T Q.2630.1,
|
||
I.366.1 and I.366.2
|
||
|
||
SUT 7004 1..254 octets Served user transport
|
||
parameter as defined in
|
||
the referenced
|
||
Recommendation.
|
||
Ref.: ITU-T Q.2630.1
|
||
|
||
TCI 7005 Boolean Test connection
|
||
indicator as defined in
|
||
the referenced
|
||
Recommendation.
|
||
Ref.: ITU-T Q.2630.1
|
||
|
||
Timer_CU 7006 32-bit integer Timer-CU
|
||
Milliseconds to hold
|
||
partially filled cell
|
||
before sending.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 135]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
MaxCPSSDU 7007 8-bit integer Maximum Common Part
|
||
Sublayer Service Data
|
||
Unit
|
||
Ref.: ITU-T Q.2630.1
|
||
|
||
CID 7008 8 bits subchannel id: 0-255
|
||
Ref.: ITU-T I.363.2
|
||
C.8 ATM AAL1
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
BIR See table 4-29 octets GIT (Generic Identifier
|
||
in C.3 Transport)
|
||
Ref.: ITU-T Q.2941.1
|
||
|
||
AAL1ST 8001 1 octet AAL1 Subtype
|
||
Bits
|
||
8 7 6 5 4 3 2 1
|
||
---------------
|
||
0 0 0 0 0 0 0 0 null
|
||
0 0 0 0 0 0 0 1 voiceband
|
||
signal transport on 64 kbit/s
|
||
0 0 0 0 0 0 1 0 circuit
|
||
transport
|
||
0 0 0 0 0 1 0 0 high-quality
|
||
audio signal transport
|
||
0 0 0 0 0 1 0 1 video signal
|
||
transport
|
||
Ref.: ITU-T Q.2931
|
||
|
||
CBRR 8002 1 octet CBR Rate
|
||
Bits
|
||
8 7 6 5 4 3 2 1
|
||
---------------
|
||
0 0 0 0 0 0 0 1 64 kbit/s
|
||
0 0 0 0 0 1 0 0 1544 kbit/s
|
||
0 0 0 0 0 1 0 1 6312 kbit/s
|
||
0 0 0 0 0 1 1 0 32 064 kbit/s
|
||
0 0 0 0 0 1 1 1 44 736 kbit/s
|
||
0 0 0 0 1 0 0 0 97 728 kbit/s
|
||
0 0 0 1 0 0 0 0 2048 kbit/s
|
||
0 0 0 1 0 0 0 1 8448 kbit/s
|
||
0 0 0 1 0 0 1 0 34 368 kbit/s
|
||
0 0 0 1 0 0 1 1 139 264 kbit/s
|
||
0 1 0 0 0 0 0 0 n x 64 kbit/s
|
||
0 1 0 0 0 0 0 1 n x 8 kbit/s
|
||
Ref.: ITU-T Q.2931
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 136]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
MULT See table Multiplier, or n x 64k/8k/300
|
||
in C.9 Ref.: ITU-T Q.2931
|
||
|
||
SCRI 8003 1 octet Source Clock Frequency Recovery
|
||
Method
|
||
Bits
|
||
8 7 6 5 4 3 2 1
|
||
---------------
|
||
0 0 0 0 0 0 0 0 null
|
||
0 0 0 0 0 0 0 1 SRTS
|
||
0 0 0 0 0 0 1 0 ACM
|
||
Ref.: ITU-T Q.2931
|
||
|
||
ECM 8004 1 octet Error Correction Method
|
||
Bits
|
||
8 7 6 5 4 3 2 1
|
||
---------------
|
||
0 0 0 0 0 0 0 0 null
|
||
0 0 0 0 0 0 0 1 FEC - Loss
|
||
0 0 0 0 0 0 1 0 FEC - Delay
|
||
Ref.: ITU-T Q.2931
|
||
|
||
SDTB 8005 16-bit Structured Data Transfer
|
||
integer Blocksize
|
||
Block size of SDT CBR service
|
||
Ref.: ITU-T I.363.1
|
||
|
||
PFCI 8006 8-bit Partially filled cells identifier
|
||
integer 1-47
|
||
Ref.: ITU-T I.363.1
|
||
|
||
C.9 Bearer capabilities
|
||
|
||
The table entries referencing Recommendation Q.931 refer to the
|
||
encoding in the bearer capability information element of Q.931, not
|
||
to the low layer information element.
|
||
|
||
PropertyID Tag Type Value
|
||
|
||
TMR 9001 1 octet Transmission Medium
|
||
Requirement (Q.763)
|
||
Bits
|
||
87654321
|
||
--------
|
||
00000000 speech
|
||
00000001 spare
|
||
00000010 64 kbit/s
|
||
unrestricted
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 137]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
00000011 3.1 kHz audio
|
||
00000100 reserved for
|
||
alternate speech (service
|
||
2)/64 kbit/s unrestricted
|
||
(service 1)
|
||
00000101 reserved for
|
||
alternate 64 kbit/s
|
||
unrestricted (service
|
||
1)/speech (service 2)
|
||
00000110 64 kbit/s preferred
|
||
|
||
The assigned codepoints
|
||
listed below are all for
|
||
unrestricted service.
|
||
00000111 2 x 64 kbit/s
|
||
00001000 384 kbit/s
|
||
00001001 1536 kbit/s
|
||
00001010 1920 kbit/s
|
||
00001011
|
||
through
|
||
00001111 spare
|
||
00010000
|
||
through
|
||
00101010:
|
||
3 x 64 kbit/s through
|
||
29 x 64 kbit/s
|
||
except
|
||
00010011 spare
|
||
00100101 spare
|
||
|
||
00101011
|
||
through
|
||
11111111 spare
|
||
Ref.: ITU-T Q.763
|
||
|
||
TMRSR 9002 1 octet Transmission Medium
|
||
Requirement Subrate
|
||
0 unspecified
|
||
1 8 kbit/s
|
||
2 16 kbit/s
|
||
3 32 kbit/s
|
||
|
||
Contcheck 9003 Boolean Continuity Check
|
||
0 continuity check not
|
||
required on this circuit
|
||
1 continuity check
|
||
required on this circuit
|
||
Ref.: ITU-T Q.763
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 138]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
ITC 9004 5 bits Information Transfer
|
||
Capability
|
||
Bits
|
||
5 4 3 2 1
|
||
---------
|
||
0 0 0 0 0 Speech
|
||
0 1 0 0 0 Unrestricted
|
||
digital information
|
||
0 1 0 0 1 Restricted
|
||
digital information
|
||
1 0 0 0 0 3.1 kHz audio
|
||
1 0 0 0 1 Unrestricted
|
||
digital information with
|
||
tones/announcements
|
||
1 1 0 0 0 Video
|
||
All other values are
|
||
reserved.
|
||
Ref.: ITU-T Q.763
|
||
|
||
TransMode 9005 2 bits Transfer Mode
|
||
Bits
|
||
2 1
|
||
---
|
||
0 0 Circuit mode
|
||
1 0 Packet mode
|
||
Ref.: ITU-T Q.931
|
||
|
||
TransRate 9006 5 bits Transfer Rate
|
||
Bits
|
||
5 4 3 2 1
|
||
---------
|
||
0 0 0 0 0 This code shall
|
||
be used for packet mode calls
|
||
1 0 0 0 0 64 kbit/s
|
||
1 0 0 0 1 2 x 64 kbit/s
|
||
1 0 0 1 1 384 kbit/s
|
||
1 0 1 0 1 1536 kbit/s
|
||
1 0 1 1 1 1920 kbit/s
|
||
1 1 0 0 0 Multirate (64
|
||
kbit/s base rate)
|
||
Ref.: ITU-T Q.931
|
||
|
||
MULT 9007 7 bits Rate Multiplier
|
||
Any value from 2 to n
|
||
(maximum number of B-
|
||
channels)
|
||
Ref.: ITU-T Q.931
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 139]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
layer1prot 9008 5 bits User Information Layer 1
|
||
Protocol
|
||
Bits
|
||
5 4 3 2 1
|
||
---------
|
||
0 0 0 0 1 ITU-T
|
||
standardized rate adaption
|
||
V.110 and X.30.
|
||
0 0 0 1 0 Recommendation
|
||
G.711 m-law
|
||
0 0 0 1 1 Recommendation
|
||
G.711 A-law
|
||
0 0 1 0 0 Recommendation
|
||
G.721 32 kbit/s ADPCM and
|
||
Recommendation I.460
|
||
0 0 1 0 1 Recommendations
|
||
H.221 and H.242
|
||
0 0 1 1 0 Recommendations
|
||
H.223 and H.245
|
||
0 0 1 1 1 Non-ITU-T
|
||
standardized rate adaption.
|
||
0 1 0 0 0 ITU-T
|
||
standardized rate adaption
|
||
V.120.
|
||
0 1 0 0 1 ITU-T
|
||
standardized rate adaption
|
||
X.31 HDLC flag stuffing
|
||
All other values are
|
||
reserved.
|
||
Ref.: ITU Recommendation
|
||
Q.931
|
||
|
||
syncasync 9009 Boolean Synchronous/Asynchronous
|
||
0 Synchronous data
|
||
1 Asynchronous data
|
||
Ref.: ITU-T Q.931
|
||
|
||
negotiation 900A Boolean Negotiation
|
||
0 In-band negotiation
|
||
possible
|
||
1 In-band negotiation not
|
||
possible
|
||
Ref.: ITU-T Q.931
|
||
|
||
Userrate 900B 5 bits User Rate
|
||
Bits
|
||
5 4 3 2 1
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 140]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
---------
|
||
0 0 0 0 0 Rate is
|
||
indicated by E-bits specified
|
||
in Recommendation I.460 or
|
||
may be negotiated in-band
|
||
0 0 0 0 1 0.6 kbit/s
|
||
Recommendations V.6 and X.1
|
||
0 0 0 1 0 1.2 kbit/s
|
||
Recommendation V.6
|
||
0 0 0 1 1 2.4 kbit/s
|
||
Recommendations V.6 and X.1
|
||
0 0 1 0 0 3.6 kbit/s
|
||
Recommendation V.6
|
||
0 0 1 0 1 4.8 kbit/s
|
||
Recommendations V.6 and X.1
|
||
0 0 1 1 0 7.2 kbit/s
|
||
Recommendation V.6
|
||
0 0 1 1 1 8 kbit/s
|
||
Recommendation I.460
|
||
0 1 0 0 0 9.6 kbit/s
|
||
Recommendations V.6 and X.1
|
||
0 1 0 0 1 14.4 kbit/s
|
||
Recommendation V.6
|
||
0 1 0 1 0 16 kbit/s
|
||
Recommendation I.460
|
||
0 1 0 1 1 19.2 kbit/s
|
||
Recommendation V.6
|
||
0 1 1 0 0 32 kbit/s
|
||
Recommendation I.460
|
||
0 1 1 0 1 38.4 kbit/s
|
||
Recommendation V.110
|
||
0 1 1 1 0 48 kbit/s
|
||
Recommendations V.6 and X.1
|
||
0 1 1 1 1 56 kbit/s
|
||
Recommendation V.6
|
||
1 0 0 1 0 57.6 kbit/s
|
||
Recommendation V.14 extended
|
||
1 0 0 1 1 28.8 kbit/s
|
||
Recommendation V.110
|
||
1 0 1 0 0 24 kbit/s
|
||
Recommendation V.110
|
||
1 0 1 0 1 0.1345 kbit/s
|
||
Recommendation X.1
|
||
1 0 1 1 0 0.100 kbit/s
|
||
Recommendation X.1
|
||
1 0 1 1 1 0.075/1.2
|
||
kbit/s Recommendations V.6
|
||
and X.1
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 141]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
1 1 0 0 0 1.2/0.075
|
||
kbit/s Recommendations V.6
|
||
and X.1
|
||
1 1 0 0 1 0.050 kbit/s
|
||
Recommendations V.6 and X.1
|
||
1 1 0 1 0 0.075 kbit/s
|
||
Recommendations V.6 and X.1
|
||
1 1 0 1 1 0.110 kbit/s
|
||
Recommendations V.6 and X.1
|
||
1 1 1 0 0 0.150 kbit/s
|
||
Recommendations V.6 and X.1
|
||
1 1 1 0 1 0.200 kbit/s
|
||
Recommendations V.6 and X.1
|
||
1 1 1 1 0 0.300 kbit/s
|
||
Recommendations V.6 and X.1
|
||
1 1 1 1 1 12 kbit/s
|
||
Recommendation V.6
|
||
All other values are
|
||
reserved.
|
||
Ref.: ITU-T Q.931
|
||
INTRATE 900C 2 bits Intermediate Rate
|
||
Bits
|
||
2 1
|
||
---
|
||
0 0 Not used
|
||
0 1 8 kbit/s
|
||
1 0 16 kbit/s
|
||
1 1 32 kbit/s
|
||
Ref.: ITU-T Q.931
|
||
|
||
nictx 900D Boolean Network Independent Clock
|
||
(NIC) on transmission
|
||
0 Not required to send
|
||
data with network independent
|
||
clock
|
||
1 Required to send data
|
||
with network independent
|
||
clock
|
||
Ref.: ITU-T Q.931
|
||
|
||
nicrx 900E Boolean Network independent clock
|
||
(NIC) on reception
|
||
0 Cannot accept data with
|
||
network independent clock
|
||
(i.e., sender does not support
|
||
this optional procedure)
|
||
1 Can accept data with
|
||
network independent clock
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 142]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
(i.e., sender does support
|
||
this optional procedure)
|
||
Ref.: ITU-T Q.931
|
||
|
||
flowconttx 900F Boolean Flow Control on transmission
|
||
(Tx)
|
||
0 Not required to send
|
||
data with flow control
|
||
mechanism
|
||
1 Required to send data
|
||
with flow control mechanism
|
||
Ref.: ITU-T Q.931
|
||
|
||
flowcontrx 9010 Boolean Flow control on reception
|
||
(Rx)
|
||
0 Cannot accept data with
|
||
flow control mechanism (i.e.,
|
||
sender does not support this
|
||
optional procedure)
|
||
1 Can accept data with
|
||
flow control mechanism (i.e.,
|
||
sender does support this
|
||
optional procedure)
|
||
Ref.: ITU-T Q.931
|
||
|
||
rateadapthdr 9011 Boolean Rate adaption header/no
|
||
header
|
||
0 Rate adaption header
|
||
not included
|
||
1 Rate adaption header
|
||
included
|
||
Ref.: ITU-T Q.931
|
||
|
||
multiframe 9012 Boolean Multiple frame establishment
|
||
support in data link
|
||
0 Multiple frame
|
||
establishment not supported.
|
||
Only UI frames allowed
|
||
1 Multiple frame
|
||
establishment supported
|
||
Ref.: ITU-T Q.931
|
||
|
||
OPMODE 9013 Boolean Mode of operation
|
||
0 Bit transparent mode of
|
||
operation
|
||
1 Protocol sensitive mode
|
||
of operation
|
||
Ref.: ITU-T Q.931
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 143]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
llidnegot 9014 Boolean Logical link identifier
|
||
negotiation
|
||
0 Default, LLI = 256 only
|
||
1 Full protocol
|
||
negotiation
|
||
Ref.: ITU-T Q.931
|
||
|
||
assign 9015 Boolean Assignor/assignee
|
||
0 Message originator is
|
||
"default assignee"
|
||
1 Message originator is
|
||
"assignor only"
|
||
Ref.: ITU-T Q.931
|
||
|
||
inbandneg 9016 Boolean In-band/out-band negotiation
|
||
0 Negotiation is done
|
||
with USER INFORMATION
|
||
messages on a temporary
|
||
signalling connection
|
||
1 Negotiation is done in-
|
||
band using logical link zero
|
||
Ref.: ITU-T Q.931
|
||
|
||
stopbits 9017 2 bits Number of stop bits
|
||
Bits
|
||
2 1
|
||
---
|
||
0 0 Not used
|
||
0 1 1 bit
|
||
1 0 1.5 bits
|
||
1 1 2 bits
|
||
Ref.: ITU-T Q.931
|
||
|
||
databits 9018 2 bits Number of data bits excluding
|
||
parity bit if present
|
||
Bits
|
||
2 1
|
||
---
|
||
0 0 Not used
|
||
0 1 5 bits
|
||
1 0 7 bits
|
||
1 1 8 bits
|
||
Ref.: ITU-T Q.931
|
||
|
||
parity 9019 3 bits Parity information
|
||
Bits
|
||
3 2 1
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 144]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
------
|
||
0 0 0 Odd
|
||
0 1 0 Even
|
||
0 1 1 None
|
||
1 0 0 Forced to 0
|
||
1 0 1 Forced to 1
|
||
All other values are
|
||
reserved.
|
||
Ref.: ITU-T Q.931
|
||
|
||
duplexmode 901A Boolean Mode duplex
|
||
0 Half duplex
|
||
1 Full duplex
|
||
Ref.: ITU-T Q.931
|
||
|
||
modem 901B 6 bits Modem Type
|
||
Bits
|
||
6 5 4 3 2 1
|
||
-----------
|
||
0 0 0 0 0 0 through
|
||
0 0 0 1 0 1 National use
|
||
0 1 0 0 0 1 Rec. V.21
|
||
0 1 0 0 1 0 Rec. V.22
|
||
0 1 0 0 1 1 Rec. V.22 bis
|
||
0 1 0 1 0 0 Rec. V.23
|
||
0 1 0 1 0 1 Rec. V.26
|
||
0 1 1 0 0 1 Rec. V.26 bis
|
||
0 1 0 1 1 1 Rec. V.26 ter
|
||
0 1 1 0 0 0 Rec. V.27
|
||
0 1 1 0 0 1 Rec. V.27 bis
|
||
0 1 1 0 1 0 Rec. V.27 ter
|
||
0 1 1 0 1 1 Rec. V.29
|
||
0 1 1 1 0 1 Rec. V.32
|
||
0 1 1 1 1 0 Rec. V.34
|
||
1 0 0 0 0 0 through
|
||
1 0 1 1 1 1 National use
|
||
1 1 0 0 0 0 through
|
||
1 1 1 1 1 1 User specified
|
||
Ref.: ITU-T Q.931
|
||
|
||
layer2prot 901C 5 bits User information layer 2
|
||
protocol
|
||
Bits
|
||
5 4 3 2 1
|
||
---------
|
||
0 0 0 1 0 Rec. Q.921/I.441
|
||
0 0 1 1 0 Rec. X.25, link
|
||
layer
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 145]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
0 1 1 0 0 LAN logical link
|
||
control (ISO/IEC 8802 2)
|
||
All other values are
|
||
reserved.
|
||
Ref.: ITU-T Q.931
|
||
|
||
layer3prot 901D 5 bits User information layer 3
|
||
protocol
|
||
Bits
|
||
5 4 3 2 1
|
||
---------
|
||
0 0 0 1 0 ITU-T Q.931
|
||
0 0 1 1 0 ITU-T X.25,
|
||
packet layer
|
||
0 1 0 1 1 ISO/IEC TR 9577
|
||
(Protocol identification in
|
||
the network layer)
|
||
All other values are
|
||
reserved.
|
||
Ref.: ITU-T Q.931
|
||
|
||
addlayer3prot 901E Octet Additional User Information
|
||
layer 3 protocol
|
||
Bits Bits
|
||
4 3 2 1 4 3 2 1
|
||
------- -------
|
||
1 1 0 0 1 1 0 0
|
||
Internet Protocol (RFC 791)
|
||
(ISO/IEC TR 9577)
|
||
1 1 0 0 1 1 1 1
|
||
Point-to-point Protocol (RFC
|
||
1661)
|
||
Ref.: ITU-T Q.931
|
||
|
||
DialledN 901F 30 Dialled Number
|
||
octets
|
||
|
||
DiallingN 9020 30 Dialling Number
|
||
octets
|
||
|
||
ECHOCI 9021 Not Used. See H.248.1 E.13
|
||
for an example of possible
|
||
Echo Control properties.
|
||
|
||
NCI 9022 1 octet Nature of Connection
|
||
Indicators
|
||
Bits
|
||
2 1 Satellite Indicator
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 146]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
---
|
||
0 0 no satellite circuit
|
||
in the connection
|
||
0 1 one satellite circuit
|
||
in the connection
|
||
1 0 two satellite
|
||
circuits in the connection
|
||
1 1 spare
|
||
|
||
Bits
|
||
4 3 Continuity check
|
||
--- indicator
|
||
0 0 continuity check not
|
||
required
|
||
0 1 continuity check
|
||
required on this circuit
|
||
1 0 continuity check
|
||
performed on a previous
|
||
circuit
|
||
1 1 spare
|
||
|
||
Bit
|
||
5 Echo control device
|
||
- indicator
|
||
0 outgoing echo control
|
||
device not included
|
||
1 outgoing echo control
|
||
device included
|
||
|
||
Bits
|
||
8 7 6 Spare
|
||
Ref.: ITU-T Q.763
|
||
|
||
USI 9023 Octet User Service Information
|
||
string Ref.: ITU-T Q.763 Clause 3.57
|
||
|
||
C.10 AAL5 properties
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
FMSDU A001 32-bit Forward Maximum CPCS-SDU Size:
|
||
integer Maximum CPCS-SDU size sent in the
|
||
direction from the calling user to
|
||
the called user.
|
||
Ref.: ITU-T Q.2931
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 147]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
BMSDU A002 32-bit Backwards Maximum CPCS-SDU Size:
|
||
integer Maximum CPCS-SDU size sent in the
|
||
direction from the called user to
|
||
the calling user.
|
||
Ref.: ITU-T Q.2931
|
||
|
||
SSCS See table See table See table in C.7
|
||
in C.7 in C.7 Additional values:
|
||
VPI/VCI
|
||
|
||
C.11 SDP equivalents
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
SDP_V B001 String Protocol Version
|
||
Ref.: RFC 2327
|
||
|
||
SDP_O B002 String Owner/creator and session ID
|
||
Ref.: RFC 2327
|
||
|
||
SDP_S B003 String Session name
|
||
Ref.: RFC 2327
|
||
|
||
SDP_I B004 String Session identifier
|
||
Ref.: RFC 2327
|
||
|
||
SDP_U B005 String URI of descriptor
|
||
Ref.: RFC 2327
|
||
|
||
SDC_E B006 String email address
|
||
Ref.: RFC 2327
|
||
|
||
SDP_P B007 String phone number
|
||
Ref.: RFC 2327
|
||
|
||
SDP_C B008 String Connection information
|
||
Ref.: RFC 2327
|
||
|
||
SDP_B B009 String Bandwidth Information
|
||
Ref.: RFC 2327
|
||
|
||
SDP_Z B00A String Time zone adjustment
|
||
Ref.: RFC 2327
|
||
|
||
SDP_K B00B String Encryption Key
|
||
Ref.: RFC 2327
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 148]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
SDP_A B00C String Zero or more session attributes
|
||
Ref.: RFC 2327
|
||
|
||
SDP_T B00D String Active Session Time
|
||
Ref.: RFC 2327
|
||
|
||
SDP_R B00E String Zero or more repeat times
|
||
Reference: RFC 2327
|
||
|
||
SDP_M B00F String Media type, port, transport and format
|
||
Ref.: RFC 2327
|
||
|
||
C.12 H.245
|
||
|
||
PropertyID Property Type Value
|
||
tag
|
||
|
||
OLC C001 Octet The value of H.245
|
||
OpenLogicalChannel structure.
|
||
string Ref.: ITU-T H.245
|
||
|
||
OLCack C002 Octet The value of H.245
|
||
string OpenLogicalChannelAck structure.
|
||
Ref.: ITU-T H.245
|
||
|
||
OLCcnf C003 Octet The value of H.245
|
||
string OpenLogicalChannelConfirm structure.
|
||
Ref.: ITU-T H.245
|
||
|
||
OLCrej C004 Octet The value of H.245
|
||
string OpenLogicalChannelReject structure.
|
||
Ref.: ITU-T H.245
|
||
|
||
CLC C005 Octet The value of H.245
|
||
string CloseLogicalChannel structure.
|
||
Ref.: ITU-T H.245
|
||
|
||
CLCack C006 Octet The value of H.245
|
||
string CloseLogicalChannelAck structure.
|
||
Ref.: ITU-T H.245
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 149]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ANNEX D - Transport over IP
|
||
|
||
D.1 Transport over IP/UDP using Application Level Framing (ALF)
|
||
|
||
Protocol messages defined in this RFC may be transmitted over UDP.
|
||
When no port is provided by the peer (see 7.2.8), commands should be
|
||
sent to the default port number: 2944 for text-encoded operation, or
|
||
2945 for binary-encoded operation. Responses must be sent to the
|
||
address and port from which the corresponding commands were sent.
|
||
|
||
ALF is a set of techniques that allows an application, as opposed to
|
||
a stack, to affect how messages are sent to the other side. A
|
||
typical ALF technique is to allow an application to change the order
|
||
of messages sent when there is a queue after it has queued them.
|
||
There is no formal specification for ALF. The procedures in Annex
|
||
D.1 contain a minimum suggested set of ALF behaviours
|
||
|
||
Implementors using IP/UDP with ALF should be aware of the
|
||
restrictions of the MTU on the maximum message size.
|
||
|
||
D.1.1 Providing At-Most-Once functionality
|
||
|
||
Messages, being carried over UDP, may be subject to losses. In the
|
||
absence of a timely response, commands are repeated. Most commands
|
||
are not idempotent. The state of the MG would become unpredictable
|
||
if, for example, Add commands were executed several times. The
|
||
transmission procedures shall thus provide an "At-Most-Once"
|
||
functionality.
|
||
|
||
Peer protocol entities are expected to keep in memory a list of the
|
||
responses that they sent to recent transactions and a list of the
|
||
transactions that are currently outstanding. The transaction
|
||
identifier of each incoming message is compared to the transaction
|
||
identifiers of the recent responses sent to the same MId. If a match
|
||
is found, the entity does not execute the transaction, but simply
|
||
repeats the response. If no match is found, the message will be
|
||
compared to the list of currently outstanding transactions. If a
|
||
match is found in that list, indicating a duplicate transaction, the
|
||
entity does not execute the transaction (see D.1.4 for procedures on
|
||
sending TransactionPending).
|
||
|
||
The procedure uses a long timer value, noted LONG-TIMER in the
|
||
following. The timer should be set larger than the maximum duration
|
||
of a transaction, which should take into account the maximum number
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 150]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
of repetitions, the maximum value of the repetition timer and the
|
||
maximum propagation delay of a packet in the network. A suggested
|
||
value is 30 seconds.
|
||
|
||
The copy of the responses may be destroyed either LONG-TIMER seconds
|
||
after the response is issued, or when the entity receives a
|
||
confirmation that the response has been received, through the
|
||
"Response Acknowledgement parameter". For transactions that are
|
||
acknowledged through this parameter, the entity shall keep a copy of
|
||
the transaction-id for LONG-TIMER seconds after the response is
|
||
issued, in order to detect and ignore duplicate copies of the
|
||
transaction request that could be produced by the network.
|
||
|
||
D.1.2 Transaction identifiers and three-way handshake
|
||
|
||
D.1.2.1 Transaction identifiers
|
||
|
||
Transaction identifiers are 32-bit integer numbers. A Media Gateway
|
||
Controller may decide to use a specific number space for each of the
|
||
MGs that they manage, or to use the same number space for all MGs
|
||
that belong to some arbitrary group. MGCs may decide to share the
|
||
load of managing a large MG between several independent processes.
|
||
These processes will share the same transaction number space. There
|
||
are multiple possible implementations of this sharing, such as having
|
||
a centralized allocation of transaction identifiers, or
|
||
pre-allocating non-overlapping ranges of identifiers to different
|
||
processes. The implementations shall guarantee that unique
|
||
transaction identifiers are allocated to all transactions that
|
||
originate from a logical MGC (identical mId). MGs can simply detect
|
||
duplicate transactions by looking at the transaction identifier and
|
||
mId only.
|
||
|
||
D.1.2.2 Three-way handshake
|
||
|
||
The TransactionResponse Acknowledgement parameter can be found in any
|
||
message. It carries a set of "confirmed transaction-id ranges".
|
||
Entities may choose to delete the copies of the responses to
|
||
transactions whose id is included in "confirmed transaction-id
|
||
ranges" received in the transaction response messages. They should
|
||
silently discard further commands when the transaction-id falls
|
||
within these ranges.
|
||
|
||
The "confirmed transaction-id ranges" values shall not be used if
|
||
more than LONG-TIMER seconds have elapsed since the MG issued its
|
||
last response to that MGC, or when a MG resumes operation. In this
|
||
situation, transactions should be accepted and processed, without any
|
||
test on the transaction-id.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 151]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Messages that carry the "Transaction Response Acknowledgement"
|
||
parameter may be transmitted in any order. The entity shall retain
|
||
the "confirmed transaction-id ranges" received for LONG-TIMER
|
||
seconds.
|
||
|
||
In the binary encoding, if only the firstAck is present in a response
|
||
acknowledgement (see A.2), only one transaction is acknowledged. If
|
||
both firstAck and lastAck are present, then the range of transactions
|
||
from firstAck to lastAck is acknowledged. In the text encoding, a
|
||
horizontal dash is used to indicate a range of transactions being
|
||
acknowledged (see B.2).
|
||
|
||
D.1.3 Computing retransmission timers
|
||
|
||
It is the responsibility of the requesting entity to provide suitable
|
||
timeouts for all outstanding transactions, and to retry transactions
|
||
when timeouts have been exceeded. Furthermore, when repeated
|
||
transactions fail to be acknowledged, it is the responsibility of the
|
||
requesting entity to seek redundant services and/or clear existing or
|
||
pending connections.
|
||
|
||
The specification purposely avoids specifying any value for the
|
||
retransmission timers. These values are typically network dependent.
|
||
The retransmission timers should normally estimate the timer value by
|
||
measuring the time spent between the sending of a command and the
|
||
return of a response. Implementations SHALL ensure that the
|
||
algorithm used to calculate retransmission timing performs an
|
||
exponentially increasing backoff of the retransmission timeout for
|
||
each retransmission or repetition after the first one.
|
||
|
||
NOTE - One possibility is to use the algorithm implemented in
|
||
TCP-IP, which uses two variables:
|
||
|
||
- The average acknowledgement delay (AAD), estimated through an
|
||
exponentially smoothed average of the observed delays.
|
||
|
||
- The average deviation (ADEV), estimated through an exponentially
|
||
smoothed average of the absolute value of the difference between
|
||
the observed delay and the current average. The retransmission
|
||
timer, in TCP, is set to the sum of the average delay plus N times
|
||
the average deviation. The maximum value of the timer should
|
||
however be bounded for the protocol defined in this
|
||
RFC, in order to guarantee that no repeated packet
|
||
would be received by the gateways after LONG-TIMER seconds. A
|
||
suggested maximum value is 4 seconds.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 152]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
After any retransmission, the entity SHOULD do the following:
|
||
|
||
- It should double the estimated value of the average delay, AAD.
|
||
|
||
- It should compute a random value, uniformly distributed between
|
||
0.5 AAD and AAD.
|
||
|
||
- It should set the retransmission timer to the sum of that random
|
||
value and N times the average deviation.
|
||
|
||
This procedure has two effects. Because it includes an exponentially
|
||
increasing component, it will automatically slow down the stream of
|
||
messages in case of congestion. Because it includes a random
|
||
component, it will break the potential synchronization between
|
||
notifications triggered by the same external event.
|
||
|
||
D.1.4 Provisional responses
|
||
|
||
Executing some transactions may require a long time. Long execution
|
||
times may interact with the timer-based retransmission procedure.
|
||
This may result either in an inordinate number of retransmissions, or
|
||
in timer values that become too long to be efficient. Entities that
|
||
can predict that a transaction will require a long execution time may
|
||
send a provisional response, "Transaction Pending". They SHOULD send
|
||
this response if they receive a repetition of a transaction that is
|
||
still being executed.
|
||
|
||
Entities that receive a Transaction Pending shall switch to a
|
||
different repetition timer for repeating requests. The root
|
||
Termination has a property (ProvisionalResponseTimerValue), which can
|
||
be set to the requested maximum number of milliseconds between
|
||
receipt of a command and transmission of the TransactionPending
|
||
response. Upon receipt of a final response following receipt of
|
||
provisional responses, an immediate confirmation shall be sent, and
|
||
normal repetition timers shall be used thereafter. An entity that
|
||
sends a provisional response, SHALL include the immAckRequired field
|
||
in the ensuing final response, indicating that an immediate
|
||
confirmation is expected. Receipt of a Transaction Pending after
|
||
receipt of a reply shall be ignored.
|
||
|
||
D.1.5 Repeating Requests, Responses and Acknowledgements
|
||
|
||
The protocol is organized as a set of transactions, each of which is
|
||
composed of a request and a response, commonly referred to as an
|
||
acknowledgement. The protocol messages, being carried over UDP, may
|
||
be subject to losses. In the absence of a timely response,
|
||
transactions are repeated. Entities are expected to keep in memory a
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 153]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
list of the responses that they sent to recent transactions, i.e., a
|
||
list of all the responses they sent over the last LONG-TIMER seconds,
|
||
and a list of the transactions that are currently being executed.
|
||
|
||
The repetition mechanism is used to guard against three types of
|
||
possible errors:
|
||
|
||
- transmission errors, when for example a packet is lost due to
|
||
noise on a line or congestion in a queue;
|
||
|
||
- component failure, when for example an interface to a entity
|
||
becomes unavailable;
|
||
|
||
- entity failure, when for example an entire entity becomes
|
||
unavailable.
|
||
|
||
The entities should be able to derive from the past history an
|
||
estimate of the packet loss rate due to transmission errors. In a
|
||
properly configured system, this loss rate should be kept very low,
|
||
typically less than 1%. If a Media Gateway Controller or a Media
|
||
Gateway has to repeat a message more than a few times, it is very
|
||
legitimate to assume that something else than a transmission error is
|
||
occurring. For example, given a loss rate of 1%, the probability
|
||
that five consecutive transmission attempts fail is 1 in 100 billion,
|
||
an event that should occur less than once every 10 days for a Media
|
||
Gateway Controller that processes 1000 transactions per second.
|
||
(Indeed, the number of repetition that is considered excessive should
|
||
be a function of the prevailing packet loss rate.) We should note
|
||
that the "suspicion threshold", which we will call "Max1", is
|
||
normally lower than the "disconnection threshold", which should be
|
||
set to a larger value.
|
||
|
||
A classic retransmission algorithm would simply count the number of
|
||
successive repetitions, and conclude that the association is broken
|
||
after retransmitting the packet an excessive number of times
|
||
(typically between 7 and 11 times.) In order to account for the
|
||
possibility of an undetected or in progress "failover", we modify
|
||
the classic algorithm so that if the Media Gateway receives a valid
|
||
ServiceChange message announcing a failover, it will start
|
||
transmitting outstanding commands to that new MGC. Responses to
|
||
commands are still transmitted to the source address of the command.
|
||
|
||
In order to automatically adapt to network load, this RFC specifies
|
||
exponentially increasing timers. If the initial timer is set to 200
|
||
milliseconds, the loss of a fifth retransmission will be detected
|
||
after about 6 seconds. This is probably an acceptable waiting delay
|
||
to detect a failover. The repetitions should continue after that
|
||
delay not only in order to perhaps overcome a transient connectivity
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 154]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
problem, but also in order to allow some more time for the execution
|
||
of a failover (waiting a total delay of 30 seconds is probably
|
||
acceptable).
|
||
|
||
It is, however, important that the maximum delay of retransmissions
|
||
be bounded. Prior to any retransmission, it is checked that the time
|
||
elapsed since the sending of the initial datagram is no greater than
|
||
T-MAX. If more than T-MAX time has elapsed, the MG concludes that
|
||
the MGC has failed, and it begins its recovery process as described
|
||
in section 11.5. If the MG retries to connect to the current MGC it
|
||
shall use a ServiceChange with ServiceChangeMethod set to
|
||
Disconnected so that the new MGC will be aware that the MG lost one
|
||
or more transactions. The value T-MAX is related to the LONG-TIMER
|
||
value: the LONG-TIMER value is obtained by adding to T MAX the
|
||
maximum propagation delay in the network.
|
||
|
||
D.2 Using TCP
|
||
|
||
Protocol messages as defined in this RFC may be transmitted over TCP.
|
||
When no port is specified by the other side (see 7.2.8), the commands
|
||
should be sent to the default port. The defined protocol has
|
||
messages as the unit of transfer, while TCP is a stream-oriented
|
||
protocol. TPKT, according to RFC 1006, SHALL be used to delineate
|
||
messages within the TCP stream.
|
||
|
||
In a transaction-oriented protocol, there are still ways for
|
||
transaction requests or responses to be lost. As such, it is
|
||
recommended that entities using TCP transport implement application
|
||
level timers for each request and each response, similar to those
|
||
specified for application level framing over UDP.
|
||
|
||
D.2.1 Providing the At-Most-Once functionality
|
||
|
||
Messages, being carried over TCP, are not subject to transport
|
||
losses, but loss of a transaction request or its reply may
|
||
nonetheless be noted in real implementations. In the absence of a
|
||
timely response, commands are repeated. Most commands are not
|
||
idempotent. The state of the MG would become unpredictable if, for
|
||
example, Add commands were executed several times.
|
||
|
||
To guard against such losses, it is recommended that entities follow
|
||
the procedures in D.1.1.
|
||
|
||
D.2.2 Transaction identifiers and three-way handshake
|
||
|
||
For the same reasons, it is possible that transaction replies may be
|
||
lost even with a reliable delivery protocol such as TCP. It is
|
||
recommended that entities follow the procedures in D.1.2.2.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 155]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
D.2.3 Computing retransmission timers
|
||
|
||
With reliable delivery, the incidence of loss of a transaction
|
||
request or reply is expected to be very low. Therefore, only simple
|
||
timer mechanisms are required. Exponential back-off algorithms
|
||
should not be necessary, although they could be employed where, as in
|
||
an MGC, the code to do so is already required, since MGCs must
|
||
implement ALF/UDP as well as TCP.
|
||
|
||
D.2.4 Provisional responses
|
||
|
||
As with UDP, executing some transactions may require a long time.
|
||
Entities that can predict that a transaction will require a long
|
||
execution time may send a provisional response, "Transaction
|
||
Pending". They should send this response if they receive a
|
||
repetition of a transaction that is still being executed.
|
||
|
||
Entities that receive a Transaction Pending shall switch to a longer
|
||
repetition timer for that transaction.
|
||
|
||
Entities shall retain Transactions and replies until they are
|
||
confirmed. The basic procedure of D.1.4 should be followed, but
|
||
simple timer values should be sufficient. There is no need to send
|
||
an immediate confirmation upon receipt of a final response.
|
||
|
||
D.2.5 Ordering of commands
|
||
|
||
TCP provides ordered delivery of transactions. No special procedures
|
||
are required. It should be noted that ALF/UDP allows sending entity
|
||
to modify its behaviour under congestion, and in particular, could
|
||
reorder transactions when congestion is encountered. TCP could not
|
||
achieve the same results.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 156]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ANNEX E - Basic packages
|
||
|
||
This annex contains definitions of some packages for use with
|
||
Recommendation H.248.1.
|
||
|
||
E.1 Generic
|
||
|
||
PackageID: g (0x0001)
|
||
Version: 1
|
||
Extends: None
|
||
|
||
Description:
|
||
Generic package for commonly encountered items.
|
||
|
||
E.1.1 Properties
|
||
|
||
None.
|
||
|
||
E.1.2 Events
|
||
|
||
Cause
|
||
|
||
EventID: cause (0x0001)
|
||
Generic error event
|
||
|
||
EventsDescriptor parameters: None
|
||
|
||
ObservedEvents Descriptor Parameters:
|
||
|
||
General Cause
|
||
ParameterID: Generalcause (0x0001)
|
||
|
||
This parameter groups the failures into six groups, which
|
||
the MGC may act upon.
|
||
|
||
Type: enumeration
|
||
|
||
Possible values:
|
||
"NR" Normal Release (0x0001)
|
||
"UR" Unavailable Resources (0x0002)
|
||
"FT" Failure, Temporary (0x0003)
|
||
"FP" Failure, Permanent (0x0004)
|
||
"IW" Interworking Error (0x0005)
|
||
"UN" Unsupported (0x0006)
|
||
|
||
Failure Cause
|
||
ParameterID: Failurecause (0x0002)
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 157]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Possible values: OCTET STRING
|
||
|
||
Description: The Failure Cause is the value generated by the
|
||
Released equipment, i.e., a released network connection.
|
||
The concerned value is defined in the appropriate bearer
|
||
control protocol.
|
||
|
||
Signal Completion
|
||
|
||
EventID: sc (0x0002)
|
||
|
||
Indicates the termination of a signal for which the
|
||
notifyCompletion parameter was set to enable reporting of a
|
||
completion event. For further procedural description, see 7.1.1,
|
||
7.1.17 and 7.2.7.
|
||
|
||
EventsDescriptor parameters: None
|
||
|
||
ObservedEvents Descriptor parameters:
|
||
|
||
Signal Identity
|
||
ParameterID: SigID (0x0001)
|
||
|
||
This parameter identifies the signal which has terminated.
|
||
For a signal that is contained in a signal list, the signal
|
||
list identity parameter should also be returned indicating
|
||
the appropriate list.
|
||
|
||
Type: Binary: octet (string), Text: string
|
||
|
||
Possible values: a signal which has terminated. A signal
|
||
shall be identified using the pkgdName syntax without
|
||
wildcarding.
|
||
|
||
Termination Method
|
||
ParameterID: Meth (0x0002)
|
||
|
||
Indicates the means by which the signal terminated.
|
||
|
||
Type: enumeration
|
||
|
||
Possible values:
|
||
"TO" (0x0001) Signal timed out or otherwise completed on
|
||
its own
|
||
"EV" (0x0002) Interrupted by event
|
||
"SD" (0x0003) Halted by new Signals descriptor
|
||
"NC" (0x0004) Not completed, other cause
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 158]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Signal List ID
|
||
ParameterID: SLID (0x0003)
|
||
|
||
Indicates to which signal list a signal belongs. The
|
||
SignalList ID is only returned in cases where the signal
|
||
resides in a signal list.
|
||
|
||
Type: integer
|
||
|
||
Possible values: any integer
|
||
|
||
E.1.3 Signals
|
||
|
||
None.
|
||
|
||
E.1.4 Statistics
|
||
|
||
None.
|
||
|
||
E.2 Base Root Package
|
||
|
||
PackageID: root (0x0002)
|
||
Version: 1
|
||
Extends: None
|
||
|
||
Description:
|
||
This package defines Gateway wide properties.
|
||
|
||
E.2.1 Properties
|
||
|
||
MaxNrOfContexts
|
||
PropertyID: maxNumberOfContexts (0x0001)
|
||
|
||
The value of this property gives the maximum number of contexts
|
||
that can exist at any time. The NULL context is not included in
|
||
this number.
|
||
|
||
Type: double
|
||
|
||
Possible values: 1 and up
|
||
|
||
Defined in: TerminationState
|
||
|
||
Characteristics: read only
|
||
|
||
MaxTerminationsPerContext
|
||
PropertyID: maxTerminationsPerContext (0x0002)
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 159]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The maximum number of allowed terminations in a context, see 6.1
|
||
|
||
Type: integer
|
||
|
||
Possible values: any integer
|
||
|
||
Defined in: TerminationState
|
||
|
||
Characteristics: read only
|
||
|
||
normalMGExecutionTime
|
||
PropertyId: normalMGExecutionTime (0x0003)
|
||
|
||
Settable by the MGC to indicate the interval within which the MGC
|
||
expects a response to any transaction from the MG (exclusive of
|
||
network delay)
|
||
|
||
Type: integer
|
||
|
||
Possible values: any integer, represents milliseconds
|
||
|
||
Defined in: TerminationState
|
||
|
||
Characteristics: read / write
|
||
|
||
normalMGCExecutionTime
|
||
PropertyId: normalMGCExecutionTime (0x0004)
|
||
|
||
Settable by the MGC to indicate the interval within which the MG
|
||
should expects a response to any transaction from the MGC
|
||
(exclusive of network delay)
|
||
|
||
Type: integer
|
||
|
||
Possible values: any integer, represents milliseconds
|
||
|
||
Defined in: TerminationState
|
||
|
||
Characteristics: read / write
|
||
|
||
MGProvisionalResponseTimerValue
|
||
PropertyId: MGProvisionalResponseTimerValue (0x0005)
|
||
|
||
Indicates the time within which the MGC should expect a Pending
|
||
Response from the MG if a Transaction cannot be completed.
|
||
|
||
Initially set to normalMGExecutionTime plus network delay, but may
|
||
be lowered.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 160]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Type: Integer
|
||
|
||
Possible Values: any integer, represents milliseconds
|
||
|
||
Defined in: TerminationState
|
||
|
||
Characteristics: read / write
|
||
|
||
MGCProvisionalResponseTimerValue
|
||
PropertyId: MGCProvisionalResponseTimerValue (0x0006)
|
||
|
||
Indicates the time within which the MG should expect a Pending
|
||
Response from the MGC if a Transaction cannot be completed.
|
||
Initially set to normalMGCExecutionTime plus network delay, but
|
||
may be lowered.
|
||
|
||
Type: Integer
|
||
|
||
Possible Values: any integer, represents milliseconds
|
||
|
||
Defined in: TerminationState
|
||
|
||
Characteristics: read / write
|
||
|
||
E.2.2 Events
|
||
|
||
None.
|
||
|
||
E.2.3 Signals
|
||
|
||
None.
|
||
|
||
E.2.4 Statistics
|
||
|
||
None.
|
||
|
||
E.2.5 Procedures
|
||
|
||
None.
|
||
|
||
E.3 Tone Generator Package
|
||
|
||
PackageID: tonegen (0x0003)
|
||
Version: 1
|
||
Extends: None
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 161]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Description:
|
||
|
||
This package defines signals to generate audio tones. This
|
||
package does not specify parameter values. It is intended to be
|
||
extendable. Generally, tones are defined as an individual signal
|
||
with a parameter, ind, representing "interdigit" time delay, and a
|
||
tone id to be used with playtones. A tone id should be kept
|
||
consistent with any tone generation for the same tone. MGs are
|
||
expected to be provisioned with the characteristics of appropriate
|
||
tones for the country in which the MG is located.
|
||
|
||
Designed to be extended only.
|
||
|
||
E.3.1 Properties
|
||
|
||
None.
|
||
|
||
E.3.2 Events
|
||
|
||
None.
|
||
|
||
E.3.3 Signals
|
||
|
||
Play tone
|
||
SignalID: pt (0x0001)
|
||
|
||
Plays audio tone over an audio channel
|
||
|
||
Signal Type: Brief
|
||
|
||
Duration: Provisioned
|
||
|
||
Additional parameters:
|
||
|
||
Tone id list
|
||
ParameterID: tl (0x0001)
|
||
|
||
Type: list of tone ids
|
||
|
||
List of tones to be played in sequence. The list SHALL
|
||
contain one or more tone ids.
|
||
|
||
Inter signal duration
|
||
ParameterID: ind (0x0002)
|
||
|
||
Type: integer
|
||
|
||
Timeout between two consecutive tones in milliseconds
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 162]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
No tone ids are specified in this package. Packages that extend this
|
||
package can add possible values for tone id as well as adding
|
||
individual tone signals.
|
||
|
||
E.3.4 Statistics
|
||
|
||
None.
|
||
|
||
E.3.5 Procedures
|
||
|
||
None.
|
||
|
||
E.4 Tone Detection Package
|
||
|
||
PackageID: tonedet (0x0004)
|
||
Version: 1
|
||
Extends: None
|
||
|
||
This Package defines events for audio tone detection. Tones are
|
||
selected by name (tone id). MGs are expected to be provisioned with
|
||
the characteristics of appropriate tones for the country in which the
|
||
MG is located.
|
||
|
||
Designed to be extended only:
|
||
This package does not specify parameter values. It is intended to
|
||
be extendable.
|
||
|
||
E.4.1 Properties
|
||
|
||
None.
|
||
|
||
E.4.2 Events
|
||
|
||
Start tone detected
|
||
EventID: std, 0x0001
|
||
|
||
Detects the start of a tone. The characteristics of positive tone
|
||
detection are implementation dependent.
|
||
|
||
EventsDescriptor parameters:
|
||
|
||
Tone id list
|
||
ParameterID: tl (0x0001)
|
||
|
||
Type: list of tone ids
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 163]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Possible values: The only tone id defined in this package is
|
||
"wild card" which is "*" in text encoding and 0x0000 in
|
||
binary. Extensions to this package would add possible
|
||
values for tone id. If tl is "wild card", any tone id is
|
||
detected.
|
||
|
||
ObservedEventsDescriptor parameters:
|
||
|
||
Tone id
|
||
ParameterID: tid (0x0003)
|
||
|
||
Type: enumeration
|
||
|
||
Possible values: "wildcard" as defined above is the only
|
||
value defined in this package. Extensions to this package
|
||
would add additional possible values for tone id.
|
||
|
||
End tone detected
|
||
EventID: etd, 0x0002
|
||
|
||
Detects the end of a tone.
|
||
|
||
EventDescriptor parameters:
|
||
|
||
Tone id list
|
||
ParameterID: tl (0x0001)
|
||
|
||
Type: enumeration or list of enumerated types
|
||
|
||
Possible values: No possible values are specified in this
|
||
package. Extensions to this package would add possible
|
||
values for tone id.
|
||
|
||
ObservedEventsDescriptor parameters:
|
||
|
||
Tone id
|
||
ParameterID: tid (0x0003)
|
||
|
||
Type: enumeration
|
||
|
||
Possible values: "wildcard" as defined above is the only
|
||
value defined in this package. Extensions to this
|
||
package would add possible values for tone id.
|
||
|
||
Duration
|
||
ParameterId: dur (0x0002)
|
||
|
||
Type: integer, in milliseconds
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 164]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
|
||
This parameter contains the duration of the tone from
|
||
first detection until it stopped.
|
||
|
||
Long tone detected
|
||
EventID: ltd, 0x0003
|
||
|
||
Detects that a tone has been playing for at least a certain amount
|
||
of time.
|
||
|
||
EventDescriptor parameters:
|
||
|
||
Tone id list
|
||
ParameterID: tl (0x0001)
|
||
|
||
Type: enumeration or list
|
||
|
||
Possible values: "wildcard" as defined above is the only
|
||
value defined in this package. Extensions to this package
|
||
would add possible values for tone id.
|
||
|
||
Duration
|
||
ParameterID: dur (0x0002)
|
||
|
||
Type: integer, duration to test against
|
||
|
||
Possible values: any legal integer, expressed in
|
||
milliseconds
|
||
|
||
ObservedEventsDescriptor parameters:
|
||
|
||
Tone id
|
||
ParameterID: tid (0x0003)
|
||
|
||
Type: Enumeration
|
||
|
||
Possible values: No possible values are specified in this
|
||
package. Extensions to this package would add possible
|
||
values for tone id.
|
||
|
||
E.4.3 Signals
|
||
|
||
None.
|
||
|
||
E.4.4 Statistics
|
||
|
||
None.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 165]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.4.5 Procedures
|
||
|
||
None.
|
||
|
||
E.5 Basic DTMF Generator Package
|
||
|
||
PackageID: dg (0x0005)
|
||
Version: 1
|
||
Extends: tonegen version 1
|
||
|
||
This package defines the basic DTMF tones as signals and extends the
|
||
allowed values of parameter tl of playtone in tonegen.
|
||
|
||
E.5.1 Properties
|
||
|
||
None.
|
||
|
||
E.5.2 Events
|
||
|
||
None.
|
||
|
||
E.5.3 Signals
|
||
|
||
DTMF character 0
|
||
SignalID: d0 (0x0010)
|
||
|
||
Generate DTMF 0 tone. The physical characteristic of DTMF 0 is
|
||
defined in the gateway.
|
||
|
||
Signal Type: Brief
|
||
|
||
Duration: Provisioned
|
||
|
||
Additional parameters:
|
||
|
||
None.
|
||
|
||
Additional values:
|
||
|
||
d0 (0x0010) is defined as a tone id for playtone
|
||
|
||
The other DTMF characters are specified in exactly the same way. A
|
||
table with all signal names and signal IDs is included. Note that
|
||
each DTMF character is defined as both a signal and a tone id, thus
|
||
extending the basic tone generation package. Also note that DTMF
|
||
SignalIds are different from the names used in a digit map.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 166]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Signal name Signal ID/Tone id
|
||
|
||
DTMF character 0 d0 (0x0010)
|
||
DTMF character 1 d1 (0x0011)
|
||
DTMF character 2 d2 (0x0012)
|
||
DTMF character 3 d3 (0x0013)
|
||
DTMF character 4 d4 (0x0014)
|
||
DTMF character 5 d5 (0x0015)
|
||
DTMF character 6 d6 (0x0016)
|
||
DTMF character 7 d7 (0x0017)
|
||
DTMF character 8 d8 (0x0018)
|
||
DTMF character 9 d9 (0x0019)
|
||
DTMF character * ds (0x0020)
|
||
DTMF character # do (0x0021)
|
||
DTMF character A da (0x001a)
|
||
DTMF character B db (0x001b)
|
||
DTMF character C dc (0x001c)
|
||
DTMF character D dd (0x001d)
|
||
|
||
E.5.4 Statistics
|
||
|
||
None.
|
||
|
||
E.5.5 Procedures
|
||
|
||
None.
|
||
|
||
E.6 DTMF detection Package
|
||
|
||
PackageID: dd (0x0006)
|
||
Version: 1
|
||
Extends: tonedet version 1
|
||
|
||
This package defines the basic DTMF tones detection. This Package
|
||
extends the possible values of tone id in the "start tone detected"
|
||
"end tone detected" and "long tone detected" events.
|
||
|
||
Additional tone id values are all tone ids described in package dg
|
||
(basic DTMF generator package).
|
||
|
||
The following table maps DTMF events to digit map symbols as
|
||
described in 7.1.14.
|
||
|
||
DTMF Event Symbol
|
||
|
||
d0 "0"
|
||
d1 "1"
|
||
d2 "2"
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 167]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
d3 "3"
|
||
d4 "4"
|
||
d5 "5"
|
||
d6 "6"
|
||
d7 "7"
|
||
d8 "8"
|
||
d9 "9"
|
||
da "A" or "a"
|
||
db "B" or "b"
|
||
dc "C" or "c"
|
||
dd "D" or "d"
|
||
ds "E" or "e"
|
||
do "F" or "f"
|
||
|
||
E.6.1 Properties
|
||
|
||
None.
|
||
|
||
E.6.2 Events
|
||
|
||
DTMF digits
|
||
|
||
EventIds are defined with the same names as the SignalIds defined
|
||
in the table found in E.5.3.
|
||
|
||
DigitMap Completion Event
|
||
EventID: ce, 0x0004
|
||
|
||
Generated when a digit map completes as described in 7.1.14.
|
||
|
||
EventsDescriptor parameters: None.
|
||
|
||
ObservedEventsDescriptor parameters:
|
||
|
||
DigitString
|
||
ParameterID: ds (0x0001)
|
||
|
||
Type: string of digit map symbols (possibly empty) returned
|
||
as a quotedString
|
||
|
||
Possible values: a sequence of the characters "0" through
|
||
"9", "A" through "F", and the long duration modifier "Z".
|
||
|
||
Description: the portion of the current dial string as
|
||
described in 7.1.14 which matched part or all of an
|
||
alternative event sequence specified in the digit map.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 168]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Termination Method
|
||
ParameterID: Meth (0x0003)
|
||
|
||
Type: enumeration
|
||
|
||
Possible values:
|
||
|
||
"UM" (0x0001) Unambiguous match
|
||
|
||
"PM" (0x0002) Partial match, completion by timer expiry
|
||
or unmatched event
|
||
|
||
"FM" (0x0003) Full match, completion by timer expiry or
|
||
unmatched event
|
||
|
||
Description: indicates the reason for generation of the
|
||
event. See the procedures in 7.1.14.
|
||
|
||
E.6.3 Signals
|
||
|
||
None.
|
||
|
||
E.6.4 Statistics
|
||
|
||
None.
|
||
|
||
E.6.5 Procedures
|
||
|
||
Digit map processing is activated only if an events descriptor is
|
||
activated that contains a digit map completion event as defined in
|
||
Section E.6.2 and that digit map completion event contains an eventDM
|
||
field in the requested actions as defined in Section 7.1.9. Other
|
||
parameters such as KeepActive or embedded events of signals
|
||
descriptors may also be present in the events descriptor and do not
|
||
affect the activation of digit map processing.
|
||
|
||
E.7 Call Progress Tones Generator Package
|
||
|
||
PackageID: cg, 0x0007
|
||
Version: 1
|
||
Extends: tonegen version 1
|
||
|
||
This package defines the basic call progress tones as signals and
|
||
extends the allowed values of the tl parameter of playtone in
|
||
tonegen.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 169]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.7.1 Properties
|
||
|
||
None.
|
||
|
||
E.7.2 Events
|
||
|
||
None.
|
||
|
||
E.7.3 Signals
|
||
|
||
Dial Tone
|
||
SignalID: dt (0x0030)
|
||
|
||
Generate dial tone. The physical characteristic of dial tone is
|
||
available in the gateway.
|
||
|
||
Signal Type: TimeOut
|
||
|
||
Duration: Provisioned
|
||
|
||
Additional parameters:
|
||
|
||
None.
|
||
|
||
Additional values:
|
||
|
||
dt (0x0030) is defined as a tone id for playtone
|
||
|
||
The other tones of this package are defined in exactly the same way.
|
||
A table with all signal names and signal IDs is included. Note that
|
||
each tone is defined as both a signal and a tone id, thus extending
|
||
the basic tone generation package.
|
||
|
||
Signal Name Signal ID/tone id
|
||
|
||
Dial Tone dt (0x0030)
|
||
Ringing Tone rt (0x0031)
|
||
Busy Tone bt (0x0032)
|
||
Congestion Tone ct (0x0033)
|
||
Special Information Tone sit(0x0034)
|
||
Warning Tone wt (0x0035)
|
||
Payphone Recognition Tone prt (0x0036)
|
||
Call Waiting Tone cw (0x0037)
|
||
Caller Waiting Tone cr (0x0038)
|
||
|
||
E.7.4 Statistics
|
||
|
||
None.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 170]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.7.5 Procedures
|
||
|
||
NOTE - The required set of tone ids corresponds to those defined
|
||
in Recommendation E.180/Q.35. See Recommendation E.180/Q.35 for
|
||
definition of the meanings of these tones.
|
||
|
||
|
||
E.8 Call Progress Tones Detection Package
|
||
|
||
PackageID: cd (0x0008)
|
||
Version: 1
|
||
Extends: tonedet version 1
|
||
|
||
This package defines the basic call progress detection tones. This
|
||
package extends the possible values of tone id in the "start tone
|
||
detected", "end tone detected" and "long tone detected" events.
|
||
|
||
Additional values
|
||
|
||
toneID values are defined for start tone detected, end tone
|
||
detected and long tone detected with the same values as those in
|
||
package cg (call progress tones generation package).
|
||
|
||
The required set of tone ids corresponds to Recommendation
|
||
E.180/Q.35. See Recommendation E.180/Q.35 for definition of the
|
||
meanings of these tones.
|
||
|
||
E.8.1 Properties
|
||
|
||
None.
|
||
|
||
E.8.2 Events
|
||
|
||
Events are defined as in the call progress tones generator package
|
||
(cg) for the tones listed in the table of E.7.3.
|
||
|
||
E.8.3 Signals
|
||
|
||
None.
|
||
|
||
E.8.4 Statistics
|
||
|
||
None.
|
||
|
||
E.8.5 Procedures
|
||
|
||
None.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 171]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.9 Analog Line Supervision Package
|
||
|
||
PackageID: al, 0x0009
|
||
Version: 1
|
||
Extends: None
|
||
|
||
This package defines events and signals for an analog line.
|
||
|
||
E.9.1 Properties
|
||
|
||
None.
|
||
|
||
E.9.2 Events
|
||
|
||
onhook
|
||
EventID: on (0x0004)
|
||
|
||
Detects handset going on hook. Whenever an events descriptor is
|
||
activated that requests monitoring for an on-hook event and the
|
||
line is already on-hook, then the MG shall behave according to the
|
||
setting of the "strict" parameter.
|
||
|
||
EventDescriptor parameters:
|
||
|
||
Strict Transition
|
||
ParameterID: strict (0x0001)
|
||
|
||
Type: enumeration
|
||
|
||
Possible values: "exact" (0x00), "state" (0x01), "failWrong"
|
||
(0x02)
|
||
|
||
"exact" means that only an actual hook state transition to
|
||
on-hook is to be recognized;
|
||
|
||
"state" means that the event is to be recognized either if
|
||
the hook state transition is detected or if the hook state
|
||
is already on-hook;
|
||
|
||
"failWrong" means that if the hook state is already
|
||
on-hook, the command fails and an error is reported.
|
||
|
||
ObservedEventsDescriptor parameters:
|
||
|
||
Initial State
|
||
ParameterID: init (0x0002)
|
||
|
||
Type: Boolean
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 172]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Possible values:
|
||
|
||
"True" means that the event was reported because the line
|
||
was already on-hook when the events descriptor containing
|
||
this event was activated;
|
||
|
||
"False" means that the event represents an actual state
|
||
transition to on-hook.
|
||
|
||
offhook
|
||
EventID: of (0x0005)
|
||
|
||
Detects handset going off hook. Whenever an events descriptor is
|
||
activated that requests monitoring for an off-hook event and the
|
||
line is already off-hook, then the MG shall behave according to
|
||
the setting of the "strict" parameter.
|
||
|
||
EventDescriptor parameters:
|
||
|
||
Strict Transition
|
||
ParameterID: strict (0x0001)
|
||
|
||
Type: enumeration
|
||
|
||
Possible values: "exact" (0x00), "state" (0x01), "failWrong"
|
||
(0x02)
|
||
|
||
"exact" means that only an actual hook state transition
|
||
to off-hook is to be recognized;
|
||
|
||
"state" means that the event is to be recognized either
|
||
if the hook state transition is detected or if the hook
|
||
state is already off-hook;
|
||
|
||
"failWrong" means that if the hook state is already off-
|
||
hook, the command fails and an error is reported.
|
||
|
||
ObservedEventsDescriptor parameters
|
||
|
||
Initial State
|
||
ParameterID: init (0x0002)
|
||
|
||
Type: Boolean
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 173]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Possible values:
|
||
|
||
"True" means that the event was reported because the line
|
||
was already off-hook when the events descriptor
|
||
containing this event was activated;
|
||
|
||
"False" means that the event represents an actual state
|
||
transition to off-hook.
|
||
|
||
flashhook
|
||
EventID: fl, 0x0006
|
||
|
||
Detects handset flash. A flash occurs when an onhook is followed
|
||
by an offhook between a minimum and maximum duration.
|
||
|
||
EventDescriptor parameters:
|
||
|
||
Minimum duration
|
||
ParameterID: mindur (0x0004)
|
||
|
||
Type: integer in milliseconds
|
||
|
||
Default value is provisioned.
|
||
|
||
Maximum duration
|
||
ParameterID: maxdur (0x0005)
|
||
|
||
Type: integer in milliseconds
|
||
|
||
Default value is provisioned.
|
||
|
||
ObservedEventsDescriptor parameters:
|
||
|
||
None
|
||
|
||
E.9.3 Signals
|
||
|
||
ring
|
||
SignalID: ri, 0x0002
|
||
|
||
Applies ringing on the line
|
||
|
||
Signal Type: TimeOut
|
||
|
||
Duration: Provisioned
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 174]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Additional parameters:
|
||
|
||
Cadence
|
||
ParameterID: cad (0x0006)
|
||
|
||
Type: list of integers representing durations of alternating
|
||
on and off segments, constituting a complete ringing cycle
|
||
starting with an on. Units in milliseconds
|
||
|
||
Default is fixed or provisioned. Restricted function MGs
|
||
may ignore cadence values they are incapable of generating.
|
||
|
||
Frequency
|
||
ParameterID: freq (0x0007)
|
||
|
||
Type: integer in Hz
|
||
|
||
Default is fixed or provisioned. Restricted function MGs
|
||
may ignore frequency values they are incapable of
|
||
generating.
|
||
|
||
E.9.4 Statistics
|
||
|
||
None.
|
||
|
||
E.9.5 Procedures
|
||
|
||
If the MGC sets an EventsDescriptor containing a hook state
|
||
transition event (on-hook or off-hook) with the "strict" (0x0001)
|
||
parameter set to "failWrong", and the hook state is already what the
|
||
transition implies, the execution of the command containing that
|
||
EventsDescriptor fails. The MG SHALL include error code 540
|
||
"Unexpected initial hook state" in its reponse.
|
||
|
||
E.9.6 Error code
|
||
|
||
This package defines a new error code:
|
||
|
||
540 - Unexpected initial hook state
|
||
|
||
The procedure for use of this code is given in E.9.5.
|
||
|
||
E.10 Basic Continuity Package
|
||
|
||
PackageID: ct (0x000a)
|
||
Version: 1
|
||
Extends: None
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 175]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
This package defines events and signals for continuity test. The
|
||
continuity test includes provision of either a loopback or
|
||
transceiver functionality.
|
||
|
||
E.10.1 Properties
|
||
|
||
None.
|
||
|
||
E.10.2 Events
|
||
|
||
Completion
|
||
EventID: cmp, 0x0005
|
||
|
||
This event detects test completion of continuity test.
|
||
|
||
EventDescriptor parameters
|
||
|
||
None.
|
||
|
||
ObservedEventsDescriptor parameters
|
||
|
||
Result
|
||
ParameterID: res (0x0008)
|
||
|
||
Type: enumeration
|
||
|
||
Possible values: success (0x0001), failure (0x0000)
|
||
|
||
E.10.3 Signals
|
||
|
||
Continuity test
|
||
SignalID: ct (0x0003)
|
||
|
||
Initiates sending of continuity test tone on the termination to
|
||
which it is applied.
|
||
|
||
Signal Type: TimeOut
|
||
|
||
Default value is provisioned
|
||
|
||
Additional parameters:
|
||
|
||
None.
|
||
|
||
Respond
|
||
SignalID: rsp (0x0004)
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 176]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The signal is used to respond to a continuity test. See E.10.5
|
||
for further explanation.
|
||
|
||
Signal Type: On/Off
|
||
|
||
Default duration is provisioned
|
||
|
||
Additional parameters:
|
||
|
||
None.
|
||
|
||
E.10.4 Statistics
|
||
|
||
None.
|
||
|
||
E.10.5 Procedures
|
||
|
||
When a MGC wants to initiate a continuity test, it sends a command to
|
||
the MG containing:
|
||
|
||
- a signals descriptor with the ct signal; and
|
||
|
||
- an events descriptor containing the cmp event.
|
||
|
||
Upon reception of a command containing the ct signal and cmp event,
|
||
the MG initiates the continuity test tone for the specified
|
||
Termination. If the return tone is detected and any other required
|
||
conditions are satisfied before the signal times out, the cmp event
|
||
shall be generated with the value of the result parameter equal to
|
||
success. In all other cases, the cmp event shall be generated with
|
||
the value of the result parameter equal to failure.
|
||
|
||
When a MGC wants the MG to respond to a continuity test, it sends a
|
||
command to the MG containing a signals descriptor with the rsp
|
||
signal. Upon reception of a command with the rsp signal, the MG
|
||
either applies a loopback or (for 2-wire circuits) awaits reception
|
||
of a continuity test tone. In the loopback case, any incoming
|
||
information shall be reflected back as outgoing information. In the
|
||
2-wire case, any time the appropriate test tone is received, the
|
||
appropriate response tone should be sent. The MGC determines when to
|
||
remove the rsp signal.
|
||
|
||
When a continuity test is performed on a Termination, no echo devices
|
||
or codecs shall be active on that Termination.
|
||
|
||
Performing voice path assurance as part of continuity testing is
|
||
provisioned by bilateral agreement between network operators.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 177]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
(Informative Note) Example tones and test procedure details are
|
||
given in Q.724 sections 7 and 8, Q.764 section 2.1.8 and Q.1902.4.
|
||
|
||
E.11 Network Package
|
||
|
||
PackageID: nt (0x000b)
|
||
Version: 1
|
||
Extends: None
|
||
|
||
This package defines properties of network terminations independent
|
||
of network type.
|
||
|
||
E.11.1 Properties
|
||
|
||
Maximum Jitter Buffer
|
||
PropertyID: jit (0x0007)
|
||
|
||
This property puts a maximum size on the jitter buffer.
|
||
|
||
Type: integer in milliseconds
|
||
|
||
Possible values: This property is specified in milliseconds.
|
||
|
||
Defined in: LocalControlDescriptor
|
||
|
||
Characteristics: read/write
|
||
|
||
E.11.2 Events
|
||
|
||
network failure
|
||
EventID: netfail, 0x0005
|
||
|
||
The termination generates this event upon detection of a failure
|
||
due to external or internal network reasons.
|
||
|
||
EventDescriptor parameters
|
||
|
||
None.
|
||
|
||
ObservedEventsDescriptor parameters
|
||
|
||
cause
|
||
ParameterID: cs (0x0001)
|
||
|
||
Type: string
|
||
|
||
Possible values: any text string
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 178]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
This parameter may be included with the failure event to
|
||
provide diagnostic information on the reason of failure.
|
||
|
||
quality alert
|
||
EventID: qualert, 0x0006
|
||
|
||
This property allows the MG to indicate a loss of quality of the
|
||
network connection. The MG may do this by measuring packet loss,
|
||
interarrival jitter, propagation delay and then indicating this
|
||
using a percentage of quality loss.
|
||
|
||
EventDescriptor parameters
|
||
|
||
Threshold
|
||
ParameterId: th (0x0001)
|
||
|
||
Type: integer
|
||
|
||
Possible values: 0 to 99
|
||
|
||
Description: threshold for percent of quality loss measured,
|
||
calculated based on a provisioned method, that could take
|
||
into consideration packet loss, jitter, and delay for
|
||
example. Event is triggered when calculation exceeds the
|
||
threshold.
|
||
|
||
ObservedEventsDescriptor parameters
|
||
|
||
Threshold
|
||
ParameterId: th (0x0001)
|
||
|
||
Type: integer
|
||
|
||
Possible values: 0 to 99
|
||
|
||
Description: percent of quality loss measured, calculated
|
||
based on a provisioned method, that could take into
|
||
consideration packet loss, jitter, and delay for example.
|
||
|
||
E.11.3 Signals
|
||
|
||
None.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 179]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.11.4 Statistics
|
||
|
||
Duration
|
||
StatisticsID: dur (0x0001)
|
||
|
||
Description: provides duration of time the termination has been in
|
||
the Context.
|
||
|
||
Type: double, in milliseconds
|
||
|
||
Octets Sent
|
||
StatisticID: os (0x0002)
|
||
|
||
Type: double
|
||
|
||
Possible values: any 64-bit integer
|
||
|
||
Octets Received
|
||
StatisticID: or (0x0003)
|
||
|
||
Type: double
|
||
|
||
Possible values: any 64-bit integer
|
||
|
||
E.11.5 Procedures
|
||
|
||
None.
|
||
|
||
E.12 RTP Package
|
||
|
||
PackageID: rtp (0x000c)
|
||
Version: 1
|
||
Extends: Network Package version 1
|
||
|
||
This package is used to support packet-based multimedia data transfer
|
||
by means of the Real-time Transport Protocol (RTP) [RFC 1889].
|
||
|
||
E.12.1 Properties
|
||
|
||
None.
|
||
|
||
E.12.2 Events
|
||
|
||
Payload Transition
|
||
EventID: pltrans, 0x0001
|
||
|
||
This event detects and notifies when there is a transition of the
|
||
RTP payload format from one format to another.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 180]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
EventDescriptor parameters
|
||
|
||
None.
|
||
|
||
ObservedEventsDescriptor parameters
|
||
|
||
ParameterName: rtppayload
|
||
ParameterID: rtppltype, 0x01
|
||
|
||
Type: list of enumerated types.
|
||
|
||
Possible values: The encoding method shall be specified by
|
||
using one or several valid encoding names, as defined in the
|
||
RTP AV Profile or registered with IANA.
|
||
|
||
E.12.3 Signals
|
||
|
||
None.
|
||
|
||
E.12.4 Statistics
|
||
|
||
Packets Sent
|
||
StatisticID: ps (0x0004)
|
||
|
||
Type: double
|
||
|
||
Possible values: any 64-bit integer
|
||
|
||
Packets Received
|
||
StatisticID: pr (0x0005)
|
||
|
||
Type: double
|
||
|
||
Possible values: any 64-bit integer
|
||
|
||
Packet Loss
|
||
StatisticID: pl (0x0006)
|
||
|
||
Describes the current rate of packet loss on an RTP stream, as
|
||
defined in IETF RFC 1889. Packet loss is expressed as percentage
|
||
value: number of packets lost in the interval between two
|
||
reception reports, divided by the number of packets expected
|
||
during that interval.
|
||
|
||
Type: double
|
||
|
||
Possible values: a 32-bit whole number and a 32-bit fraction.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 181]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Jitter
|
||
StatisticID: jit (0x0007)
|
||
|
||
Requests the current value of the interarrival jitter on an RTP
|
||
stream as defined in IETF RFC 1889. Jitter measures the variation
|
||
in interarrival time for RTP data packets.
|
||
|
||
Delay
|
||
StatisticID:delay (0x0008)
|
||
|
||
Requests the current value of packet propagation delay expressed
|
||
in timestamp units. Same as average latency.
|
||
|
||
E.12.5 Procedures
|
||
|
||
None.
|
||
|
||
E.13 TDM Circuit Package
|
||
|
||
PackageID: tdmc (0x000d)
|
||
Version: 1
|
||
Extends: Network Package version 1
|
||
|
||
This package may be used by any termination that supports gain and
|
||
echo control. It was originally intended for use on TDM circuits
|
||
but may be more widely used.
|
||
|
||
|
||
New versions or extensions of this package should take non-TDM use
|
||
into account.
|
||
|
||
E.13.1 Properties
|
||
|
||
Echo Cancellation
|
||
PropertyID: ec (0x0008)
|
||
|
||
Type: boolean
|
||
|
||
Possible values:
|
||
|
||
"on" (when the echo cancellation is requested) and
|
||
|
||
"off" (when it is turned off.)
|
||
|
||
The default is provisioned.
|
||
|
||
Defined in: LocalControlDescriptor
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 182]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Characteristics: read/write
|
||
|
||
Gain Control
|
||
PropertyID: gain (0x000a)
|
||
|
||
Gain control, or usage of of signal level adaptation and
|
||
noise level reduction is used to adapt the level of the signal.
|
||
However, it is necessary, for example for modem calls, to turn
|
||
off this function.
|
||
|
||
Type: integer
|
||
|
||
Possible values:
|
||
|
||
The gain control parameter may either be specified as
|
||
"automatic" (0xffffffff), or as an explicit number of decibels
|
||
of gain (any other integer value). The default is provisioned
|
||
in the MG.
|
||
|
||
Defined in: LocalControlDescriptor
|
||
|
||
Characteristics: read/write
|
||
|
||
E.13.2 Events
|
||
|
||
None.
|
||
|
||
E.13.3 Signals
|
||
|
||
None.
|
||
|
||
E.13.4 Statistics
|
||
|
||
None.
|
||
|
||
E.13.5 Procedures
|
||
|
||
None.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 183]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
APPENDIX I EXAMPLE CALL FLOWS (INFORMATIVE)
|
||
|
||
All H.248.1 implementors must read the normative part of this RFC
|
||
carefully before implementing from it. The examples in this appendix
|
||
should not be used as stand-alone explanations of how to create
|
||
protocol messages.
|
||
|
||
The examples in this appendix use SDP for encoding of the Local and
|
||
and Remote stream descriptors. SDP is defined in RFC 2327. If there
|
||
is is any discrepancy between the SDP in the examples, and RFC 2327,
|
||
the the RFC should be consulted for correctness. Audio profiles used
|
||
are are those defined in IETF RFC 1890, and others registered with
|
||
IANA. For example, G.711 A-law is called PCMA in SDP, and is
|
||
assigned profile 0. G.723.1 is called G723 and is profile 4; H.263 is
|
||
called H263 and is profile 34. See also
|
||
http://www.iana.org/assignments/rtp-parameters.
|
||
|
||
A.1 Residential Gateway to Residential Gateway Call
|
||
|
||
This example scenario illustrates the use of the elements of the
|
||
protocol to set up a Residential Gateway to Residential Gateway call
|
||
over an IP-based network. For simplicity, this example assumes that
|
||
both Residential Gateways involved in the call are controlled by the
|
||
same Media Gateway Controller.
|
||
|
||
A.1.1 Programming Residential GW Analog Line Terminations for Idle
|
||
Behavior
|
||
|
||
The following illustrates the API invocations from the Media Gateway
|
||
Controller and Media Gateways to get the Terminations in this
|
||
scenario programmed for idle behavior. Both the originating and
|
||
terminating Media Gateways have idle AnalogLine Terminations
|
||
programmed to look for call initiation events (i.e., -offhook) by
|
||
using the Modify Command with the appropriate parameters. The null
|
||
Context is used to indicate that the Terminations are not yet
|
||
involved in a Context. The ROOT termination is used to indicate the
|
||
entire MG instead of a termination within the MG.
|
||
|
||
In this example, MG1 has the IP address 124.124.124.222, MG2 is
|
||
125.125.125.111, and the MGC is 123.123.123.4. The default Megaco
|
||
port is 55555 for all three.
|
||
|
||
1. An MG registers with an MGC using the ServiceChange command:
|
||
|
||
MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222] Transaction = 9998 {
|
||
Context = - {
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 184]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
ServiceChange = ROOT {Services {
|
||
Method=Restart,
|
||
ServiceChangeAddress=55555, Profile=ResGW/1}
|
||
}
|
||
} }
|
||
|
||
2. The MGC sends a reply:
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Reply = 9998 {
|
||
Context = - {ServiceChange = ROOT {
|
||
Services {ServiceChangeAddress=55555, Profile=ResGW/1} } } }
|
||
|
||
3. The MGC programs a Termination in the NULL context. The
|
||
terminationId is A4444, the streamId is 1, the requestId in the
|
||
Events descriptor is 2222. The mId is the identifier of the sender
|
||
of this message, in this case, it is the IP address and port
|
||
[123.123.123.4]:55555. Mode for this stream is set to SendReceive.
|
||
"al" is the analog line supervision package. Local and Remote are
|
||
assumed to be provisioned.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 {
|
||
Context = - {
|
||
Modify = A4444 {
|
||
Media { Stream = 1 {
|
||
LocalControl {
|
||
Mode = SendReceive,
|
||
tdmc/gain=2, ; in dB,
|
||
tdmc/ec=on
|
||
},
|
||
|
||
}
|
||
},
|
||
Events = 2222 {al/of(strict=state)}
|
||
}
|
||
} }
|
||
|
||
|
||
The dialplan script could have been loaded into the MG previously.
|
||
Its function would be to wait for the OffHook, turn on dialtone and
|
||
start collecting DTMF digits. However in this example, we use the
|
||
digit map, which is put into place after the offhook is detected
|
||
(step 5 below).
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 185]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Note that the embedded EventsDescriptor could have been used to
|
||
combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
|
||
|
||
4. The MG1 accepts the Modify with this reply:
|
||
|
||
MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555
|
||
|
||
Reply = 9999 {
|
||
Context = - {Modify = A4444} }
|
||
|
||
5. A similar exchange happens between MG2 and the MGC, resulting in
|
||
an idle Termination called A5555.
|
||
|
||
A.1.2 Collecting Originator Digits and Initiating Termination
|
||
|
||
The following builds upon the previously shown conditions. It
|
||
illustrates the transactions from the Media Gateway Controller and
|
||
originating Media Gateway (MG1) to get the originating Termination
|
||
(A4444) through the stages of digit collection required to initiate a
|
||
connection to the terminating Media Gateway (MG2).
|
||
|
||
6. MG1 detects an offhook event from User 1 and reports it to the
|
||
Media Gateway Controller via the Notify Command.
|
||
|
||
MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555 Transaction = 10000 {
|
||
Context = - {
|
||
Notify = A4444 {ObservedEvents =2222 {
|
||
19990729T22000000:al/of(init=false)}}
|
||
} }
|
||
|
||
7. And the Notify is acknowledged.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Reply = 10000 {
|
||
|
||
Context = - {Notify = A4444} }
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 186]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
8. The MGC Modifies the termination to play dial tone, to look for
|
||
digits according to Dialplan0 and to look for the on-hook event now.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 10001 {
|
||
Context = - {
|
||
Modify = A4444 {
|
||
Events = 2223 {
|
||
al/on(strict=state), dd/ce {DigitMap=Dialplan0}
|
||
},
|
||
Signals {cg/dt},
|
||
DigitMap= Dialplan0{ (0| 00|[1-
|
||
7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
|
||
}
|
||
} }
|
||
|
||
9. And the Modify is acknowledged.
|
||
|
||
MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555 Reply = 10001 {
|
||
Context = - {Modify = A4444} }
|
||
|
||
10. Next, digits are accumulated by MG1 as they are dialed by User
|
||
1. Dialtone is stopped upon detection of the first digit. When an
|
||
appropriate match is made of collected digits against the currently
|
||
programmed Dialplan for A4444, another Notify is sent to the Media
|
||
Gateway Controller.
|
||
|
||
MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555 Transaction = 10002 {
|
||
Context = - {
|
||
Notify = A4444 {ObservedEvents =2223 {
|
||
19990729T22010001:dd/ce{ds="916135551212",Meth=UM}}}
|
||
} }
|
||
|
||
11. And the Notify is acknowledged.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Reply = 10002 {
|
||
Context = - {Notify = A4444} }
|
||
|
||
|
||
12. The controller then analyses the digits and determines that a
|
||
connection needs to be made from MG1 to MG2. Both the TDM
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 187]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
termination A4444, and an RTP termination are added to a new context
|
||
in MG1. Mode is ReceiveOnly since Remote descriptor values are not
|
||
yet specified. Preferred codecs are in the MGC's preferred order of
|
||
choice.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 {
|
||
Context = $ {
|
||
Add = A4444,
|
||
Add = $ {
|
||
Media {
|
||
Stream = 1 {
|
||
LocalControl {
|
||
Mode = ReceiveOnly,
|
||
|
||
nt/jit=40 ; in ms
|
||
},
|
||
Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4
|
||
a=ptime:30 v=0 c=IN IP4 $ m=audio $ RTP/AVP 0
|
||
}
|
||
}
|
||
}
|
||
}
|
||
} }
|
||
|
||
|
||
NOTE - The MGC states its preferred parameter values as a series
|
||
of SDP blocks in Local. The MG fills in the Local Descriptor in
|
||
the Reply.
|
||
|
||
13. MG1 acknowledges the new Termination and fills in the Local IP
|
||
address and UDP port. It also makes a choice for the codec based on
|
||
the MGC preferences in Local. MG1 sets the RTP port to 2222.
|
||
|
||
MG1 -> MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555 Reply = 10003 {
|
||
Context = 2000 {
|
||
Add = A4444,
|
||
Add=A4445{
|
||
Media {
|
||
Stream = 1 {
|
||
Local { v=0 o=- 2890844526 2890842807 IN IP4
|
||
124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
|
||
RTP/AVP 4 a=ptime:30 a=recvonly
|
||
} ; RTP profile for G.723.1 is 4
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 188]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
}
|
||
}
|
||
} }
|
||
|
||
14. The MGC will now associate A5555 with a new Context on MG2, and
|
||
establish an RTP Stream (i.e., A5556 will be assigned), SendReceive
|
||
connection through to the originating user, User 1. The MGC also
|
||
sets ring on A5555.
|
||
|
||
MGC to MG2:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 50003 {
|
||
Context = $ {
|
||
Add = A5555 { Media {
|
||
Stream = 1 {
|
||
LocalControl {Mode = SendReceive} }},
|
||
Events=1234{al/of(strict=state)},
|
||
Signals {al/ri}
|
||
|
||
},
|
||
Add = $ {Media {
|
||
Stream = 1 {
|
||
LocalControl {
|
||
Mode = SendReceive,
|
||
nt/jit=40 ; in ms
|
||
},
|
||
Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4
|
||
a=ptime:30
|
||
},
|
||
Remote { v=0 c=IN IP4 124.124.124.222 m=audio 2222
|
||
RTP/AVP 4 a=ptime:30
|
||
} ; RTP profile for G.723.1 is 4
|
||
}
|
||
}
|
||
}
|
||
} }
|
||
|
||
15. This is acknowledged. The stream port number is different from
|
||
the control port number. In this case it is 1111 (in the SDP).
|
||
|
||
MG2 to MGC:
|
||
|
||
MEGACO/1 [125.125.125.111]:55555 Reply = 50003 {
|
||
Context = 5000 {
|
||
Add = A5555,
|
||
Add = A5556{
|
||
Media {
|
||
Stream = 1 {
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 189]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Local { v=0 o=- 7736844526 7736842807 IN IP4
|
||
125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
|
||
RTP/AVP 4 }
|
||
} ; RTP profile for G723.1 is 4
|
||
}
|
||
}
|
||
|
||
} }
|
||
|
||
16. The above IPAddr and UDPport need to be given to MG1 now.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 10005 {
|
||
Context = 2000 {
|
||
Modify = A4444 {
|
||
Signals {cg/rt}
|
||
},
|
||
Modify = A4445 {
|
||
Media {
|
||
Stream = 1 {
|
||
Remote { v=0 o=- 7736844526 7736842807 IN IP4
|
||
125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
|
||
RTP/AVP 4
|
||
}
|
||
} ; RTP profile for G723.1 is 4
|
||
}
|
||
}
|
||
} }
|
||
|
||
|
||
MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555 Reply = 10005 {
|
||
Context = 2000 {Modify = A4444, Modify = A4445} }
|
||
|
||
17. The two gateways are now connected and User 1 hears the
|
||
RingBack. The MG2 now waits until User2 picks up the receiver and
|
||
then the two-way call is established.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 190]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
From MG2 to MGC:
|
||
|
||
MEGACO/1 [125.125.125.111]:55555 Transaction = 50005 {
|
||
Context = 5000 {
|
||
|
||
Notify = A5555 {ObservedEvents =1234 {
|
||
19990729T22020002:al/of(init=false)}}
|
||
} }
|
||
|
||
From MGC to MG2:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Reply = 50005 {
|
||
Context = - {Notify = A5555} }
|
||
|
||
From MGC to MG2:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 50006 {
|
||
Context = 5000 {
|
||
Modify = A5555 {
|
||
Events = 1235 {al/on(strict=state)},
|
||
Signals { } ; to turn off ringing
|
||
}
|
||
} }
|
||
|
||
From MG2 to MGC:
|
||
|
||
MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {
|
||
Context = 5000 {Modify = A4445} }
|
||
|
||
18. Change mode on MG1 to SendReceive, and stop the ringback.
|
||
|
||
MGC to MG1:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 10006 {
|
||
Context = 2000 {
|
||
Modify = A4445 {
|
||
Media {
|
||
Stream = 1 {
|
||
LocalControl {
|
||
Mode=SendReceive
|
||
|
||
}
|
||
}
|
||
}
|
||
},
|
||
Modify = A4444 {
|
||
Signals { }
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 191]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
} }
|
||
|
||
from MG1 to MGC:
|
||
|
||
MEGACO/1 [124.124.124.222]:55555 Reply = 10006 {
|
||
Context = 2000 {Modify = A4445, Modify = A4444}}
|
||
|
||
19. The MGC decides to Audit the RTP termination on MG2.
|
||
|
||
MGC -> MG2:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 50007 {
|
||
Context = - {AuditValue = A5556{
|
||
Audit{Media, DigitMap, Events, Signals, Packages, Statistics }}
|
||
} }
|
||
|
||
20. The MG2 replies.
|
||
|
||
MG2 -> MGC:
|
||
|
||
MEGACO/1 [125.125.125.111]:55555 Reply = 50007 {
|
||
Context = - { AuditValue = A5556 {
|
||
Media {
|
||
TerminationState { ServiceStates = InService,
|
||
Buffer = OFF },
|
||
Stream = 1 {
|
||
LocalControl { Mode = SendReceive,
|
||
nt/jit=40 },
|
||
Local { v=0 o=- 7736844526 7736842807 IN IP4
|
||
125.125.125.111 s=- t= 0 0 c=IN IP4 125.125.125.111 m=audio 1111
|
||
RTP/AVP 4 a=ptime:30
|
||
},
|
||
Remote { v=0 o=- 2890844526 2890842807 IN IP4
|
||
124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222
|
||
RTP/AVP 4 a=ptime:30
|
||
} } },
|
||
Events,
|
||
Signals,
|
||
DigitMap,
|
||
Packages {nt-1, rtp-1},
|
||
Statistics { rtp/ps=1200, ; packets sent
|
||
nt/os=62300, ; octets sent
|
||
rtp/pr=700, ; packets received
|
||
nt/or=45100, ; octets received
|
||
rtp/pl=0.2, ; % packet loss
|
||
rtp/jit=20,
|
||
rtp/delay=40 } ; avg latency
|
||
}
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 192]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
} }
|
||
|
||
21. When the MGC receives an onhook signal from one of the MGs, it
|
||
brings down the call. In this example, the user at MG2 hangs up
|
||
first.
|
||
|
||
From MG2 to MGC:
|
||
|
||
MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 {
|
||
Context = 5000 {
|
||
Notify = A5555 {ObservedEvents =1235 {
|
||
19990729T24020002:al/on(init=false)}
|
||
}
|
||
} }
|
||
|
||
From MGC to MG2:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Reply = 50008 {
|
||
|
||
Context = - {Notify = A5555} }
|
||
|
||
22. The MGC now sends both MGs a Subtract to take down the call.
|
||
Only the subtracts to MG2 are shown here. Each termination has its
|
||
own set of statistics that it gathers. An MGC may not need to
|
||
request both to be returned. A5555 is a physical termination, and
|
||
A5556 is an RTP termination.
|
||
|
||
From MGC to MG2:
|
||
|
||
MEGACO/1 [123.123.123.4]:55555 Transaction = 50009 {
|
||
Context = 5000 {
|
||
Subtract = A5555 {Audit{Statistics}},
|
||
Subtract = A5556 {Audit{Statistics}}
|
||
} }
|
||
|
||
From MG2 to MGC:
|
||
|
||
MEGACO/1 [125.125.125.111]:55555 Reply = 50009 {
|
||
Context = 5000 {
|
||
Subtract = A5555 {
|
||
Statistics {
|
||
nt/os=45123, ; Octets Sent
|
||
nt/dur=40 ; in seconds
|
||
}
|
||
},
|
||
Subtract = A5556 {
|
||
Statistics {
|
||
rtp/ps=1245, ; packets sent
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 193]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
nt/os=62345, ; octets sent
|
||
rtp/pr=780, ; packets received
|
||
nt/or=45123, ; octets received
|
||
rtp/pl=10, ; % packets lost
|
||
rtp/jit=27,
|
||
rtp/delay=48 ; average latency
|
||
}
|
||
}
|
||
} }
|
||
|
||
23. The MGC now sets up both MG1 and MG2 to be ready to detect the
|
||
next off-hook event. See step 1. Note that this could be the
|
||
default state of a termination in the null context, and if this were
|
||
the case, no message need be sent from the MGC to the MG. Once a
|
||
termination returns to the null context, it goes back to the default
|
||
termination values for that termination.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 194]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
APPENDIX II Changes From RFC 3015
|
||
|
||
In the following table, "source" indicates when the change was first
|
||
approved. It has the following values:
|
||
|
||
IG1100: H.248 Implementor's Guide approved in November, 2000 (as TD
|
||
Plen-39, Christian Groves, editor).
|
||
|
||
IG0601: H.248 Implementor's Guide approved in June, 2001 (as TD
|
||
Plen-15, Christian Groves, editor).
|
||
|
||
IGDUB: Draft H.248 Implementor's Guide approved at the Q.3
|
||
Rapporteur's meeting held near Dublin, October 2001 (as TD-28, Terry
|
||
Anderson, editor).
|
||
|
||
GEN0202: added at the Geneva meeting, February 2002, which consented
|
||
to H.248 v1 Amendment 1 (as TD Plen-36r1, Marcello Pantaleo, editor).
|
||
|
||
ITUPOST: added in post-Geneva editing by the ITU-T.
|
||
|
||
TTPOST: added in post-approval editing by the Megaco Chair, Tom
|
||
Taylor, who assembled this document for submission.
|
||
|
||
Section Source Change
|
||
|
||
1 ITUPOST Reference changed from H.248 to H.248.1.
|
||
|
||
2.1 ITUPOST Reference added for error codes, changed from
|
||
H.248 Annex L to H.248.8 (2002).
|
||
|
||
2.1 IG1100 Corrected Q.765 reference to Q.765.5.
|
||
|
||
2.1 GEN0202 Added reference to X.690.
|
||
|
||
2.2 GEN0202 Added reference to H.226.
|
||
|
||
2.2 IGDUB Added informative references to Q.724, Q.764,
|
||
and Q.1902.4.
|
||
|
||
4 IG0601 Added expansion of ALF.
|
||
|
||
5 TTPOST Gave priority to IETF conventions (added at
|
||
start of document).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 195]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
6.1.1 IG0601 Added text regarding use of wildcards for
|
||
context identifiers. (This information
|
||
already appeared in section 8.1.2. The IG
|
||
change subsequently disappeared.)
|
||
|
||
6.1.1 IG1100 Added ranking of priority values.
|
||
|
||
6.2 IGDUB Deleted definition of signals.
|
||
|
||
6.2 GEN0202 Expanded text and diagrams describing
|
||
multiplexing terminations.
|
||
|
||
6.2 TTPOST Added asterisks to multiplexing diagrams to
|
||
indicate centre of context. Added Figure 6a
|
||
showing cascading of multiplexes.
|
||
|
||
6.2.2 IG0601 Added text indicating that ALL does not
|
||
include ROOT.
|
||
|
||
6.2.3 IG1100 Added text clarifying what must be supported
|
||
to claim support of a package.
|
||
|
||
6.2.3 IG1100 Added text indicating what packages a peer can
|
||
indicate support for, when some of them are
|
||
extensions of others.
|
||
|
||
6.2.4 IG0601 Added text on ability of provisioning to
|
||
override default values, and need for MGC to
|
||
audit to learn the provisioned defaults.
|
||
|
||
6.2.4 IG0601 Added text indicating effect of omitting
|
||
specific properties from Descriptors in
|
||
commands modifying a termination.
|
||
Contradicted original text saying that omitted
|
||
properties retain their prior values (still
|
||
true for entirely-omitted Descriptors).
|
||
|
||
6.2.4 GEN0202 Modified above text to restrict it to
|
||
read/write properties, allow for default
|
||
behaviour in place of default values if so
|
||
specified in the property definition.
|
||
|
||
6.2.4 IGDUB Trimmed definition of signals Descriptor in
|
||
table and inserted cross-reference to section
|
||
7.1.11.
|
||
|
||
6.2.4 IG1100 Added Topology and Error Descriptors to table.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 196]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
6.2.5 IGDUB Specified error code to return if ROOT used
|
||
inappropriately.
|
||
|
||
7.1.1 IG1100 Added qualification to explanation of effect
|
||
of missing Audit Descriptor, excepting
|
||
Subtract.
|
||
|
||
7.1.3 GEN0202 Changed "inputs" to "bearers" to be consistent
|
||
with terminology in 6.2.
|
||
|
||
7.1.4 IG0601 Small change to make clear that more than one
|
||
of Local, Remote, and LocalControl can be
|
||
included in the default streamId.
|
||
|
||
7.1.7 IG0601 Default value for Mode specified to be
|
||
Inactive.
|
||
|
||
7.1.7 GEN0202 Added text requiring processing of media in
|
||
any of the reserved formats, where more than
|
||
one has been reserved in a given stream.
|
||
|
||
7.1.8 IGDUB Added restriction to at most one m= line per
|
||
session description.
|
||
|
||
7.1.9 IG0601 Text added to omit request identifier if the
|
||
EventsDescriptor is empty. Further text added
|
||
at end to indicate the effects of an empty
|
||
EventsDescriptor and an empty
|
||
EventBufferDescriptor.
|
||
|
||
7.1.9 IG0601 Fixed typo for destination of a Notify.
|
||
|
||
7.1.9 IG1100 Added note to say event remains active after
|
||
it has been notified, so long as it is still
|
||
present in the active Events Descriptor.
|
||
|
||
7.1.11 IGDUB Added definition of signals.
|
||
|
||
7.1.11 GEN0202 Modified definition to include example of more
|
||
complex signal, and added role of signal in
|
||
media preparation for future signals.
|
||
|
||
7.1.11 IGDUB The timeout completion reason was broadened to
|
||
include other circumstances where the signal
|
||
completed on its own. Text added to indicate
|
||
that if default signal type changed to TO,
|
||
duration parameter must be provided.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 197]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.1.11 GEN0202 Removed reference to BR signal being "so
|
||
short" it will stop on its own. Added text
|
||
indicating that if the type of a signal is
|
||
changed to TO, the Duration parameter must be
|
||
supplied.
|
||
|
||
7.1.11 IG1100 Deleted text discussing type of Signals List.
|
||
|
||
7.1.12 GEN0202 Improved wording of introductory paragraph and
|
||
added text making content of returned
|
||
Descriptor clear.
|
||
|
||
7.1.14.2 GEN0202 Added text indicating that when the start
|
||
timer is set to 0, initial digit timing is
|
||
disabled and the MG waits indefinitely for
|
||
digits.
|
||
|
||
7.1.14.2 GEN0202 Added text pointing out that default digit
|
||
timer values should be provisioned, but can be
|
||
overridden in the digit map.
|
||
|
||
7.1.14.3 GEN0202 Changed result of long-short digit timer
|
||
conflict from undefined to long.
|
||
|
||
7.1.14.6 IG1100 Clarified that the digit map is provided by
|
||
the eventDM parameter, which must be present.
|
||
|
||
7.1.14.7 GEN0202 Added text clarifying that events covered by
|
||
the digit map completion event have no side-
|
||
effects unless separately enabled.
|
||
|
||
7.1.14.8 IG0601 Added requirement that the event specification
|
||
include the eventDM parameter.
|
||
|
||
7.1.17 IGDUB Added text to indicate timestamp is optional
|
||
and to include observed event parameters in
|
||
reported content.
|
||
|
||
7.1.17 GEN0202 Deleted provision that time is expressed in
|
||
UTC (since intention was to use format, not
|
||
time zone).
|
||
|
||
7.1.18 IGDUB Added text indicating error to return if
|
||
topology option not supported.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 198]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.1.18 IG1100 Added text clarifying effect of not mentioning
|
||
TTPOST a termination in a topology Descriptor, and
|
||
default topology for a new termination. (This
|
||
text got lost between the Dublin meeting and
|
||
the production of H.248 Amendment 1 out of the
|
||
Geneva 02/02 meeting. It has been added back
|
||
to the present document.)
|
||
|
||
7.1.19 IG1100 New section to describe Error Descriptor.
|
||
GEN0202 Slightly edited in Geneva 02/02 meeting.
|
||
ITUPOST Reference for error code documentation updated
|
||
to H.248.8.
|
||
|
||
7.1.19 IG0601 Added paragraph giving guidance on level at
|
||
which errors should be reported.
|
||
|
||
7.2 IG1100 Noted possibility of Error Descriptor in reply
|
||
to any command.
|
||
|
||
7.2.1 IG1100 Added EventBufferDescriptor as Add parameter.
|
||
|
||
7.2.1 IG1100 Removed restriction on use of CHOOSE wildcard.
|
||
|
||
7.2.2 IG1100 Added EventBufferDescriptor as Modify
|
||
parameter.
|
||
|
||
7.2.2 GEN0202 Added text on side-effects of Modify of a
|
||
multiplexing termination.
|
||
|
||
7.2.3 IG1100 Added prohibition against subtracting from the
|
||
NULL context.
|
||
|
||
7.2.3 GEN0202 Added text on side-effects of Subtract of a
|
||
multiplexing termination.
|
||
|
||
7.2.3 IGDUB Added text clarifying effect of empty
|
||
AuditDescriptor in Subtract.
|
||
|
||
7.2.4 IG1100 Added EventBufferDescriptor as Move parameter.
|
||
|
||
7.2.4 GEN0202 Removed misleading statement that Move acts as
|
||
subtract from original context.
|
||
|
||
7.2.4 IG1100 Clarified effect of Move on properties of the
|
||
moved termination.
|
||
|
||
7.2.4 GEN0202 Added text on side-effects of Move of a
|
||
multiplexing termination.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 199]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
7.2.5 IG1100 Added examples showing W- wildcard usage.
|
||
|
||
7.2.5 IG1100 Noted that returning a list of all contextIDs
|
||
requires that they be returned one per
|
||
ActionReply.
|
||
|
||
7.2.5 IG1100 Added table entry (ALL, specific) to determine
|
||
context in which termination currently
|
||
resides.
|
||
|
||
7.2.6 GEN0202 Added table similar to that in 7.2.5.
|
||
|
||
7.2.7 IG0601 Added TerminationID to API.
|
||
|
||
7.2.7 IGDUB Indicated timestamp was optional in Notify, to
|
||
accord with syntax.
|
||
|
||
7.2.7 IG1100 Noted possibility of sending Error Descriptor
|
||
in Notify.
|
||
|
||
7.2.8 IG0601 Added text to description of Forced method to
|
||
indicate that Forced on ROOT indicates a cold
|
||
restart (all context state lost).
|
||
|
||
7.2.8 IGDUB Amplified explanation of Disconnected method
|
||
to emphasize return to the previously
|
||
controlling MGC.
|
||
|
||
7.2.8 IG0601 Added text for MG use of Failover method when
|
||
it detects MGC failure.
|
||
|
||
7.2.8 IG1100 Added notes discouraging use of
|
||
ServiceChangeAddress and warning that it could
|
||
be either a full address or just a port
|
||
number.
|
||
|
||
7.2.8 IG0601 Added text indicating that timestamp does not
|
||
necessarily represent absolute time, only
|
||
local clock reading.
|
||
|
||
7.2.8 IGDUB Corrected "gateway" to "MGC" in discussion of
|
||
returned ServiceChangeMgcId parameter.
|
||
|
||
7.3 IG0601 Removed error code documentation to Annex L
|
||
ITUPOST (now H.248.8).
|
||
|
||
8 IG1100 Added requirement that an Action be non-empty.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 200]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
8 GEN0202 Added context properties and context property
|
||
audit requests to commands as potential
|
||
contents of actions.
|
||
|
||
8.1.2 GEN0202 Added prohibition on using partial contextIDs
|
||
with ALL wildcards.
|
||
|
||
8.2.2 IG1100 Added text clarifying when in transaction
|
||
processing the requested actions have been
|
||
completed and a reply can be sent.
|
||
|
||
8.2.2 IG1100 Added ALL as allowed contextID in
|
||
TransactionReply.
|
||
|
||
8.2.2 GEN0202 Provided general reference to section 7.1.19
|
||
for generation of error Descriptors.
|
||
|
||
8.2.2 IG0601 Corrected Actions to Commands when discussing
|
||
partially-understood action.
|
||
|
||
8.3 IG0601 Added text specifying that the same MId value
|
||
must be used by a given entity throughout the
|
||
life of a control association.
|
||
|
||
8.3 IG0601 Added text expanding on independence of
|
||
transactions from messages.
|
||
|
||
9 ITUPOST Indicated that additional transports may be
|
||
defined in separate Recommendations as well as
|
||
annexes to the primary specification.
|
||
|
||
9 IG0601 Gave specific example of "request source
|
||
address" for IP.
|
||
|
||
9.1 IG1100 Deleted restriction to one outstanding Notify
|
||
command on a termination at one time, since
|
||
this is transport-specific.
|
||
|
||
9.1 IG0601 Restored restriction, but noted that it
|
||
applied only to transport not guaranteeing
|
||
ordered delivery.
|
||
|
||
10.2 IG1100 Corrected length of synthesized address field
|
||
from 10 to 20 hex digits and indicated that
|
||
calculation should be over entire message, not
|
||
just one transaction.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 201]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
11.2 IG1100 Corrected text in first two paragraphs
|
||
describing use of ServiceChangeMgcId
|
||
parameter.
|
||
|
||
11.2 IG1100 Corrected "Transaction Accept" to "Transaction
|
||
Reply".
|
||
|
||
11.4 IG0601 Noted that support of redundant MGs requires
|
||
GEN0202 use of a reliable transport and support in the
|
||
MGC. Added more explanation in Geneva.
|
||
|
||
11.5 IG0601 Added text clarifying procedure if MG unable
|
||
to establish a control relationship with any
|
||
of its eligible MGCs.
|
||
|
||
11.5 IGDUB Added text indicating that when trying to
|
||
reestablish contact with the previously
|
||
controlling MGC the MG uses the Disconnected
|
||
method.
|
||
|
||
11.5 IG1100 Clarified handoff procedure.
|
||
|
||
11.5 GEN0202 Changed text on replies to transactions in
|
||
progress during handoff. Replies now
|
||
discarded when the service relationship with
|
||
the old MGC has ended, rather than sent to the
|
||
new MGC. The new MGC could still send replies
|
||
to requests sent to the old MGC.
|
||
|
||
12.1.1 GEN0202 Added optional package designation as
|
||
"designed to be extended only".
|
||
|
||
12.1.1 IG1100 Made prohibition on overloading of identifiers
|
||
in extended packages transitive through all
|
||
ancestors of the extended package.
|
||
|
||
12.1.2 IGDUB Clarified the set of types allowed for
|
||
properties.
|
||
|
||
12.1.2 GEN0202 Added requirement to specify the base type of
|
||
a sub-list.
|
||
|
||
12.1.2 GEN0202 Provided requirements for content of the
|
||
"Possible Values" template item, including
|
||
specification of default values or behaviour.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 202]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
12.1.4 GEN0202 Added requirement to specify the default
|
||
signal type, and specify a default duration
|
||
for TO signals. Also noted that duration is
|
||
meaningless for BR, and that the signal type
|
||
might be dependent on the values of other
|
||
signal parameters.
|
||
|
||
12.2 GEN0202 Fixed section title (covers only event and
|
||
signal parameters, not properties or
|
||
statistics).
|
||
|
||
12.2 IG1100 Reserved SPA and EPA prefixes, so they are not
|
||
to be used for signal and event parameter
|
||
tokens.
|
||
|
||
12.2 IG0601 Expanded list of reserved prefixes.
|
||
|
||
12.2 IGDUB Clarified the set of types allowed for signal
|
||
and event parameters.
|
||
|
||
12.2 GEN0202 Added requirement to specify the base type of
|
||
a sub-list.
|
||
|
||
12.2 GEN0202 Provided requirements for content of the
|
||
"Possible Values" template item, including
|
||
specification of default values or behaviour.
|
||
|
||
12.4 IGDUB Corrected to indicate identifiers must start
|
||
with alphabetic rather than alphanumeric
|
||
character.
|
||
|
||
13.1 IG0601 Changed private range of binary package
|
||
identifiers to convenient hex values.
|
||
|
||
A GEN0202 Removed versions from X.680 and X.690
|
||
references.
|
||
|
||
A.2 IGDUB Added note warning that the syntax alone does
|
||
not provide a complete description of the
|
||
constraints, but must be supplemented by a
|
||
reading of the text and comments.
|
||
|
||
A.2 IG0601 Added description of double wrapping of
|
||
parameters declared as OCTET STRING.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 203]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A.2 GEN0202 Some editing of double wrapping description to
|
||
use ASN.1, BER in their proper places. Added
|
||
possibility of encoding strings as UTF8String,
|
||
but only if they contain non-ASCII characters.
|
||
|
||
A.2 IGDUB Added line in table on double wrapping of true
|
||
octet strings.
|
||
|
||
A.2 IG1100 Corrected and expanded comments describing
|
||
mtpAddress form of MId. Fixed maximum length
|
||
of mtpAddress both here and in
|
||
ServiceChangeAddress.
|
||
|
||
A.2 IG0601 Inserted missing lines in IP4Address
|
||
production.
|
||
|
||
A.2 IG0601 Modified TransactionResponseAck to allow
|
||
acknowledgement of multiple ranges of
|
||
transactionIds.
|
||
|
||
A.2 IG0601 Corrected numerical value of CHOOSE as a
|
||
context identifier.
|
||
|
||
A.2 IGDUB Added missing extension marker in
|
||
TopologyRequest.
|
||
|
||
A.2 IG1100 AuditReply and AuditResult modified to bring
|
||
binary functionality into line with text
|
||
functionality.
|
||
|
||
A.2 IG0601 Removed OPTIONAL tag from terminationID in
|
||
NotifyReply.
|
||
|
||
A.2 IG0601 Added extraInfo substructure to EventParameter
|
||
and SigParameter.
|
||
|
||
A.2 IG0601 Modified MediaDescriptor to make it optional
|
||
to specify a stream.
|
||
|
||
A.2 IG0601 Added OPTIONAL tags to reserveValue and
|
||
reserveGroup.
|
||
|
||
A.2 IGDUB Added to comments for pkgdName to indicate
|
||
applicability to event names, signal names,
|
||
and statisticIds as well as property.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 204]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
A.2 IG0601 RequestID made optional in EventsDescriptor
|
||
and SecondEventsDescriptor and comment added
|
||
saying it must be present if events are
|
||
present.
|
||
|
||
A.2 IG1100 Added OPTIONAL tags on RequestActions and
|
||
SecondRequestedActions keepActive BOOLEANs.
|
||
|
||
A.2 IG1100 Added comment to indicate requestID value to
|
||
use in an AuditCapReply.
|
||
|
||
A.2 GEN0202 Added comment to DigitMapValue indicating time
|
||
units for timers.
|
||
|
||
A.2 IG0601 Added comment indicating coding of Value for
|
||
GEN0202 ServiceChangeReason. Cleaned up in Geneva to
|
||
use ASN.1 and BER in their proper places.
|
||
|
||
A.2 IG0601 Inserted missing extension marker in
|
||
ServiceChangeParm production.
|
||
|
||
A.2 IG0601 Aligned definition of mtpAddress in
|
||
ServiceChangeAddress with that in MId.
|
||
|
||
A.2 IG0601 Added timestamp to ServiceChangeResParm.
|
||
|
||
A.2 IGDUB Changed type of profileName in
|
||
ServiceChangeProfile to IA5String.
|
||
|
||
A.2 IG0601 Made returned value optional in
|
||
statisticsParameter, to support
|
||
auditCapability result.
|
||
|
||
A.2 GEN0202 Added reference to ISO 8601:1988 for
|
||
TimeNotation.
|
||
|
||
A.2 IG1100 Value production modified to support the
|
||
sublist parameter type.
|
||
|
||
A.3 IG1100 Corrected ABNF for digitStringlisT, replacing
|
||
"/" with "|".
|
||
|
||
A.3 IG1100 Added parentheses to digitMapRange production.
|
||
|
||
A.3 IG1100 Replaced more abbreviated syntax for pathName
|
||
with fuller definition and constraints copied
|
||
from B.2.
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 205]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
B.2 IGDUB Added note warning that the syntax alone does
|
||
not provide a complete description of the
|
||
constraints, but must be supplemented by a
|
||
reading of the text and comments.
|
||
|
||
B.2 IG0601 Added note warning that the interpretation of
|
||
symbols is context-dependent.
|
||
|
||
B.2 IG1100 Added comment to indicate case insensitivity
|
||
of protocol (excepting SDP) and ABNF.
|
||
|
||
B.2 IG0601 Expanded upon and capitalized this comment.
|
||
|
||
B.2 IG0601 Lengthy note added on the coding of the VALUE
|
||
construct.
|
||
|
||
B.2 IGDUB Deleted sentence in note suggesting that
|
||
packages could add new types for properties,
|
||
parameters, or statistics.
|
||
|
||
B.2 IG0601 Added note indicating that parsers should
|
||
allow for white space preceding the first line
|
||
of SDP in Local or Remote.
|
||
|
||
B.2 IGDUB Added comments identifying the O- and W- tags.
|
||
|
||
B.2 IG1100 Moved wildcard tag up from individual commands
|
||
to commandRequestList.
|
||
|
||
B.2 GEN0202 Added additional error case to actionReply.
|
||
|
||
B.2 IG0601 Modified syntax of auditOther to allow return
|
||
of terminationID only.
|
||
|
||
B.2 IGDUB Corrected upper limit for V4hex.
|
||
|
||
B.2 IG1100 Corrected and expanded comments describing
|
||
mtpAddress form of MId.
|
||
|
||
B.2 IG0601 Modified comment to mediaParm to make
|
||
streamParms and StreamDescriptor mutually
|
||
exclusive.
|
||
|
||
B.2 GEN0202 Modified comment further to indicate at most
|
||
one instance of terminationStateDescriptor.
|
||
|
||
B.2 GEN0202 Expanded comment for streamParm to indicate
|
||
the restriction on repetition is per item.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 206]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
B.2 IG0601 Modified "at most once" comments to localParm,
|
||
terminationStateParm, and modemType, to allow
|
||
multiple instances of propertyParm in the
|
||
first two cases and extensionParameter in the
|
||
last one.
|
||
|
||
B.2 IG0601 Added note before description of Local and
|
||
Remote, pointing out that the octet value x00
|
||
is not allowed in octetString.
|
||
|
||
B.2 IG0601 Syntax for eventsDescriptor, embedFirst, and
|
||
eventBufferDescriptor modified to make
|
||
contents beyond token optional.
|
||
|
||
B.2 IGDUB Replaced "event" by "item" in comment to
|
||
pkgdName because pkgdName applies to
|
||
properties, signals, and statistics as well.
|
||
|
||
B.2 IG0601 Corrected placement of EQUAL in eventDM
|
||
production.
|
||
|
||
B.2 IG1100 Added comment and syntax to indicate requestID
|
||
value to use in an AuditCapReply.
|
||
|
||
B.2 IG1100 Corrected Modem Descriptor to allow package
|
||
items as properties.
|
||
|
||
B.2 IG0601 Comment to modemType changed to allow multiple
|
||
instances of extensionParameter.
|
||
|
||
B.2 GEN0202 Comment added to indicate units for Timer.
|
||
|
||
B.2 IG1100 Added parentheses to digitMapRange production.
|
||
|
||
B.2 IG1100 Added comment to serviceChangeParm,
|
||
restricting each parameter to one appearance.
|
||
|
||
B.2 IG0601 Added comments making serviceChangeMgcId and
|
||
serviceChangeAddress mutually exclusive in
|
||
ServiceChangeParm and servChgReplyParm.
|
||
|
||
B.2 IGDUB Added comment to serviceChangeParm indicating
|
||
that ServiceChangeMethod and
|
||
ServiceChangeReason are required.
|
||
|
||
B.2 IG0601 Added Timestamp to servChgReplyParm.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 207]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
B.2 IG0601 Added comment indicating coding of Value for
|
||
ServiceChangeReason.
|
||
|
||
B.2 IG0601 Modified ServiceChangeAddress to use MId
|
||
definition for full address.
|
||
|
||
B.2 IG1100 Made returned value optional in
|
||
statisticsParameter, to support
|
||
auditCapability result.
|
||
|
||
B.2 IG1100 Changed topologyDescriptor to allow multiple
|
||
triples.
|
||
|
||
B.2 IG0601 Added comment forbidding use of a double quote
|
||
within a quotedString value.
|
||
|
||
B.2 IG1100 Reserved prefixes for new tokens added to
|
||
signalParameter and eventParameter, to avoid
|
||
collision with package names.
|
||
|
||
B.2 IG1100 EmbedToken and EmergencyToken changed to
|
||
remove clash with EventBufferToken.
|
||
|
||
B.3 IG1100 New section describing hexadecimal octet
|
||
encoding.
|
||
|
||
B.4 IG1100 New section describing hex octet sequence.
|
||
|
||
C IG1100 Added permission to use Annex C properties in
|
||
LocalControl as well as in Local and Remote.
|
||
|
||
C IG0601 Added text making support of all properties of
|
||
Annex C optional.
|
||
|
||
C IGDUB Added directions to reconcile tabulated
|
||
formats with allowed types for properties.
|
||
|
||
C.1 IG1100 Corrected Q.765 reference to Q.765.5 for
|
||
ACodec.
|
||
|
||
C.1 IG1100 Deprecated Echocanc codepoint in favour of
|
||
package-defined property.
|
||
|
||
C.4 ITUPOST Updated references from Q.2961 to Q.2961.1.
|
||
|
||
C.4 IGDUB Added details on format of VPVC.
|
||
|
||
C.9 IG1100 Renamed USI to layer1prot.
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 208]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
C.9 IG1100 Deprecated ECHOCI codepoint in favour of
|
||
package-defined property.
|
||
|
||
C.9 IG1100 Added new USI property.
|
||
|
||
C.11 IG1100 Added m= line tag.
|
||
|
||
D.1 IG0601 Added explanation of ALF.
|
||
|
||
D.1.5 IGDUB Expanded text indicating that when trying to
|
||
reestablish contact with the previously
|
||
controlling MGC the MG uses the Disconnected
|
||
method.
|
||
|
||
E.1.2 GEN0202 Added missing EventsDescriptor parameters
|
||
lines.
|
||
|
||
E.1.2 GEN0202 For the Signal Completion event:
|
||
- corrected the description of how it is
|
||
enabled
|
||
- heavily edited the description of the Signal
|
||
Identity observed event parameter and added a
|
||
type.
|
||
|
||
E.1.2 IGDUB The timeout completion reason for the Signal
|
||
Completion event was broadened to include
|
||
other circumstances where the signal completed
|
||
on its own.
|
||
|
||
E.1.2 IG1100 Added signal list ID observed event parameter
|
||
to the Signal Completion event.
|
||
|
||
E.2.1 IG0601 Added missing read only, read-write
|
||
specifications.
|
||
|
||
E.2.1 IG0601 Split ProvisionalResponseTimer properties into
|
||
one for MG, one for MGC.
|
||
|
||
E.3 GEN0202 Added "Designed to be extended only" to
|
||
tonegen package description.
|
||
|
||
E.4 GEN0202 Added "Designed to be extended only" to
|
||
tonedet package description.
|
||
|
||
E.4.2 GEN0202 Added type for tone ID observed parameter for
|
||
Long Tone Detected event.
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 209]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
E.6.2 IG1100 Corrected binary identifier for digit map
|
||
completion event to avoid clash with base
|
||
package.
|
||
|
||
E.6.2 IG1100 Removed procedural text.
|
||
|
||
E.6.5 IG1100 Added procedural text indicating where to find
|
||
the applicable digit map and indicating the
|
||
error to return if the parameter is missing.
|
||
|
||
E.6.5 IG0601 Further modified procedural text.
|
||
|
||
E.7.3 IG1100 Corrected text identifier for payphone
|
||
recognition tone to avoid clash with base
|
||
package.
|
||
|
||
E.10.5 IGDUB Provided informative references for tones and
|
||
procedures for continuity check.
|
||
|
||
E.13 GEN0202 Added note that TDM package could also apply
|
||
to other transports.
|
||
|
||
E.13.1 IG1100 Changed default for echo cancellation from
|
||
"on" to provisioned.
|
||
|
||
E.13.1 IG0601 Corrected type for gain property.
|
||
|
||
Appendix TTPOST Included a number of corrections which were
|
||
I not picked up in H.248.1 Amendment 1 but which
|
||
do appear in H.248.1 v2.
|
||
|
||
Intellectual Property Rights
|
||
|
||
The ITU draws attention to the possibility that the practice or
|
||
implementation of this RFC may involve the use of a claimed
|
||
Intellectual Property Right. The ITU takes no position concerning
|
||
the evidence, validity or applicability of claimed Intellectual
|
||
Property Rights, whether asserted by ITU members or others outside of
|
||
the Recommendation development process.
|
||
|
||
As of the date of approval of this RFC, the ITU had received notice
|
||
of intellectual property, protected by patents, which may be required
|
||
to implement this RFC. However, implementors are cautioned that this
|
||
may not represent the latest information and are therefore strongly
|
||
urged to consult the TSB patent database.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 210]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
The IETF has also received notice of intellectual property claims
|
||
relating to Megaco/H.248.1. Please consult the IETF IPR
|
||
announcements at http://www.ietf.org/ipr.html.
|
||
|
||
Acknowledgments
|
||
|
||
Megaco/H.248.1 is the result of hard work by many people in both the
|
||
IETF and in ITU-T Study Group 16. This section records those who
|
||
played a prominent role in ITU-T meetings, on the Megaco list, or
|
||
both.
|
||
|
||
Megaco/H.248 owes a large initial debt to the MGCP protocol (RFC
|
||
2705), and thus to its authors, Mauricio Arango, Andrew Dugan, Ike
|
||
Elliott, Christian Huitema, and Scott Pickett. Flemming Andreasen
|
||
does not appear on this list of authors, but was a major contributor
|
||
to the development of both MGCP and Megaco/H.248.1. RFC 3435 has an
|
||
extensive acknowledgement of many other people who worked on media
|
||
gateway control before Megaco got started.
|
||
|
||
The authors of the first Megaco RFCs (2805, then 3015) were Fernando
|
||
Cuervo, Nancy Greene, Abdallah Rayhan, Christian Huitema, Brian
|
||
Rosen, and John Segers. Christian Groves conceived and was editor of
|
||
Annex C. The people most active on the Megaco list in the period
|
||
leading up to the completion of RFC 2885 were Brian Rosen, Tom
|
||
Taylor, Nancy Greene, Christian Huitema, Matt Holdrege, Chip Sharp,
|
||
John Segers, Michael Thomas, Henry Sinnreich, and Paul Sijben. The
|
||
people who sacrificed sleep and meals to complete the massive amount
|
||
of work required in the decisive Study Group 16 meeting of February,
|
||
2000, were Michael Brown, Ranga Dendi, Larry Forni, Glen Freundlich,
|
||
Christian Groves, Alf Heidemark, Steve Magnell, Selvam Rengasami,
|
||
Rich Rubin, Klaus Sambor, John Segers, Chip Sharp, Tom Taylor, and
|
||
Stephen Terrill.
|
||
|
||
The most active people on the Megaco list in the period since the
|
||
February 2000 have been Tom Taylor, Brian Rosen, Christian Groves,
|
||
Madhu Babu Brahmanapally, Troy Cauble, Terry Anderson, Chuong Nguyen,
|
||
and Kevin Boyle, but many other people have been regular
|
||
contributors. Brian Rosen did tremendous service in putting together
|
||
the Megaco interoperability tests. On the Study Group 16 side, the
|
||
editorial team for the final revised document in February, 2002
|
||
included Christian Groves, Marcello Pantaleo, Terry Anderson, Peter
|
||
Leis, Kevin Boyle, and Tom Taylor.
|
||
|
||
Tom Taylor as Megaco Chair managed the day to day operation of the
|
||
Megaco list, with Brian Rosen taking an equal share of the burden for
|
||
most of the last three years. Glen Freundlich as the Study Group 16
|
||
Rapporteur ran the ITU-T meetings and ensured that all of the work at
|
||
hand was completed. Without Glen's determination the Megaco/H.248
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 211]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
standard would have taken at least half a year longer to produce.
|
||
Christian Groves filled in ably as Rapporteur when Glen could no
|
||
longer take part.
|
||
|
||
Authors' Addresses
|
||
|
||
Terry L. Anderson
|
||
24 Hill St
|
||
Bernardsville, NJ 07924
|
||
USA
|
||
|
||
EMail: tlatla@verizon.net
|
||
|
||
|
||
Christian Groves
|
||
Ericsson AsiaPacificLab Australia
|
||
37/360 Elizabeth St
|
||
Melbourne, Victoria 3000
|
||
Australia
|
||
|
||
EMail: Christian.Groves@ericsson.com.au
|
||
|
||
|
||
Marcello Pantaleo
|
||
Ericsson Eurolab Deuschland
|
||
Ericsson Allee 1
|
||
52134 Herzogenrath, Germany
|
||
|
||
EMail: Marcello.Pantaleo@eed.ericsson.se
|
||
|
||
|
||
Tom Taylor
|
||
Nortel Networks
|
||
1852 Lorraine Ave,
|
||
Ottawa, Ontario
|
||
Canada K1H 6Z8
|
||
|
||
Phone: +1 613 736 0961
|
||
EMail: taylor@nortelnetworks.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 212]
|
||
|
||
RFC 3525 Gateway Control Protocol June 2003
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Groves, et al. Standards Track [Page 213]
|
||
|