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]
|
|||
|
|