draft-ietf-megaco-protocol-07.txt   rfc2885.txt 
Internet Engineering Task Force Fernando Cuervo Network Working Group F. Cuervo
INTERNET DRAFT Nortel Networks Request for Comments: 2885 N. Greene
February 21, 2000 Bryan Hill Category: Standards Track Nortel Networks
Expires August 21, 2000 Gotham Networks C. Huitema
<draft-ietf-megaco-protocol-07.txt> Nancy Greene Microsoft Corporation
Nortel Networks A. Rayhan
Christian Huitema Nortel Networks
Telcordia Technologies B. Rosen
Abdallah Rayhan Marconi
Nortel Networks J. Segers
Brian Rosen Lucent Technologies
Marconi August 2000
John Segers
Lucent Technologies
Megaco Protocol
Status of this document
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document will expire in July 2000.
Internet draft MEGACO Protocol February 21, 2000
1. SCOPE ..................................................... 8
2. REFERENCES ................................................ 8
2.1. Normative references ................................. 8
2.2. Informative references ............................... 10
3. DEFINITIONS ............................................... 11
4. ABBREVIATIONS ............................................. 12
5. CONVENTIONS ............................................... 12
6. CONNECTION MODEL .......................................... 12
6.1. Contexts ............................................. 15
6.1.1. Context Attributes and Descriptors .............. 16
6.1.2. Creating, Deleting and Modifying Contexts ....... 16
6.2. Terminations ......................................... 16
6.2.1. Termination Dynamics ............................ 17
6.2.2. TerminationIDs .................................. 17
6.2.3. Packages ........................................ 18
6.2.4. Termination Properties and Descriptors .......... 18
6.2.5. Root Termination ................................ 20
7. COMMANDS .................................................. 21
7.1. Descriptors .......................................... 22
7.1.1. Specifying Parameters ........................... 22
7.1.2. Modem Descriptor ................................ 23
7.1.3. Multiplex Descriptor ............................ 23
7.1.4. Media Descriptor ................................ 23
7.1.5. Termination State Descriptor .................... 24
7.1.6. Stream Descriptor ............................... 24
7.1.7. LocalControl Descriptor ......................... 25
7.1.8. Local and Remote Descriptors .................... 26
7.1.9. Events Descriptor ............................... 29
7.1.10. EventBuffer Descriptor ......................... 31
7.1.11. Signals Descriptor ............................. 31
7.1.12. Audit Descriptor ............................... 33
7.1.13. ServiceChange Descriptor ....................... 34
7.1.14. DigitMap Descriptor ............................ 34
7.1.15. Statistics Descriptor .......................... 39
7.1.16. Packages Descriptor ............................ 39
7.1.17. ObservedEvents Descriptor ...................... 39
7.1.18. Topology Descriptor ............................ 39
7.2. Command Application Programming Interface ............ 42
7.2.1. Add ............................................. 42
7.2.2. Modify .......................................... 44
7.2.3. Subtract ........................................ 44
7.2.4. Move ............................................ 45
7.2.5. AuditValue ...................................... 46
7.2.6. AuditCapabilities ............................... 48
7.2.7. Notify .......................................... 49
7.2.8. ServiceChange ................................... 49
7.2.9. Manipulating and Auditing Context Attributes .... 53
7.2.10. Generic Command Syntax ......................... 54
Internet draft MEGACO Protocol February 21, 2000
7.3. Command Error Codes .................................. 54
8. TRANSACTIONS .............................................. 56
8.1. Common Parameters .................................... 57
8.1.1. Transaction Identifiers ......................... 57
8.1.2. Context Identifiers ............................. 57
8.2. Transaction Application Programming Interface ........ 58
8.2.1. TransactionRequest .............................. 58
8.2.2. TransactionReply ................................ 58
8.2.3. TransactionPending .............................. 59
8.3. Messages ............................................. 60
9. TRANSPORT ................................................. 60
9.1. Ordering of Commands ................................. 61
9.2. Protection against Restart Avalanche ................. 62
10. SECURITY CONSIDERATIONS .................................. 63
10.1. Protection of Protocol Connections .................. 63
10.2. Interim AH scheme ................................... 64
10.3. Protection of Media Connections ..................... 65
11. MG-MGC CONTROL INTERFACE ................................. 65
11.1. Multiple Virtual MGs ................................ 66
11.2. Cold Start .......................................... 67
11.3. Negotiation of Protocol Version ..................... 67
11.4. Failure of an MG .................................... 68
11.5. Failure of an MGC ................................... 68
12. PACKAGE DEFINITION ....................................... 69
12.1. Guidelines for defining packages .................... 70
12.1.1. Package ........................................ 70
12.1.2. Properties ..................................... 71
12.1.3. Events ......................................... 71
12.1.4. Signals ........................................ 72
12.1.5. Statistics ..................................... 72
12.1.6. Procedures ..................................... 72
12.2. Guidelines to defining Properties, Statistics and .. 72
12.3. Lists ............................................... 73
12.4. Identifiers ......................................... 73
12.5. Package Registration ................................ 73
13. IANA CONSIDERATIONS ...................................... 73
13.1. Packages ............................................ 73
13.2. Error Codes ......................................... 74
13.3. ServiceChange Reasons ............................... 74
ANNEX A BINARY ENCODING OF THE PROTOCOL (NORMATIVE) ........... 76
A.1. Coding of wildcards .................................. 76
A.2. ASN.1 syntax specification ........................... 78
A.3. Digit maps and path names ............................ 93
ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE) ............. 94
B.1. Coding of wildcards .................................. 95
B.2. ABNF specification ................................... 95
ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE) ..........106
Internet draft MEGACO Protocol February 21, 2000
C.1. General Media Attributes .............................107
C.2. Mux Properties .......................................107
C.3. General Bearer Properties ............................107
C.4. General ATM Properties ...............................108
C.5. Frame Relay ..........................................108
C.6. IP ...................................................109
C.7. ATM AAL2 .............................................109
C.8. ATM AAL1 .............................................109
C.9. Bearer Capabilities ..................................110
C.10. AAL5 Properties .....................................111
C.11. SDP Equivalents .....................................112
C.12. H.245 ...............................................112
ANNEX D TRANSPORT OVER IP (NORMATIVE) .........................112
D.1. Transport over IP/UDP using Application Level ........112
D.1.1. Providing At-Most-Once Functionality ............113
D.1.2. Transaction identifiers and three-way handshake 113
D.1.2.1. Transaction identifiers ....................113
D.1.2.2. Three-way handshake ........................114
D.1.3. Computing retransmission timers .................114
D.1.4. Provisional responses ...........................115
D.1.5. Repeating Requests, Responses and ...............116
D.2. using TCP ............................................117
D.2.1. Providing the At-Most-Once functionality ........117
D.2.2. Transaction identifiers and three way handshake 118
D.2.3. Computing retransmission timers .................118
D.2.4. Provisional responses ...........................118
D.2.5. Ordering of commands ............................118
ANNEX E BASIC PACKAGES ........................................118
E.1. Generic ..............................................118
E.1.1. Properties ......................................119
E.1.2. Events ..........................................119
E.3.1. Properties ......................................122
E.3.2. Events ..........................................123
E.3.3. Signals .........................................123
E.3.4. Statistics ......................................123
E.3.5. Procedures ......................................123
E.4. Tone Detection Package ...............................123
E.4.1. Properties ......................................124
E.4.2. Events ..........................................124
E.4.3. Signals .........................................125
E.4.4. Statistics ......................................125
E.4.5. Procedures ......................................125
E.5. Basic DTMF Generator Package .........................125
E.5.1. Properties ......................................126
E.5.2. Events ..........................................126
Internet draft MEGACO Protocol February 21, 2000 Megaco Protocol version 0.8
E.5.3. Signals .........................................126 Status of this Memo
E.5.4. Statistics ......................................127
E.5.5. Procedures ......................................127
E.6. DTMF detection Package ...............................127
E.6.1. Properties ......................................128
E.6.2. Events ..........................................128
E.6.3. Signals .........................................128
E.6.4. Statistics ......................................129
E.6.5. Procedures ......................................129
E.7. Call Progress Tones Generator Package ................129
E.7.1. Properties ......................................129
E.7.2. Events ..........................................129
E.7.3. Signals .........................................129
E.7.4. Statistics ......................................130
E.7.5. Procedures ......................................130
E.8. Call Progress Tones Detection Package ................130
E.8.1. Properties ......................................130
E.8.2. Events ..........................................130
E.8.3. Signals .........................................130
E.8.4. Statistics ......................................131
E.8.5. Procedures ......................................131
E.9. Analog Line Supervision Package ......................131
E.9.1. Properties ......................................131
E.9.2. Events ..........................................131
E.9.3. Signals .........................................132
E.9.4. Statistics ......................................132
E.9.5. Procedures ......................................132
E.10. Basic Continuity Package ............................132
E.10.1. Properties .....................................133
E.10.2. Events .........................................133
E.10.3. Signals ........................................133
E.10.4. Statistics .....................................133
E.10.5. Procedures .....................................134
E.11. Network Package .....................................134
E.11.1. Properties .....................................134
E.11.2. Events .........................................134
E.11.3. Signals ........................................135
E.11.4. Statistics .....................................135
E.11.5. Procedures .....................................136
E.12. RTP Package .........................................136
E.12.1. Properties .....................................136
E.12.2. Events .........................................136
E.12.3. Signals ........................................137
E.12.4. Statistics .....................................137
E.12.5. Procedures .....................................137
E.13. TDM Circuit Package ................................137
E.13.1. Properties .....................................138
E.13.2. Events .........................................138
Internet draft MEGACO Protocol February 21, 2000 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.
E.13.3. Signals ........................................138 Copyright Notice
E.13.4. Statistics .....................................138
E.13.5. Procedures .....................................138
APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) ..............139
A.1. Residential Gateway to Residential Gateway Call .....139
A.1.1. Programming Residential GW Analog Line .........139
A.1.2. Collecting Originator Digits ....................141
Internet draft MEGACO Protocol February 21, 2000 Copyright (C) The Internet Society (2000). All Rights Reserved.
TABLE OF FIGURES Abstract
Figure 1 Example of MEGACOH.248 Connection Model................13
Figure 2 Example Call Waiting Scenario / Alerting Applied to T1.14
Figure 3 Example Call Waiting Scenario / Answer by T1...........15
Figure 4 Example topologies......................... ...........41
Figure 5 Transactions, Actions and Commands.....................56
Internet draft MEGACO Protocol February 21, 2000 This document is common text with Recommendation H.248 as
redetermined in Geneva, February 2000. It must be read in
conjunction with the Megaco Errata, RFC 2886. A merged document
presenting the Megaco protocol with the Errata incorporated will be
available shortly.
1. SCOPE The protocol presented in this document meets the requirements for a
media gateway control protocol as presented in RFC 2805.
MEGACO defines the protocols used between elements of a physically TABLE OF CONTENTS
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 monol-
ithic gateway such as described in H.246. This document does not define
how gateways, multipoint control units or integrated voice response
units (IVRs) work. Instead it creates a general framework that is suit-
able for these applications.
Packet network interfaces may include IP, ATM or possibly others. The 1. SCOPE..........................................................6
interfaces will support a variety of SCN signalling systems, including 2. REFERENCES.....................................................6
tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of these 2.1 Normative references..........................................6
signalling systems will be supported where applicable. 2.2 Informative references........................................8
3. DEFINITIONS....................................................9
4. ABBREVIATIONS.................................................10
5. CONVENTIONS...................................................11
6. CONNECTION MODEL..............................................11
6.1 Contexts.....................................................14
6.1.1 Context Attributes and Descriptors....................15
6.1.2 Creating, Deleting and Modifying Contexts.............15
6.2 Terminations.................................................15
6.2.1 Termination Dynamics..................................16
6.2.2 TerminationIDs........................................17
6.2.3 Packages..............................................17
6.2.4 Termination Properties and Descriptors................18
6.2.5 Root Termination......................................20
7. COMMANDS......................................................20
7.1 Descriptors..................................................21
7.1.1 Specifying Parameters.................................21
7.1.2 Modem Descriptor......................................22
7.1.3 Multiplex Descriptor..................................22
7.1.4 Media Descriptor......................................23
7.1.5 Termination State Descriptor..........................23
7.1.6 Stream Descriptor.....................................24
7.1.7 LocalControl Descriptor...............................24
7.1.8 Local and Remote Descriptors..........................25
7.1.9 Events Descriptor.....................................28
7.1.10 EventBuffer Descriptor...............................31
7.1.11 Signals Descriptor...................................31
7.1.12 Audit Descriptor.....................................32
7.1.13 ServiceChange Descriptor.............................33
7.1.14 DigitMap Descriptor..................................33
7.1.15 Statistics Descriptor................................38
7.1.16 Packages Descriptor..................................39
7.1.17 ObservedEvents Descriptor............................39
7.1.18 Topology Descriptor.................................39
7.2 Command Application Programming Interface....................42
7.2.1 Add...................................................43
7.2.2 Modify................................................44
7.2.3 Subtract..............................................45
7.2.4 Move..................................................46
7.2.5 AuditValue............................................47
7.2.6 AuditCapabilities.....................................48
7.2.7 Notify................................................49
7.2.8 ServiceChange.........................................50
7.2.9 Manipulating and Auditing Context Attributes..........54
7.2.10 Generic Command Syntax...............................54
7.3 Command Error Codes..........................................55
8. TRANSACTIONS..................................................56
8.1 Common Parameters............................................58
8.1.1 Transaction Identifiers...............................58
8.1.2 Context Identifiers...................................58
8.2 Transaction Application Programming Interface................58
8.2.1 TransactionRequest....................................59
8.2.2 TransactionReply......................................59
8.2.3 TransactionPending....................................60
8.3 Messages.....................................................61
9. TRANSPORT.....................................................61
9.1 Ordering of Commands.........................................62
9.2 Protection against Restart Avalanche.........................63
10. SECURITY CONSIDERATIONS......................................64
10.1 Protection of Protocol Connections..........................64
10.2 Interim AH scheme...........................................65
10.3 Protection of Media Connections.............................66
11. MG-MGC CONTROL INTERFACE....................................66
11.1 Multiple Virtual MGs........................................67
11.2 Cold Start..................................................68
11.3 Negotiation of Protocol Version.............................68
11.4 Failure of an MG............................................69
11.5 Failure of an MGC...........................................69
12. PACKAGE DEFINITION...........................................70
12.1 Guidelines for defining packages............................71
12.1.1 Package..............................................71
12.1.2 Properties...........................................72
12.1.3 Events...............................................72
12.1.4 Signals..............................................73
12.1.5 Statistics...........................................73
12.1.6 Procedures...........................................73
12.2 Guidelines to defining Properties, Statistics and Parameters
to Events and Signals.......................................73
12.3 Lists.......................................................74
12.4 Identifiers.................................................74
12.5 Package Registration........................................74
13. IANA CONSIDERATIONS.........................................74
13.1 Packages....................................................74
13.2 Error Codes.................................................75
13.3 ServiceChange Reasons.......................................76
ANNEX A: BINARY ENCODING OF THE PROTOCOL (NORMATIVE).............77
A.1 Coding of wildcards..........................................77
A.2 ASN.1 syntax specification...................................78
A.3 Digit maps and path names....................................94
ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE)................95
B.1 Coding of wildcards..........................................95
B.2 ABNF specification...........................................95
ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE)............107
C.1 General Media Attributes....................................107
C.2 Mux Properties..............................................108
C.3 General bearer properties...................................109
C.4 General ATM properties......................................109
C.5 Frame Relay.................................................112
C.6 IP..........................................................113
C.7 ATM AAL2....................................................113
C.8 ATM AAL1....................................................114
C.9 Bearer Capabilities.........................................116
C.10 AAL5 Properties............................................123
C.11 SDP Equivalents............................................124
C.12 H.245......................................................124
ANNEX D TRANSPORT OVER IP (NORMATIVE)...........................125
D.1 Transport over IP/UDP using Application Level Framing.......125
D.1.1 Providing At-Most-Once Functionality.................125
D.1.2 Transaction identifiers and three-way handshake......126
D.1.2.1 Transaction identifiers....................126
D.1.2.2 Three-way handshake........................126
D.1.3 Computing retransmission timers......................127
D.1.4 Provisional responses................................128
D.1.5 Repeating Requests, Responses and Acknowledgements...128
D.2 using TCP..................................................130
D.2.1 Providing the At-Most-Once functionality..........130
D.2.2 Transaction identifiers and three way handshake...130
D.2.3 Computing retransmission timers...................131
D.2.4 Provisional responses.............................131
D.2.5 Ordering of commands..............................131
ANNEX E BASIC PACKAGES..........................................131
E.1 Generic.....................................................131
E.1.1 Properties...........................................132
E.1.2 Events...............................................132
E.1.3 Signals..............................................133
E.1.4 Statistics...........................................133
E.2 Base Root Package...........................................133
E.2.1 Properties...........................................134
E.2.2 Events...............................................135
E.2.3 Signals..............................................135
E.2.4 Statistics...........................................135
E.2.5 Procedures...........................................135
E.3 Tone Generator Package......................................135
E.3.1 Properties...........................................135
E.3.2 Events...............................................136
E.3.3 Signals..............................................136
E.3.4 Statistics...........................................136
E.3.5 Procedures...........................................136
E.4 Tone Detection Package......................................137
E.4.1 Properties...........................................137
E.4.2 Events...............................................137
E.4.3 Signals..............................................139
E.4.4 Statistics...........................................139
E.4.5 Procedures...........................................139
E.5 Basic DTMF Generator Package................................140
E.5.1 Properties...........................................140
E.5.2 Events...............................................140
E.5.3 Signals..............................................140
E.5.4 Statistics...........................................141
E.5.5 Procedures...........................................141
E.6 DTMF detection Package......................................141
E.6.1 Properties...........................................142
E.6.2 Events...............................................142
E.6.3 Signals..............................................143
E.6.4 Statistics...........................................143
E.6.5 Procedures...........................................143
E.7 Call Progress Tones Generator Package.......................143
E.7.1 Properties...........................................144
E.7.2 Events...............................................144
E.7.3 Signals..............................................144
E.7.4 Statistics...........................................145
E.7.5 Procedures...........................................145
E.8 Call Progress Tones Detection Package.......................145
E.8.1 Properties...........................................145
E.8.2 Events...............................................145
E.8.3 Signals..............................................145
E.8.4 Statistics...........................................145
E.8.5 Procedures...........................................146
E.9 Analog Line Supervision Package.............................146
E.9.1 Properties...........................................146
E.9.2 Events...............................................146
E.9.3 Signals..............................................147
E.9.4 Statistics...........................................148
E.9.5 Procedures...........................................148
E.10 Basic Continuity Package...................................148
E.10.1 Properties..........................................148
E.10.2 Events..............................................148
E.10.3 Signals.............................................149
E.10.4 Statistics..........................................150
E.10.5 Procedures..........................................150
E.11 Network Package............................................150
E.11.1 Properties..........................................150
E.11.2 Events..............................................151
E.11.3 Signals.............................................152
E.11.4 Statistics..........................................152
E.11.5 Procedures..........................................153
E.12 RTP Package...............................................153
E.12.1 Properties..........................................153
E.12.2 Events..............................................153
E.12.3 Signals.............................................153
E.12.4 Statistics..........................................153
E.12.5 Procedures..........................................154
E.13 TDM Circuit Package........................................154
E.13.1 Properties..........................................155
E.13.2 Events..............................................155
E.13.3 Signals.............................................155
E.13.4 Statistics..........................................156
E.13.5 Procedures..........................................156
APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE).....................157
A.1 Residential Gateway to Residential Gateway Call.............157
A.1.1 Programming Residential GW Analog Line Terminations for
Idle Behavior..............................................157
A.1.2 Collecting Originator Digits and Initiating Termination
...........................................................159
Authors' Addresses..............................................168
Full Copyright Statement........................................170
The protocol definition in this document is common text with ITU Recom- 1. SCOPE
mendation H.248.
2. REFERENCES This document defines the protocol 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 H.246. This
recommendation does not define how gateways, multipoint control units
or integrated 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 SCN signalling systems,
including tone signalling, ISDN, ISUP, QSIG, and GSM. National
variants of these signalling systems will be supported where
applicable.
2.1. Normative references The protocol definition in this document is common text with ITU-T
Recommendation H.248. It meets the requirements documented in RFC
2805.
ITU-T Recommendation H.225.0 (1998): "Call Signalling Protocols and 2. REFERENCES
Media Stream Packetization for Packet Based Multimedia Communications
Systems".
ITU-T Recommendation H.235 (02/98): "Security and encryption for H- 2.1 Normative references
Series (H.323 and other H.245-based) multimedia terminals".
ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia Com- ITU-T Recommendation H.225.0 (1998): "Call Signalling Protocols and
munication". Media Stream Packetization for Packet Based Multimedia Communications
Systems".
ITU-T Recommendation H.323 (1998): "Packet Based Multimedia Communica- ITU-T Recommendation H.235 (02/98): "Security and encryption for
tion Systems". H-Series (H.323 and other H.245-based) multimedia terminals".
ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia
specification: Type 1 AAL". Communication".
ITU-T Recommendation I.363.2 (09/97), "B-ISDN ATM Adaptation Layer ITU-T Recommendation H.323 (1998): "Packet Based Multimedia
specification: Type 2 AAL". Communication Systems".
ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly Ser- ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer
vice Specific Convergence Sublayer for the AAL type 2". specification: Type 1 AAL".
ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific con- ITU-T Recommendation I.363.2 (09/97), "B-ISDN ATM Adaptation Layer
vergence sublayer for trunking". specification: Type 2 AAL".
Internet draft MEGACO Protocol February 21, 2000 ITU-T Recommendation I.363.5 (08/96), "B-ISDN ATM Adaptation Layer
specification: Type 5 AAL".
ITU-T Recommendation I.371 (08/96), "Traffic control and congestion con- ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly
trol in B- ISDN". Service Specific Convergence Sublayer for the AAL type 2".
ITU-T Recommendation Q.763 (09/97), "Signalling System No. 7 - ISDN user ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific
part formats and codes". convergence sublayer for trunking".
ITU-T Recommendation Q.765, "Signalling System No. 7 - Application tran- ITU-T Recommendation I.371 (08/96), "Traffic control and congestion
sport mechanism". control in B-ISDN".
ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling Sys- ITU-T Recommendation Q.763 (09/97), "Signalling System No. 7 - ISDN
tem No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification user part formats and codes".
for Basic Call Control".
ITU-T Recommendation Q.2630.1 (1999), "AAL Type 2 Signalling Protocol ITU-T Recommendation Q.765, "Signalling System No. 7 - Application
(Capability Set 1)". transport mechanism".
ITU-T Recommendation Q.2931 (10/95), "Broadband Integrated Services ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling
Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 System No. 1 (DSS 1) - ISDN User-Network Interface Layer 3
(DSS 2) - User- Network Interface (UNI) - Layer 3 specification for Specification for Basic Call Control".
basic call/connection control".
ITU-T Recommendation Q.2941.1 (09/97), "Digital Subscriber Signalling ITU-T Recommendation Q.2630.1 (1999), "AAL Type 2 Signalling Protocol
System No. 2 - Generic Identifier Transport". (Capability Set 1)".
ITU-T Recommendation Q.2961 (10/95), "Broadband integrated services ITU-T Recommendation Q.2931 (10/95), "Broadband Integrated Services
digital network (B-ISDN) - Digital subscriber signalling system no.2 Digital Network (B-ISDN) - Digital Subscriber Signalling System No.
(DSS 2) - additional traffic parameters". 2 (DSS 2) - User-Network Interface (UNI) - Layer 3 specification for
basic call/connection control".
ITU-T Recommendation Q.2961.2 (06/97), "Digital subscriber signalling ITU-T Recommendation Q.2941.1 (09/97), "Digital Subscriber Signalling
system No. 2 - Additional traffic parameters: Support of ATM transfer System No. 2 - Generic Identifier Transport".
capability in the broadband bearer capability information element."
ITU-T Recommendation X.213 (11/1995), "Information technology - Open ITU-T Recommendation Q.2961 (10/95), "Broadband integrated services
System Interconnection - Network service definition plus Amendment 1 digital network (B-ISDN) - Digital subscriber signalling system no.2
(08/1997), Addition of the Internet protocol address format identifier". (DSS 2) - additional traffic parameters".
ITU-T Recommendation V.76 (08/96), "Generic multiplexer using V.42 ITU-T Recommendation Q.2961.2 (06/97), "Digital subscriber signalling
LAPM-based procedures". system No. 2 - Additional traffic parameters: Support of ATM transfer
capability in the broadband bearer capability information element."
ITU-T Recommendation X.680 (1997): "Information technology-Abstract Syn- ITU-T Recommendation X.213 (11/1995), "Information technology - Open
tax Notation One (ASN.1): Specification of basic notation". System Interconnection - Network service definition plus Amendment 1
(08/1997), Addition of the Internet protocol address format
identifier".
ITU-T Recommendation H.246 (1998), "Interworking of H-series multimedia ITU-T Recommendation V.76 (08/96), "Generic multiplexer using V.42
terminals with H-series multimedia terminals and voice/voiceband termi- LAPM-based procedures".
nals on GSTN and ISDN".
RFC 1006, "ISO Transport Service on top of the TCP, Version 3", Marshall ITU-T Recommendation X.680 (1997): "Information technology-Abstract
T. Rose, Dwight E. Cass, May 1987. Syntax Notation One (ASN.1): Specification of basic notation".
Internet draft MEGACO Protocol February 21, 2000 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".
RFC 2234, "Augmented BNF for Syntax Specifications: ABNF", D. Crocker, Rose, M. and D. Cass, "ISO Transport Service on top of the TCP,
P. Overell, November 1997. Version 3", RFC 1006, May 1987.
RFC 2327, "SDP: Session Description Protocol", M. Handley, V. Jacobson, Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications:
April 1998. ABNF", RFC 2234, November 1997.
RFC 2402, "IP Authentication Header", S. Kent, R. Atkinson, November Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
1998. RFC 2327, April 1998.
RFC 2406, "IP Encapsulating Security Payload (ESP)", S. Kent, R. Atkin- Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
son, November 1998. November 1998.
2.2. Informative references Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.
ITU-T Recommendation E.180/Q.35 (1998): "Technical characteristics of 2.2 Informative references
tones for the telephone service".
CCITT Recommendation G.711 (1988), "Pulse Code Modulation (PCM) of voice ITU-T Recommendation E.180/Q.35 (1998): "Technical characteristics of
frequencies". tones for the telephone service".
ITU-T Recommendation H.221 (05/99),"Frame structure for a 64 to 1920 CCITT Recommendation G.711 (1988), "Pulse Code Modulation (PCM) of
kbit/s channel in audiovisual teleservices". voice frequencies".
ITU-T Recommendation H.223 (1996), "Multiplexing protocol for low bit ITU-T Recommendation H.221 (05/99),"Frame structure for a 64 to 1920
rate multimedia communication". kbit/s channel in audiovisual teleservices".
ITU-T Recommendation Q.724 (1988): "Signalling procedures". ITU-T Recommendation H.223 (1996), "Multiplexing protocol for low bit
rate multimedia communication".
RFC 768, "User Datagram Protocol", J.Postel, August 1980. ITU-T Recommendation Q.724 (1988): "Signalling procedures".
RFC 791, "Internet protocol", J.Postel, September 1981. Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
RFC 793, "TRANSMISSION CONTROL PROTOCOL", J.Postel, September 1981. Postel, J., "Internet protocol", STD 5, RFC 791, September 1981.
RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", H. Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, RFC 793,
Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. September 1981.
RFC 1890, "RTP Profile for Audio and Video Conferences with Minimal Con- Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661, July
trol", H. Schulzrinne, January 1996. 1994.
RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A
Atkinson, November 1998. Transport Protocol for Real-Time Applications", RFC 1889, January
1996.
RFC 2543, " SIP: Session Initiation Protocol", M. Handley, H. Schulzrinne, H., "RTP Profile for Audio and Video Conferences with
Schulzrinne, E. Schooler, J. Rosenberg, March 1999. Minimal Control", RFC 1890, January 1996.
RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", S. Deer- Kent, S. and R. Atkinson, "Security Architecture for the Internet
ing, R. Hinden, December 1998. Protocol", RFC 2401, November 1998.
Internet draft MEGACO Protocol February 21, 2000 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
3. DEFINITIONS Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, March 1999.
Access Gateway: A type of gateway that provides a User to Network Inter- Greene, N., Ramalho, M. and B. Rosen, "Media Gateway control protocol
face (UNI) such as ISDN. architecture and requirements", RFC 2805, April 1999.
Descriptor: A syntactic element of the protocol that groups related pro- 3. DEFINITIONS
perties. 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 Access Gateway: A type of gateway that provides a User to Network
type of network to the format required in another type of network. For Interface (UNI) such as ISDN.
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 mes-
sages and performs other IVR functions, or may perform media conferenc-
ing.
Media Gateway Controller (MGC): Controls the parts of the call state Descriptor: A syntactic element of the protocol that groups related
that pertain to connection control for media channels in a MG. 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.
Multipoint Control Unit (MCU): An entity that controls the setup and Media Gateway (MG): The media gateway converts media provided in one
coordination of a multi- user conference that typically includes pro- type of network to the format required in another type of network.
cessing of audio, video and data. 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 performs other IVR functions, or may
perform media conferencing.
Residential Gateway: A gateway that interworks an analogue line to a Media Gateway Controller (MGC): Controls the parts of the call state
packet network. A residential gateway typically contains one or two that pertain to connection control for media channels in a MG.
analogue lines and is located at the customer premises.
SCN FAS Signalling Gateway: This function contains the SCN Signalling Multipoint Control Unit (MCU): An entity that controls the setup and
Interface that terminates SS7, ISDN or other signalling links where the coordination of a multi-user conference that typically includes
call control channel and bearer channels are collocated in the same phy- processing of audio, video and data.
sical span.
SCN NFAS Signalling Gateway: This function contains the SCN Signalling Residential Gateway: A gateway that interworks an analogue line to a
Interface that terminates SS7 or other signalling links where the call packet network. A residential gateway typically contains one or two
control channels are separated from bearer channels. analogue lines and is located at the customer premises.
Stream: Bidirectional media or control flow received/sent by a media SCN FAS Signalling Gateway: This function contains the SCN Signalling
gateway as part of a call or conference. Interface that terminates SS7, ISDN or other signalling links where
the call control channel and bearer channels are collocated in the
same physical span.
Trunk: A communication channel between two switching systems such as a SCN NFAS Signalling Gateway: This function contains the SCN
DS0 on a T1 or E1 line. Signalling Interface that terminates SS7 or other signalling links
where the call control channels are separated from bearer channels.
Trunking Gateway: A gateway between SCN network and packet network that Stream: Bidirectional media or control flow received/sent by a media
typically terminates a large number of digital circuits. gateway as part of a call or conference.
Internet draft MEGACO Protocol February 21, 2000 Trunk: A communication channel between two switching systems such as
a DS0 on a T1 or E1 line.
4. ABBREVIATIONS Trunking Gateway: A gateway between SCN network and packet network
that typically terminates a large number of digital circuits.
This recommendation defines the following terms. 4. ABBREVIATIONS
ATM Asynchronous Transfer Mode
BRI Basic Rate Interface
CAS Channel Associated Signalling
DTMF Dual Tone Multi-Frequency
FAS Facility Associated Signalling
GW GateWay
IANA Internet Assigned Numbers Authority
IP Internet Protocol
ISUP ISDN User Part
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 This recommendation defines the following terms.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", ATM Asynchronous Transfer Mode
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this BRI Basic Rate Interface
document are to be interpreted as described in RFC2119. CAS Channel Associated Signalling
DTMF Dual Tone Multi-Frequency
FAS Facility Associated Signalling
GW GateWay
IANA Internet Assigned Numbers Authority
IP Internet Protocol
ISUP ISDN User Part
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
6. CONNECTION MODEL 5. CONVENTIONS
The connection model for the protocol describes the logical entities, or In this recommendation, "shall" refers to a mandatory requirement,
objects, within the Media Gateway that can be controlled by the Media while "should" refers to a suggested but optional feature or
Gateway Controller. The main abstractions used in the connection model procedure. The term "may" refers to an optional course of action
are Terminations and Contexts. without expressing a preference.
A Termination sources and/or sinks one or more streams. In a multimedia 6. CONNECTION MODEL
conference, a Termination can be multimedia and sources or sinks multi-
ple 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 The connection model for the protocol describes the logical entities,
is a special type of Context, the null Context, which contains all Ter- or objects, within the Media Gateway that can be controlled by the
minations that are not associated to any other Termination. For Media Gateway Controller. The main abstractions used in the
instance, in a decomposed access gateway, all idle lines are represented connection model are Terminations and Contexts.
by Terminations in the null Context.
Following is a graphical depiction of these concepts. The diagram of 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.
Internet draft MEGACO Protocol February 21, 2000 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.
Figure 1 gives several examples and is not meant to be an all-inclusive For instance, in a decomposed access gateway, all idle lines are
illustration. The asterisk box in each of the Contexts represents the represented by Terminations in the null Context.
logical association of Terminations implied by the Context.
+------------------------------------------------------+ +------------------------------------------------------+
|Media Gateway | |Media Gateway |
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
| |Context +-------------+ | | | |Context +-------------+ | |
| | | Termination | | | | | | Termination | | |
| | |-------------| | | | | |-------------| | |
| | +-------------+ +->| SCN Bearer |<---+-> | | +-------------+ +->| SCN Bearer |<---+->
| | | Termination | +-----+ | | Channel | | | | | | Termination | +-----+ | | Channel | | |
| | |-------------| | |---+ +-------------+ | | | | |-------------| | |---+ +-------------+ | |
skipping to change at page 13, line 52 skipping to change at page 12, line 46
| |Context | | | |Context | |
| | +-------------+ +-------------+ | | | | +-------------+ +-------------+ | |
| | | Termination | +-----+ | Termination | | | | | | Termination | +-----+ | Termination | | |
| | |-------------| | | |-------------| | | | | |-------------| | | |-------------| | |
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
| | | Channel | | | | Channel | | | | | | Channel | | | | Channel | | |
| | +-------------+ +-----+ +-------------+ | | | | +-------------+ +-----+ +-------------+ | |
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
| ___________________________________________________ | | ___________________________________________________ |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 1: Example of MEGACO Connection Model
Internet draft MEGACO Protocol February 21, 2000 Figure 1: Example of H.248 Connection Model
The example below shows an example of one way to accomplish a call- Figure 1 is a graphical depiction of these concepts. The diagram of
waiting scenario in a decomposed access gateway, illustrating the relo- Figure 1 gives several examples and is not meant to be an all-
cation of a Termination between Contexts. Terminations T1 and T2 belong inclusive illustration. The asterisk box in each of the Contexts
to Context C1 in a two-way audio call. A second audio call is waiting represents the logical association of Terminations implied by the
for T1 from Termination T3. T3 is alone in Context C2. T1 accepts the Context.
call from T3, placing T2 on hold. This action results in T1 moving into
Context C2, as shown below. The example below 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 below.
+------------------------------------------------------+ +------------------------------------------------------+
|Media Gateway | |Media Gateway |
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
| |Context C1 | | | |Context C1 | |
| | +-------------+ +-------------+ | | | | +-------------+ +-------------+ | |
| | | Term. T2 | +-----+ | Term. T1 | | | | | | Term. T2 | +-----+ | Term. T1 | | |
| | |-------------| | | |-------------| | | | | |-------------| | | |-------------| | |
<-+--->| RTP Stream |---| * |------| SCN Bearer |<---+-> <-+--->| RTP Stream |---| * |------| SCN Bearer |<---+->
| | | | | | | Channel | | | | | | | | | | Channel | | |
skipping to change at page 14, line 37 skipping to change at page 13, line 41
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
| |Context C2 | | | |Context C2 | |
| | +-------------+ | | | | +-------------+ | |
| | +-----+ | Term. T3 | | | | | +-----+ | Term. T3 | | |
| | | | |-------------| | | | | | | |-------------| | |
| | | * |------| SCN Bearer |<---+-> | | | * |------| SCN Bearer |<---+->
| | | | | Channel | | | | | | | | Channel | | |
| | +-----+ +-------------+ | | | | +-----+ +-------------+ | |
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
+------------------------------------------------------+ +------------------------------------------------------+
Figure 2 Example Call Waiting Scenario / Alerting Applied to T1
Internet draft MEGACO Protocol February 21, 2000
Figure 2: Example Call Waiting Scenario / Alerting Applied to T1
+------------------------------------------------------+ +------------------------------------------------------+
|Media Gateway | |Media Gateway |
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
| |Context C1 | | | |Context C1 | |
| | +-------------+ | | | | +-------------+ | |
| | | Term. T2 | +-----+ | | | | | Term. T2 | +-----+ | |
| | |-------------| | | | | | | |-------------| | | | |
<-+--->| RTP Stream |---| * | | | <-+--->| RTP Stream |---| * | | |
| | | | | | | | | | | | | | | |
| | +-------------+ +-----+ | | | | +-------------+ +-----+ | |
skipping to change at page 15, line 29 skipping to change at page 14, line 26
| +-------------------------------------------------+ | | +-------------------------------------------------+ |
| |Context C2 | | | |Context C2 | |
| | +-------------+ +-------------+ | | | | +-------------+ +-------------+ | |
| | | Term. T1 | +-----+ | Term. T3 | | | | | | Term. T1 | +-----+ | Term. T3 | | |
| | |-------------| | | |-------------| | | | | |-------------| | | |-------------| | |
<-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+->
| | | Channel | | | | Channel | | | | | | 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 Con-
text 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 Termina-
tions 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.
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
Internet draft MEGACO Protocol February 21, 2000
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 Con-
text. 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.
* 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 Figure 3. Example Call Waiting Scenario / Answer by T1
The protocol can be used to (implicitly) create Contexts and modify the 6.1 Contexts
parameter values of existing Contexts. The protocol has commands to add
Terminations to Contexts, subtract them from Contexts, and to move Ter-
minations between Contexts. Contexts are deleted implicitly when the
last remaining Termination is subtracted or moved out.
6.2. Terminations 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.
A Termination is a logical entity on a MG that sources and/or sinks There is a special Context called the null Context. It contains
media and/or control streams. A Termination is described by a number of Terminations that are not associated to any other Termination.
characterizing Properties, which are grouped in a set of Descriptors Terminations in the null Context can have their parameters examined
that are included in commands. Terminations have unique identities (Ter- or modified, and may have events detected on them.
minationIDs), assigned by the MG at the time of their creation.
Terminations representing physical entities have a semi-permanent In general, an Add command is used to add Terminations to Contexts.
existence. For example, a Termination representing a TDM channel might If the MGC does not specify an existing Context to which the
exist for as long as it is provisioned in the gateway. Terminations Termination is to be added, the MG creates a new Context. A
representing ephemeral information flows, such as RTP flows, would usu- Termination may be removed from a Context with a Subtract command,
ally exist only for the duration of their use. 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.
Ephemeral Terminations are created by means of an Add command. They are The maximum number of Terminations in a Context is a MG property.
destroyed by means of a Subtract command. In contrast, when a physical Media gateways that offer only point-to-point connectivity might
Termination is Added to or Subtracted from a Context, it is taken from allow at most two Terminations per Context. Media gateways that
support multipoint conferences might allow three or more terminations
per Context.
Internet draft MEGACO Protocol February 21, 2000 6.1.1 Context Attributes and Descriptors
or to the null Context, respectively. The attributes of Contexts are:
Terminations may have signals applied to them. Signals are MG generated . ContextID.
media streams such as tones and announcements as well as line signals
such as hookswitch. 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 Audit-
Value command, see section 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, . The topology (who hears/sees whom). The topology of a Context
Recommendation H.221 describes a frame structure for multiple media describes the flow of media between the Terminations within a
streams multiplexed on a number of digital 64 kbit/s channels. Such a Context. In contrast, the mode of a Termination (send/receive/_)
case is handled in the connection model in the following way. For every describes the flow of the media at the ingress/egress of the
bearer channel that carries part of the multiplexed streams, there is a media gateway.
Termination. The Terminations that source/sink the digital channels are
connected to a separate Termination called the multiplexing Termination.
This Termination describes the multiplex used (e.g. how the H.221 frames
are carried over the digital channels used). The MuxDescriptor is used
to this end. If multiple media are carried, this Termination contains
multiple StreamDescriptors. The media streams can be associated with
streams sourced/sunk by other Terminations in the Context.
Terminations may be created which represent multiplexed bearers, such as . The priority is used for a context in order to provide the MG
an ATM AAL2. When a new multiplexed bearer is to be created, an ephem- with information about a certain precedence handling for a
eral termination is created in a context established for this purpose. context. The MGC can also use the priority to control
When the termination is subtracted, the multiplexed bearer is destroyed. 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.
6.2.1. Termination Dynamics . An indicator for an emergency call is also provided to allow a
preference handling in the MG.
The protocol can be used to create new Terminations and to modify pro- 6.1.2 Creating, Deleting and Modifying Contexts
perty values of existing Terminations. These modifications include the
possibility of adding or removing events and/or signals. The Termina-
tion properties, and events and signals are described in the ensuing
sections. 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 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.
Terminations are referenced by a TerminationID, which is an arbitrary 6.2 Terminations
schema chosen by the MG.
TerminationIDs of physical Terminations are provisioned in the Media A Termination is a logical entity on a MG that sources and/or sinks
Gateway. The TerminationIDs may be chosen to have structure. For media and/or control streams. A Termination is described by a number
instance, a TerminationID may consist of trunk group and a trunk within of characterizing Properties, which are grouped in a set of
the group. Descriptors that are included in commands. Terminations have unique
identities (TerminationIDs), assigned by the MG at the time of their
creation.
Internet draft MEGACO Protocol February 21, 2000 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.
A wildcarding mechanism using two types of wildcards can be used with Terminations representing ephemeral information flows, such as RTP
TerminationIDs. The two wildcards are ALL and CHOOSE. The former is flows, would usually exist only for the duration of their use.
used to address multiple Terminations at once, while the latter is used
to indicate to a media gateway that it must select a Termination satis-
fying 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 ident- Ephemeral Terminations are created by means of an Add command. They
ical to repeating the command with each of the matching TerminationIDs. are destroyed by means of a Subtract command. In contrast, when a
Since each of these commands may generate a response, the size of the physical Termination is Added to or Subtracted from a Context, it is
entire response may be large. If individual responses are not required, taken from or to the null Context, respectively.
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. Wildcard response may be particularly useful in the
Audit commands.
The encoding of the wildcarding mechanism is detailed in Annexes A and Terminations may have signals applied to them. Signals are MG
B. generated media streams such as tones and announcements as well as
line signals such as hookswitch. 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 section 7.2.5)
and when the Termination is taken out of the call it is in.
6.2.3. Packages 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 Termination. The Terminations that
source/sink the digital channels are connected to a separate
Termination called the multiplexing Termination. This Termination
describes the multiplex used (e.g. how the H.221 frames are carried
over the digital channels used). The MuxDescriptor is used to this
end. If multiple media are carried, this Termination contains
multiple StreamDescriptors. The media streams can be associated with
streams sourced/sunk by other Terminations in the Context.
Different types of gateways may implement Terminations that have widely Terminations may be created which represent multiplexed bearers, such
differing characteristics. Variations in Terminations are accommodated as an ATM AAL2. When a new multiplexed bearer is to be created, an
in the protocol by allowing Terminations to have optional Properties, ephemeral termination is created in a context established for this
Events, Signals and Statistics implemented by MGs. purpose. When the termination is subtracted, the multiplexed bearer
is destroyed.
In order to achieve MG/MGC interoperability, such options are grouped 6.2.1 Termination Dynamics
into Packages, and a Termination realizes a set of such Packages. More
information on definition of packages can be found in section 12. An
MGC can audit a Termination to determine which Packages it realizes.
Properties, Events, Signals and Statistics defined in Packages, as well The protocol can be used to create new Terminations and to modify
as parameters to them, are referenced by identifiers (Ids). Identifiers property values of existing Terminations. These modifications
are scoped. For each package, PropertyIds, EventIds, SignalIds, Statis- include the possibility of adding or removing events and/or signals.
ticsIds and ParameterIds have unique name spaces and the same identifier The Termination properties, and events and signals are described in
may be used in each of them. Two PropertyIds in different packages may the ensuing sections. An MGC can only release/modify terminations and
also have the same identifier, etc. the resources that the termination represents which it has previously
seized via, e.g., the Add command.
6.2.4. Termination Properties and Descriptors 6.2.2 TerminationIDs
Terminations have properties. The properties have unique PropertyIDs. Terminations are referenced by a TerminationID, which is an arbitrary
Most properties have default values. When a Termination is created, schema chosen by the MG.
properties get their default values, unless the controller specifically
sets a different value. The default value of a property of a physical
Termination can be changed by setting it to a different value when the
Termination is in the null Context. Every time such a Termination
returns to the null Context, the values of its properties are reset to
Internet draft MEGACO Protocol February 21, 2000 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.
this default value. 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.
There are a number of common properties for Terminations and properties When ALL is used in the TerminationID of a command, the effect is
specific to media streams. The common properties are also called the identical to repeating the command with each of the matching
termination state properties. For each media stream, there are local TerminationIDs. Since each of these commands may generate a
properties and properties of the received and transmitted flows. 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.
Wildcard response may be particularly useful in the Audit commands.
Properties not included in the base protocol are defined in Packages. The encoding of the wildcarding mechanism is detailed in Annexes A
These properties are referred to by a name consisting of the PackageName and B.
and a PropertyId. Most properties have default values described in the
Package description. Properties may be read-only or read/write. The pos-
sible 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 6.2.3 Packages
properties can be set by including the appropriate descriptors as param-
eters to the Add command. Properties not mentioned in the command
retain their prior values. Similarly, a property of a Termination in a
Context may have its value changed by the Modify command. Properties
not mentioned in the Modify command retain their prior values. Proper-
ties 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. The following table
lists all of the possible Descriptors and their use. Not all descrip-
tors are legal as input or output parameters to every command.
_________________________________________________________________________ Different types of gateways may implement Terminations that have
|Descriptor Name |Description | widely differing characteristics. Variations in Terminations are
|__________________|____________________________________________________| accommodated in the protocol by allowing Terminations to have
|Modem |Identifies modem type and properties when | optional Properties, Events, Signals and Statistics implemented by
| |applicable | MGs.
|__________________|____________________________________________________|
|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 |
Internet draft MEGACO Protocol February 21, 2000 In order to achieve MG/MGC interoperability, such options are grouped
into Packages, and a Termination realizes a set of such Packages.
More information on definition of packages can be found in section
12. An MGC can audit a Termination to determine which Packages it
realizes.
| |that MG receives from the remote entity. | 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,
|Remote |Contains properties that specify the media flows | SignalIds, StatisticsIds and ParameterIds have unique name spaces and
| |that the MG sends to the remote entity. | |__________________|____________________________________________________| the same identifier may be used in each of them. Two PropertyIds in
|LocalControl |Contains properties (which can be defined in | different packages may also have the same identifier, etc.
| |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 | |__________________|____________________________________________________|
|EventBuffer |Describes events to be detected by the MG when Event|
| |Buffering is active | |__________________|____________________________________________________|
|Signals |Describes signals and/or actions to be applied (e.g.|
| |Busy Tone) to the Terminations | |__________________|____________________________________________________|
|Audit |In Audit commands, identifies which information is |
| |desired |
|__________________|____________________________________________________|
|Packages |In AuditValue, returns a list of Packages realized |
| |by a Termination | |__________________|____________________________________________________|
|DigitMap |Instructions for handling DTMF tones at the MG |
|__________________|____________________________________________________|
|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. | |__________________|____________________________________________________|
6.2.5. Root Termination 6.2.4 Termination Properties and Descriptors
Occasionally, a command must refer to the entire gateway, rather than a Terminations have properties. The properties have unique
termination within it. A special TerminationID, "Root" is reserved for PropertyIDs. Most properties have default values. When a
this purpose. Packages may be defined on Root. Root thus may have pro- Termination is created, properties get their default values, unless
perties and events (signals are not appropriate for root). Accord- the controller specifically sets a different value. The default
ingly, the root TerminationID may appear in: value of a property of a physical Termination can be changed by
setting it to a different value when the Termination is in the null
Context. Every time such a Termination returns to the null Context,
the values of its properties are reset to this default value.
* a Modify command - to change a property or set an event 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.
* a Notify command - to report an event 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.
* an AuditValue return - to examine the values of properties imple- When a Termination is Added to a Context, the value of its read/write
mented on root properties can be set by including the appropriate descriptors as
parameters to the Add command. Properties not mentioned in the
command retain their prior values. Similarly, a property of a
Termination in a Context may have its value changed by the Modify
command. Properties not mentioned in the Modify command retain their
prior values. 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.
* an AuditCapability - to determine what properties of root are The following table lists all of the possible Descriptors and their
implemented a ServiceChange - to declare the gateway in or out of use. Not all descriptors are legal as input or output parameters to
service Any other use of the root TerminationID is an error. every command.
Internet draft MEGACO Protocol February 21, 2000 Descriptor Name Description
7. COMMANDS 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.
EventBuffer Describes events to be detected by the MG
when Event Buffering is active.
Signals Describes signals and/or actions to be
applied (e.g. Busy Tone) to the
Terminations.
Audit In Audit commands, identifies which
information is desired.
Packages In AuditValue, returns a list of Packages
realized by Termination.
DigitMap Instructions for handling DTMF tones at
the MG.
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.
The protocol provides commands for manipulating the logical entities of 6.2.5 Root Termination
the protocol connection model, Contexts and Terminations. Commands pro-
vide control at the finest level of granularity supported by the proto-
col. 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 Occasionally, a command must refer to the entire gateway, rather than
as command initiator in controlling Media Gateways as command a termination within it. A special TerminationID, "Root" is reserved
responders. The exceptions are the Notify and ServiceChange commands: for this purpose. Packages may be defined on Root. Root thus may
Notify is sent from Media Gateway to Media Gateway Controller, and Ser- have properties and events (signals are not appropriate for root).
viceChange may be sent by either entity. Below is an overview of the Accordingly, the root TerminationID may appear in:
commands; they are explained in more detail in section 7.2.
1. Add. The Add command adds a termination to a context. The Add com- . a Modify command - to change a property or set an event
mand on the first Termination in a Context is used to create a Con- . a Notify command - to report an event
text. . an AuditValue return - to examine the values of properties
implemented on root
. an AuditCapability - to determine what properties of root are
implemented
. a ServiceChange - to declare the gateway in or out of service.
2. Modify. The Modify command modifies the properties, events and sig- Any other use of the root TerminationID is an error.
nals of a termination.
3. Subtract. The Subtract command disconnects a Termination from its 7. COMMANDS
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 The protocol provides commands for manipulating the logical entities
context. 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).
5. AuditValue. The AuditValue command returns the current state of Most commands are for the specific use of the Media Gateway
properties, events, signals and statistics of Terminations. 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
section 7.2.
6. AuditCapabilities. The AuditCapabilities command returns all the 1. Add. The Add command adds a termination to a context. The Add
possible values for Termination properties, events and signals command on the first Termination in a Context is used to create a
allowed by the Media Gateway. Context.
7. Notify. The Notify command allows the Media Gateway to inform the 2. Modify. The Modify command modifies the properties, events and
Media Gateway Controller of the occurrence of events in the Media signals of a termination.
Gateway.
8. ServiceChange. The ServiceChange Command allows the Media Gateway 3. Subtract. The Subtract command disconnects a Termination from its
to notify the Media Gateway Controller that a Termination or group 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.
Internet draft MEGACO Protocol February 21, 2000 4. Move. The Move command atomically moves a Termination to another
context.
of Terminations is about to be taken out of service or has just 5. AuditValue. The AuditValue command returns the current state of
been returned to service. ServiceChange is also used by the MG to properties, events, signals and statistics of Terminations.
announce its availability to an 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 com-
mand. 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 sections 7.2.1 through 7.2.8
7.1. Descriptors 6. AuditCapabilities. The AuditCapabilities command returns all the
possible values for Termination properties, events and signals
allowed by the Media Gateway.
The parameters to a command are termed Descriptors. A Descriptor con- 7. Notify. The Notify command allows the Media Gateway to inform the
sists of a name and a list of items. Some items may have values. Many Media Gateway Controller of the occurrence of events in the Media
Commands share common Descriptors. This subsection enumerates these Gateway.
Descriptors. Descriptors may be returned as output from a command.
Parameters and parameter usage specific to a given Command type are
described in the subsection that describes the Command.
7.1.1. Specifying Parameters 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 an 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.
Command parameters are structured into a number of descriptors. In gen- These commands are detailed in sections 7.2.1 through 7.2.8
eral, the text format of descriptors is
DescriptorName=<someID>{parm=value, parm=value....}
Parameters may be fully specified, over-specified or under-specified: 7.1 Descriptors
1. Fully specified parameters have a single, unambiguous value that The parameters to a command are termed Descriptors. A Descriptor
the command initiator is instructing the command responder to use consists of a name and a list of items. Some items may have values.
for the specified parameter. Many Commands share common Descriptors. This subsection enumerates
these Descriptors. Descriptors may be returned as output from a
command. Parameters and parameter usage specific to a given Command
type are described in the subsection that describes the Command.
2. Under-specified parameters, using the CHOOSE value, allow the com- 7.1.1 Specifying Parameters
mand responder to choose any value it can support.
3. Over-specified parameters have a list of potential values. The Command parameters are structured into a number of descriptors. In
list order specifies the command initiator's order of preference of general, the text format of descriptors is
selection. The command responder chooses one value from the DescriptorName=<someID>{parm=value, parm=value_.}.
offered list and returns that value to the command initiator.
Unspecified mandatory parameters (i.e. mandatory parameters not
specified in a descriptor) result in the command responder retain-
ing the previous value for that parameter. Unspecified optional
parameters result in the command responder using the default value
of the parameter. Whenever a parameter is underspecified or over-
specified, 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 Parameters may be fully specified, over-specified or under-specified:
TerminationId may be "wildcarded". When the TerminationId of a command
is wildcarded, the effect shall be as if the command was repeated with
Internet draft MEGACO Protocol February 21, 2000 1. Fully specified parameters have a single, unambiguous value that
the command initiator is instructing the command responder to use
for the specified parameter.
each of the TerminationIds matched. 2. Under-specified parameters, using the CHOOSE value, allow the
command responder to choose any value it can support.
7.1.2. Modem Descriptor 3. Over-specified 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.
The Modem descriptor specifies the modem type and parameters, if any, Unspecified mandatory parameters (i.e. mandatory parameters not
required for use in e.g. H.324 and text conversation. The descriptor specified in a descriptor) result in the command responder retaining
includes the following modem types: V.18, V.22, V.22bis, V.32, V.32bis, the previous value for that parameter. Unspecified optional
V.34, V.90, V.91, Synchronous ISDN, and allows for extensions. By parameters result in the command responder using the default value of
default, no modem descriptor is present in a Termination. the parameter. Whenever a parameter is underspecified or
overspecified, the descriptor containing the value chosen by the
responder is included as output from the command.
7.1.3. Multiplex Descriptor 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.
In multimedia calls, a number of media streams are carried on a (possi- 7.1.2 Modem Descriptor
bly different) number of bearers. The multiplex descriptor associates
the media and the bearers. The descriptor includes the multiplex type:
* H.221 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.22bis, V.32,
V.32bis, V.34, V.90, V.91, Synchronous ISDN, and allows for
extensions. By default, no modem descriptor is present in a
Termination.
* H.223, 7.1.3 Multiplex Descriptor
* H.226, 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:
* V.76, . H.221
. H.223,
. H.226,
. V.76,
. Possible Extensions
* Possible Extensions and a set of TerminationIDs representing the and a set of TerminationIDs representing the multiplexed inputs, in
multiplexed inputs, in order. For example: order. For example:
Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22} Mux = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}
7.1.4. Media Descriptor 7.1.4 Media Descriptor
The Media Descriptor specifies the parameters for all the media streams. The Media Descriptor specifies the parameters for all the media
These parameters are structured into two descriptors, a Termination streams. These parameters are structured into two descriptors, a
State Descriptor, which specifies the properties of a termination that Termination State Descriptor, which specifies the properties of a
are not stream dependent, and one or more Stream Descriptors each of termination that are not stream dependent, and one or more Stream
which describes a single media stream. Descriptors each of which describes a single media stream.
A stream is identified by a StreamID. The StreamID is used to link the A stream is identified by a StreamID. The StreamID is used to link
streams in a Context that belong together. Multiple streams exiting a the streams in a Context that belong together. Multiple streams
termination shall be synchronized with each other. Within the Stream exiting a termination shall be synchronized with each other. Within
Descriptor, there are up to three subsidiary descriptors, LocalControl, the Stream Descriptor, there are up to three subsidiary descriptors,
Local, and Remote. The relationship between these descriptors is thus: LocalControl, Local, and Remote. The relationship between these
descriptors is thus:
Media Descriptor Media Descriptor
TerminationStateDescriptor TerminationStateDescriptor
Stream Descriptor Stream Descriptor
LocalControl Descriptor LocalControl Descriptor
Local Descriptor Local Descriptor
Internet draft MEGACO Protocol February 21, 2000
Remote Descriptor Remote Descriptor
As a convenience a LocalControl, Local, or Remote descriptor may be As a convenience a LocalControl, Local, or Remote descriptor may be
included in the Media Descriptor without an enclosing Stream descriptor. included in the Media Descriptor without an enclosing Stream
In this case, the StreamID is assumed to be 1. descriptor. In this case, the StreamID is assumed to be 1.
7.1.5. Termination State Descriptor
The Termination State 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 termina-
tion (not stream-specific). A Termination can be in one of the follow-
ing states: "test", "out of service", or "in service". The "test" state
indicates that the termination is being tested. The state "out of ser-
vice" 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.
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 Descrip-
tor, or processed immediately. See section 7.1.9 for details.
7.1.6. Stream Descriptor
A Stream descriptor specifies the parameters of a single bi-directional
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
Internet draft MEGACO Protocol February 21, 2000
ReserveGroup and ReserveValue in LocalControl set to "false" on all ter-
minations 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.
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 section
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.
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 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 alterna-
tive, 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 suf-
ficient resources to support any of the alternatives specified, is SHALL
Internet draft MEGACO Protocol February 21, 2000
respond with error 510 (insufficient resources).
The default value of ReserveValue and ReserveGroup is False.
A new setting of the LocalControl Descriptor completely replaces the
previous setting of that descriptor in the MG. Thus to retain informa-
tion 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 com-
mand) 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 (RFC2327). 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.
* 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
RFC2327. 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 descrip-
tion.
Below, the semantics of the local and remote descriptors are specified
Internet draft MEGACO Protocol February 21, 2000
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
* unspecified (i.e., absent),
* empty,
* underspecified through use of CHOOSE in a property value,
* fully specified, or
* 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 section
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 signi- 7.1.5 Termination State Descriptor
fies 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 The Termination State Descriptor contains the ServiceStates property,
descriptor or multiple values within a group, the order of prefer- the EventBufferControl property and properties of a termination
ence is descending. (defined in Packages) that are not stream specific.
(d) Underspecified or overspecified properties within a group of pro- The ServiceStates property describes the overall state of the
perties sent by the MGC are requests for the MG to choose one or termination (not stream-specific). A Termination can be in one of
more values which it can support for each of those properties. In the following states: "test", "out of service", or "in service". The
case of an overspecified property, the list of values is in des- "test" state indicates that the termination is being tested. The
cending order of preference. 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.
Subject to the above rules, subsequent action depends on the values of Values assigned to Properties may be simple values
the ReserveValue and ReserveGroup properties in LocalControl. If (integer/string/enumeration) or may be underspecified, where more
ReserveGroup is true, the MG reserves the resources required to support than one value is supplied and the MG may make a choice:
any of the requested property group alternatives that it can currently . Alternative Values: multiple values in a list, one of which must
support. If ReserveValue is true, the MG reserves the resources 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
Internet draft MEGACO Protocol February 21, 2000 The EventBufferControl property specifies whether events are
buffered following detection of an event in the Events Descriptor, or
processed immediately. See section 7.1.9 for details.
required to support any of the requested property value alternatives 7.1.6 Stream Descriptor
that it can currently support.
NOTE - If a Local or Remote descriptor contains multiple groups of pro- A Stream descriptor specifies the parameters of a single bi-
perties, and ReserveGroup is true, then the MG is requested to reserve directional stream. These parameters are structured into three
resources so that it can decode or encode the media stream according to descriptors: one that contains termination properties specific to a
any of the alternatives. For instance, if the Local descriptor contains stream and one each for local and remote flows. The Stream Descriptor
two groups of properties, one specifying packetized G.711 A-law audio includes a StreamID which identifies the stream. Streams are created
and the other G.723.1 audio, the MG reserves resources so that it can by specifying a new StreamID on one of the terminations in a Context.
decode one audio stream encoded in either G.711 A-law format or G.723.1 A stream is deleted by setting empty Local and Remote descriptors for
format. The MG does not have to reserve resources to decode two audio the stream with ReserveGroup and ReserveValue in LocalControl set to
streams simultaneously, one encoded in G.711 A-law and one in G.723.1. "false" on all terminations in the context that previously supported
The intention for the use of ReserveValue is analogous. If Reserve- that stream.
Group is true or ReserveValue is true, then the following rules apply.
* If the MG has insufficient resources to support all alternatives StreamIDs are of local significance between MGC and MG and they are
requested by the MGC and the MGC requested resources in both Local assigned by the MGC. Within a context, StreamID is a means by which
and Remote, the MG should reserve resources to support at least to indicate which media flows are interconnected: streams with the
one alternative each within Local and Remote. same StreamID are connected.
* If the MG has insufficient resources to support at least one alter- If a termination is moved from one context to another, the effect on
native within a Local (Remote) descriptor received from the MGC, the context to which the termination is moved is the same as in the
it shall return an empty Local (Remote) in response. case that a new termination were added with the same StreamIDs as the
moved termination.
* In its response to the MGC, when the MGC included Local and Remote 7.1.7 LocalControl Descriptor
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 or The LocalControl Descriptor contains the Mode property, the
SendRecv, the MG must be prepared to receive media encoded accord- ReserveGroup and ReserveValue properties and properties of a
ing to any of the alternatives included in its response to the MGC. termination (defined in Packages) that are stream specific, and are
If ReserveGroup is False and ReserveValue is false, then the MG of interest between the MG and the MGC. Values of properties may be
SHOULD apply the following rules to resolve Local and Remote to a underspecified as in section 7.1.1.
single alternative each:
* The MG chooses the first alternative in Local for which it is able The allowed values for the mode property are send-only, receive-only,
to support at least one alternative in Remote. 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. Signals and Events are not affected by mode.
* If the MG is unable to support at least one Local and one Remote The boolean-valued Reserve properties, ReserveValue and ReserveGroup,
alternative, it returns Error 510 (Insufficient Resources). of a Termination indicate what the MG is expected to do when it
receives a local and/or remote descriptor.
* The MG returns its selected alternative in each of Local and If the value of a Reserve property is True, the MG SHALL reserve
Remote. A new setting of a Local or Remote Descriptor completely resources for all alternatives specified in the local and/or remote
replaces the previous setting of that descriptor in the MG. Thus descriptors for which it currently has resources available. It SHALL
to retain information from the previous setting the MGC must 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.
Internet draft MEGACO Protocol February 21, 2000 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, is SHALL respond with
error 510 (insufficient resources).
include that information in the new setting. If the MGC wishes to The default value of ReserveValue and ReserveGroup is False.
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 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.
The EventsDescriptor parameter contains a RequestIdentifier and a list 7.1.8 Local and Remote Descriptors
of events that the Media Gateway is requested to detect and report. The
RequestIdentifier is used to correlate the request with the notifica-
tions that it may trigger. Requested events include, for example, fax
tones, continuity test results, and on-hook and off-hook transitions.
Each event in the descriptor contains the Event name, an optional The MGC uses Local and Remote descriptors to reserve and commit MG
streamID, an optional KeepActive flag, and optional parameters. The resources for media decoding and encoding for the given Stream(s) and
Event name consists of a Package Name (where the event is defined) and Termination to which they apply. The MG includes these descriptors
an EventID. The ALL wildcard may be used for the EventID, indicating in its response to indicate what it is actually prepared to support.
that all events from the specified package have to be detected. The The MG SHALL include additional properties and their values in its
default streamID is 0, indicating that the event to be detected is not response if these properties are mandatory yet not present in the
related to a particular media stream. Events can have parameters. This requests made by the MGC (e.g., by specifying detailed video encoding
allows a single event description to have some variation in meaning parameters where the MGC only specified the payload type).
without creating large numbers of individual events. Further event
parameters are defined in the package.
The default action of the MG, when it detects an event in the Events Local refers to the media received by the MG and Remote refers to the
Descriptor, is to send a Notify command to the MG. Any other action is media sent by the MG.
for further study.
If the value of the EventBufferControl property equals LockStep, follow- When text encoding the protocol, the descriptors consist of session
ing detection of such an event, normal handling of events is suspended. descriptions as defined in SDP (RFC2327). In session descriptions
Any event which is subsequently detected and occurs in the EventBuffer sent from the MGC to the MG, the following exceptions to the syntax
Descriptor is added to the end of the EventBuffer (a FIFO queue), along of RFC 2327 are allowed:
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 "s=", "t=" and "o=" lines are optional,
the active EventsDescriptor. . 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.
In the case that an embedded EventsDescriptor being activated, the MG When multiple session descriptions are provided in one descriptor,
continues event processing based on the newly activated EventsDescriptor the "v=" lines are required as delimiters; otherwise they are
(Note - for purposes of EventBuffer handling, activation of an embedded optional in session descriptions sent to the MG. Implementations
EventsDescriptor is equivalent to receipt of a new EventsDescriptor). shall accept session descriptions that are fully conformant to
RFC2327. 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.
When the MG receives a command with a new EventsDescriptor, one or more Below, the semantics of the local and remote descriptors are
events may have been buffered in the EventBuffer in the MG. The value of specified in detail. The specification consists of two parts. The
EventBufferControl then determines how the MG treats such buffered 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.
Internet draft MEGACO Protocol February 21, 2000 Either the local or the remote descriptor or both may be
events. . unspecified (i.e., absent),
. empty,
. underspecified through use of CHOOSE in a property value,
. fully specified, or
. overspecified through presentation of multiple groups of
properties and possibly multiple property values in one or more
of these groups.
Case 1 Where the descriptors have been passed from the MGC to the MG, they
are interpreted according to the rules given in section 7.1.1, with
the following additional comments for clarification:
If EventBufferControl = LockStep and the MG receives a new (a) An unspecified Local or Remote descriptor is considered to be a
EventsDescriptor it will check the FIFO EventBuffer and take the follow- missing mandatory parameter. It requires the MG to use whatever was
ing actions: 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.
1. If the EventBuffer is empty, the MG waits for detection of events (b) An empty Local (Remote) descriptor in a message from the MGC
based on the new EventsDescriptor. signifies a request to release any resources reserved for the media
flow received (sent).
2. If the EventBuffer is non-empty, the MG processes the FIFO queue (c) If multiple groups of properties are present in a Local or Remote
starting with the first event: descriptor or multiple values within a group, the order of preference
is descending.
- If the event in the queue is in the events listed in the new (d) Underspecified or overspecified properties within a group of
EventsDescriptor, the default action of the MG is to send a Notify properties sent by the MGC are requests for the MG to choose one or
command to the MGC and remove the event from the EventBuffer. Any more values which it can support for each of those properties. In
other action is for further study. The time stamp of the Notify case of an overspecified property, the list of values is in
shall be the time the event was actually descending order of preference.
* detected. The MG then waits for a new EventsDescriptor. While Subject to the above rules, subsequent action depends on the values
waiting for a new EventsDescriptor, any events matching the of the ReserveValue and ReserveGroup properties in LocalControl.
EventsBufferDescriptor will be placed in the EventBuffer and the
event processing will repeat from step 1.
* If the event is not in the new EventsDescriptor, the MG SHALL dis- If ReserveGroup is true, the MG reserves the resources required to
card the event and repeat from step 1. 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.
Case 2 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 EventBufferControl equals Off and the MG receives a new If ReserveGroup is true or ReserveValue is true, then the following
EventsDescriptor, it processes new events with the new EventsDescriptor. rules apply.
If the MG receives a command instructing it to set the value of . If the MG has insufficient resources to support all alternatives
EventBufferControl to Off, all events in the EventBuffer SHALL be dis- requested by the MGC and the MGC requested resources in both
carded. Local and Remote, the MG should reserve resources to support at
least one alternative each within Local and Remote.
The MG may report several events in a single Transaction as long as this . If the MG has insufficient resources to support at least one
does not unnecessarily delay the reporting of individual events. alternative within a Local (Remote) descriptor received from
the MGC, it shall return an empty Local (Remote) in response.
For procedures regarding transmitting the Notify command, refer to the . In its response to the MGC, when the MGC included Local and
appropriate annex for specific transport considerations. 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.
The default value of EventBufferControl is Off. . If the Mode property of the LocalControl descriptor is RecvOnly
or SendRecv, the MG must be prepared to receive media encoded
according to any of the alternatives included in its response to
the MGC.
Note - Since the EventBufferControl property is in the TerminationSta- . If ReserveGroup is False and ReserveValue is false, then the MG
teDescriptor, the MG might receive a command that changes the EventBuf- SHOULD apply the following rules to resolve Local and Remote to a
ferControl property and does not include an EventsDescriptor. single alternative each:
Internet draft MEGACO Protocol February 21, 2000 . The MG chooses the first alternative in Local for which it is
able to support at least one alternative in Remote.
Normally, detection of an event shall cause any active signals to stop. . If the MG is unable to support at least one Local and one Remote
When KeepActive is specified in the event, the MG shall not interrupt alternative, it returns Error 510 (Insufficient Resources).
any signals active on the Termination on which the event is detected.
An event can include an Embedded Signals descriptor and/or an Embedded . The MG returns its selected alternative in each of Local and
Events Descriptor which, if present, replaces the current Signals/Events Remote.
descriptor when the event is detected. It is possible, for example, to
specify that the dial-tone Signal be generated when an off-hook Event is
detected, or that the dial-tone Signal be stopped when a digit is
detected. A media gateway controller shall not send EventsDescriptors
with an event both marked KeepActive and containing an embedded Sig-
nalsDescriptor.
Only one level of embedding is permitted. An embedded EventsDescriptor A new setting of a Local or Remote Descriptor completely replaces the
SHALL NOT contain another embedded EventsDescriptor; an embedded previous setting of that descriptor in the MG. Thus to retain
EventsDescriptor may contain an embedded SignalsDescriptor. 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.
An EventsDescriptor received by a media gateway replaces any previous 7.1.9 Events Descriptor
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.
7.1.10. EventBuffer 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 EventBuffer Descriptor contains a list of events, with their parame- Each event in the descriptor contains the Event name, an optional
ters if any, that the MG is requested to detect and buffer when streamID, an optional KeepActive flag, and optional parameters. The
EventBufferControl equals LockStep (see 7.1.9). 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.
7.1.11. Signals Descriptor The default action of the MG, when it detects an event in the Events
Descriptor, is to send a Notify command to the MG. Any other action
is for further study.
A SignalsDescriptor is a parameter that contains the set of signals that If the value of the EventBufferControl property equals LockStep,
the Media Gateway is asked to apply to a Termination. A SignalsDescrip- following detection of such an event, normal handling of events is
tor contains a number of signals and/or sequential signal lists. A Sig- suspended. Any event which is subsequently detected and occurs in the
nalsDescriptor may contain zero signals and sequential signal lists. EventBuffer Descriptor is added to the end of the EventBuffer (a FIFO
Support of sequential signal lists is optional. 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.
Signals are defined in packages. Signals shall be named with a Package If EventBufferControl equals Off, the MG continues processing based
name (in which the signal is defined) and a SignalID. No wildcard shall on the active EventsDescriptor.
be used in the SignalID. Signals that occur in a SignalsDescriptor have
an optional StreamID parameter (default is 0, to indicate that the sig-
nal 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 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 noti-
fied when the signal finishes playout. When the MGC enables the signal
completion event (see section E.1.2) in an Events Descriptor, that event
Internet draft MEGACO Protocol February 21, 2000 In the case that an embedded EventsDescriptor being activated, the MG
continues event processing based on the newly activated
EventsDescriptor (Note - for purposes of EventBuffer handling,
activation of an embedded EventsDescriptor is equivalent to receipt
of a new EventsDescriptor).
is detected whenever a signal terminates and "notifyCompletion" for that When the MG receives a command with a new EventsDescriptor, one or
signal is set to TRUE. The signal completion event of section E.1.2 has more events may have been buffered in the EventBuffer in the MG. The
a parameter that indicates how the signal terminated: it played to com- value of EventBufferControl then determines how the MG treats such
pletion, it was interrupted by an event, it was halted because a new buffered events.
SignalsDescriptor arrived, or the signal did not complete for some other
reason.
The duration is an integer value that is expressed in hundredths of a Case 1
second.
There are three types of signals: If EventBufferControl = LockStep and the MG receives a new
EventsDescriptor it will check the FIFO EventBuffer and take the
following actions:
* on/off - the signal lasts until it is turned off, 1. If the EventBuffer is empty, the MG waits for detection of events
based on the new EventsDescriptor.
* timeout - the signal lasts until it is turned off or a specific 2. If the EventBuffer is non-empty, the MG processes the FIFO queue
period of time elapses, starting with the first event:
* brief - the signal duration is so short that it will stop on its a) If the event in the queue is in the events listed in the new
own unless a new signal is applied that causes it to stop; no EventsDescriptor, the default action of the MG is to send a
timeout value is needed. Notify command to the MGC and remove the event from the
EventBuffer. Any other action is for further study. 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 matching the
EventsBufferDescriptor will be placed in the EventBuffer and
the event processing will repeat from step 1.
If the signal type is specified in a SignalsDescriptor, it overrides the b) If the event is not in the new EventsDescriptor, the MG
default signal type (see Section 12.1.4). If duration is specified for SHALL discard the event and repeat from step 1.
an on/off signal, it SHALL be ignored.
A sequential signal list consists of a signal list identifier, a Case 2
sequence of signals to be played sequentially, and a signal type. Only
the trailing element of the sequence of signals in a sequential signal
list may be an on/off signal. If the trailing element of the sequence
is an on/off signal, the signal type of the sequential signal list shall
be on/off as well. If the sequence of signals in a sequential signal
list contains signals of type timeout and the trailing element is not of
type on/off, the type of the sequential signal list SHALL be set to
timeout. The duration of a sequential signal list with type timeout is
the sum of the durations of the signals it contains. If the sequence of
signals in a sequential signal list contains only signals of type brief,
the type of the sequential signal list SHALL be set to brief. A signal
list is treated as a single signal of the specified type when played
out.
Multiple signals and sequential signal lists in the same SignalsDescrip- If EventBufferControl equals Off and the MG receives a new
tor shall be played simultaneously. EventsDescriptor, it processes new events with the new
EventsDescriptor.
Signals are defined as proceeding from the termination towards the exte- If the MG receives a command instructing it to set the value of
rior of the Context unless otherwise specified in a package. When the EventBufferControl to Off, all events in the EventBuffer SHALL be
same Signal is applied to multiple Terminations within one Transaction, discarded.
the MG should consider using the same resource to generate these Sig-
nals.
Internet draft MEGACO Protocol February 21, 2000 The MG may report several events in a single Transaction as long as
this does not unnecessarily delay the reporting of individual events.
Production of a Signal on a Termination is stopped by application of a For procedures regarding transmitting the Notify command, refer to
new SignalsDescriptor, or detection of an Event on the Termination (see the appropriate annex for specific transport considerations.
section 7.1.9).
A new SignalsDescriptor replaces any existing SignalsDescriptor. Any The default value of EventBufferControl is Off.
signals applied to the Termination not in the replacement descriptor
shall be stopped, and new signals are applied, except as follows. Sig-
nals present in the replacement descriptor and containing the KeepActive
flagshall 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 descrip-
tor, then
* the signal type and sequence of signals in the sequential signal Note - Since the EventBufferControl property is in the
list in the replacement descriptor shall be ignored, and TerminationStateDescriptor, the MG might receive a command that
changes the EventBufferControl property and does not include an
EventsDescriptor.
* the playing of the signals in the sequential signal list in the Normally, detection of an event shall cause any active signals to
existing descriptor shall not be interrupted. 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.
7.1.12. Audit Descriptor 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 detected. It is
possible, for example, to specify that the dial-tone Signal be
generated when an off-hook Event is detected, or that the dial-tone
Signal be stopped when a digit is detected. A media gateway
controller shall not send EventsDescriptors with an event both marked
KeepActive and containing an embedded SignalsDescriptor.
The Audit Descriptor specifies what information is to be audited. The Only one level of embedding is permitted. An embedded
Audit Descriptor specifies the list of descriptors to be returned. EventsDescriptor SHALL NOT contain another embedded EventsDescriptor;
Audit may be used in any command to force the return of a descriptor an embedded EventsDescriptor may contain an embedded
even if the descriptor in the command was not present, or had no under- SignalsDescriptor.
specified parameters. Possible items in the Audit Descriptor are:
________________ An EventsDescriptor received by a media gateway replaces any previous
| Modem | Events Descriptor. Event notification in process shall complete, and
|________________| events detected after the command containing the new EventsDescriptor
| Mux | executes, shall be processed according to the new EventsDescriptor.
|________________|
| Events |
|________________|
| Media |
|________________|
| Signals |
|________________|
| ObservedEvents |
|________________|
| DigitMap |
|________________|
| Statistics |
|________________|
| Packages |
Internet draft MEGACO Protocol February 21, 2000 7.1.10 EventBuffer Descriptor
|_______________| The EventBuffer Descriptor contains a list of events, with their
| EventBuffer | parameters if any, that the MG is requested to detect and buffer when
|_______________| EventBufferControl equals LockStep (see 7.1.9).
Audit may be empty, in which case, no descriptors are returned. This is 7.1.11 Signals Descriptor
useful in Subtract, to inhibit return of statistics, especially when
using wildcard.
7.1.13. ServiceChange Descriptor 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.
The ServiceChangeDescriptor contains the following parameters: 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
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. When the MGC enables the signal completion event
(see section E.1.2) in an Events Descriptor, that event is detected
whenever a signal terminates and "notifyCompletion" for that signal
is set to TRUE. The signal completion event of section E.1.2 has a
parameter that indicates how the signal terminated: it played to
completion, it was interrupted by an event, it was halted because a
new SignalsDescriptor arrived, or the signal did not complete for
some other reason.
* ServiceChangeMethod The duration is an integer value that is expressed in hundredths of a
second.
* ServiceChangeReason There are three types of signals:
* ServiceChangeAddress . 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 duration is so short that it will stop on its
own unless a new signal is applied that causes it to stop; no
timeout value is needed.
* ServiceChangeDelay If the signal type is specified in a SignalsDescriptor, it overrides
the default signal type (see Section 12.1.4). If duration is
specified for an on/off signal, it SHALL be ignored.
* ServiceChangeProfile A sequential signal list consists of a signal list identifier, a
sequence of signals to be played sequentially, and a signal type.
* ServiceChangeVersion Only the trailing element of the sequence of signals in a sequential
signal list may be an on/off signal. If the trailing element of the
sequence is an on/off signal, the signal type of the sequential
signal list shall be on/off as well. If the sequence of signals in a
sequential signal list contains signals of type timeout and the
trailing element is not of type on/off, the type of the sequential
signal list SHALL be set to timeout. The duration of a sequential
signal list with type timeout is the sum of the durations of the
signals it contains. If the sequence of signals in a sequential
signal list contains only signals of type brief, the type of the
sequential signal list SHALL be set to brief. A signal list is
treated as a single signal of the specified type when played out.
* ServiceChangeMGCId Multiple signals and sequential signal lists in the same
SignalsDescriptor shall be played simultaneously.
* TimeStamp Signals are defined as proceeding from the termination towards the
exterior of the Context unless otherwise specified in a package.
When the same Signal is applied to multiple Terminations within one
Transaction, the MG should consider using the same resource to
generate these Signals.
See section 7.2.8 Production of a Signal on a Termination is stopped by application of
a new SignalsDescriptor, or detection of an Event on the Termination
(see section 7.1.9).
7.1.14. DigitMap Descriptor 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 flagshall 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
A DigitMap is a dialing plan resident in the Media Gateway used for . the signal type and sequence of signals in the sequential signal
detecting and reporting digit events received on a Termination. The list in the replacement descriptor shall be ignored, and
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 dynami-
cally 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 com-
mand, regardless of the transmitted order of the respective descriptors.
DigitMaps defined in a DigitMapDescriptor can occur in any of the stan- . the playing of the signals in the sequential signal list in the
dard Termination manipulation Commands of the protocol. A DigitMap, existing descriptor shall not be interrupted.
once defined, can be used on all Terminations specified by the (possibly
wildcarded) TerminationID in such a command. DigitMaps defined on the
Internet draft MEGACO Protocol February 21, 2000 7.1.12 Audit Descriptor
root Termination are global and can be used on every Termination in the The Audit Descriptor specifies what information is to be audited.
MG, provided that a DigitMap with the same name has not been defined on The Audit Descriptor specifies the list of descriptors to be
the given Termination. When a DigitMap is defined dynamically in a returned. Audit may be used in any command to force the return of a
DigitMap Descriptor: descriptor even if the descriptor in the command was not present, or
had no underspecified parameters. Possible items in the Audit
Descriptor are:
* A new DigitMap is created by specifying a name that is not yet Modem
defined. The value shall be present. Mux
Events
Media
Signals
ObservedEvents
DigitMap
Statistics
Packages
EventBuffer
* A DigitMap value is updated by supplying a new value for a name Audit may be empty, in which case, no descriptors are returned. This
that is already defined. Terminations presently using the digitmap is useful in Subtract, to inhibit return of statistics, especially
shall continue to use the old definition; subsequent EventsDescrip- when using wildcard.
tors 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 7.1.13 ServiceChange Descriptor
is already defined. Terminations presently using the digitmap shall
continue to use the old definition.
The collection of digits according to a DigitMap may be protected by The ServiceChangeDescriptor contains the following parameters:
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. . ServiceChangeMethod
. ServiceChangeReason
. ServiceChangeAddress
. ServiceChangeDelay
. ServiceChangeProfile
. ServiceChangeVersion
. ServiceChangeMGCId
. TimeStamp
2. If the Media Gateway can determine that at least one more digit is See section 7.2.8.
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, 7.1.14 DigitMap Descriptor
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. The Start timer A DigitMap is a dialing plan resident in the Media Gateway used for
is started at the beginning of every digit map use, but can be overrid- detecting and reporting digit events received on a Termination. The
den. 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.
The formal syntax of the digit map is described by the DigitMap rule in DigitMaps defined in a DigitMapDescriptor can occur in any of the
the formal syntax description of the protocol (see Annex A and Annex B). standard Termination manipulation Commands of the protocol. A
A DigitMap, according to this syntax, is defined either by a string or DigitMap, once defined, can be used on all Terminations specified by
by a list of strings. Each string in the list is an alternative event the (possibly wildcarded) TerminationID in such a command. DigitMaps
sequence, specified either as a sequence of digit map symbols or as a defined on the root Termination are global and can be used on every
regular expression of digit map symbols. These digit map symbols, the Termination in the MG, provided that a DigitMap with the same name
digits "0" through "9" and letters "A" through a maximum value depending has not been defined on the given Termination. When a DigitMap is
on the signalling system concerned, but never exceeding "K", correspond defined dynamically in a DigitMap Descriptor:
Internet draft MEGACO Protocol February 21, 2000 . A new DigitMap is created by specifying a name that is not yet
defined. The value shall be present.
to specified events within a package which has been designated in the . A DigitMap value is updated by supplying a new value for a name
Events Descriptor on the termination to which the digit map is being that is already defined. Terminations presently using the
applied. (The mapping between events and digit map symbols is defined digitmap shall continue to use the old definition; subsequent
in the documentation for packages associated with channel-associated EventsDescriptors specifying the name, including any
signalling systems such as DTMF, MF, or R2. Digits "0" through "9" MUST EventsDescriptor in the command containing the DigitMap
be mapped to the corresponding digit events within the signalling system descriptor, shall use the new one.
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 correspond- . A DigitMap is deleted by supplying an empty value for a name that
ing to symbols in the range "0"-"9". The string may also contain expli- is already defined. Terminations presently using the digitmap
cit ranges and, more generally, explicit sets of symbols, designating shall continue to use the old definition.
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 the dot symbol uses the
short timer by default.
In addition to these event symbols, the string may contain "S" and "L" The collection of digits according to a DigitMap may be protected by
inter-event timing specifiers and the "Z" duration modifier. "S" and three timers, viz. a start timer (T), short timer (S), and long timer
"L" respectively indicate that the MG should use the short (S) timer or (L).
the long (L) timer for subsequent events, over-riding the timing rules
described above. A timer specifier following a dot specifies inter-event
timing for all events matching the dot as well as for subsequent events.
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 con-
flicting timing specifiers are in effect in different alternative
sequences, the results are undefined.
A "Z" designates a long duration event: placed in front of the symbol(s) 1. The start timer (T) is used prior to any digits having been
designating the event(s) which satisfy a given digit position, it indi- dialed.
cates 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. 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 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).
* an alternative event sequence has been matched and no other alter- 3. If the digit string has matched one of the patterns in a digit
native event sequence in the digit map could be matched through map, but it is possible that more digits could be received which
detection of an additional event (unambiguous match), or 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.
* an event has been detected such that a match to a complete The timers are configurable parameters to a DigitMap. The Start
timer is started at the beginning of every digit map use, but can be
overridden.
Internet draft MEGACO Protocol February 21, 2000 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
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.)
alternative event sequence of the digit map will be impossible no The letter "x" is used as a wildcard, designating any event
matter what additional events are received. 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 the dot symbol uses the short timer by default.
Upon completion, a digit map completion event as defined in the package In addition to these event symbols, the string may contain "S" and
providing the events being mapped into the digit map shall be generated. "L" inter-event timing specifiers and the "Z" duration modifier. "S"
At that point the digit map is deactivated. Subsequent events in the and "L" respectively indicate that the MG should use the short (S)
package are processed as per the currently active event processing timer or the long (L) timer for subsequent events, over-riding the
mechanisms. timing rules described above. A timer specifier following a dot
specifies inter-event timing for all events matching the dot as well
as for subsequent events. 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 results are
undefined.
Pending completion, successive events shall be processed according to A "Z" designates a long duration event: placed in front of the
the following rules: 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.
1. The "current dial string", an internal variable, is initially A digit map is active while the events descriptor which invoked it is
empty. The set of candidate alternative event sequences includes active and it has not completed. A digit map completes when:
all of the alternatives specified in the digit map.
2. At each step, a timer is set to wait for the next event, based . a timer has expired, or
either on the default timing rules given above or on explicit tim-
ing 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 . an alternative event sequence has been matched and no other
digit string symbol and provisionally added to the end of the alternative event sequence in the digit map could be matched
current dial string. The duration of the event (long or not long) through detection of an additional event (unambiguous match), or
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 . an event has been detected such that a match to a complete
event sequences. If and only if a sequence expecting a long- alternative event sequence of the digit map will be impossible no
duration event at this position is matched (i.e. the event had long matter what additional events are received.
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 modi-
fied 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 position remain in the candidate
set after application of the above rules, the observed event dura-
tion is treated as irrelevant in assessing matches to them. If
exactly one candidate remains, 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
Internet draft MEGACO Protocol February 21, 2000 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.
completion event is generated indicating full match if one of the Pending completion, successive events shall be processed according to
candidates from the previous step was fully satisfied before the the following rules:
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.
5. If no completion event is reported out of step 5 (because the can- 1. The "current dial string", an internal variable, is initially
didate set still contains more than one alternative event empty. The set of candidate alternative event sequences includes
sequence), processing returns to step 2. A digit map is activated all of the alternatives specified in the digit map.
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 which itself contains a digit
map parameter. Each new activation of a digit map begins at step 1
of the above procedure, with a clear current dial string. Any pre-
vious contents of the current dial string from an earlier activa-
tion are lost. While the digit map is activated, detection is
enabled for all events defined in the package containing the speci-
fied 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. 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 if the event includes a digit map
parameter. Regardless of whether a digit map is activated, this
form of event specification will cause the individual events to be
reported to the MGC as they are detected.
As an example, consider the following dial plan: 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
| 0 | Local operator | a digit string symbol and provisionally added to the end of the
| 00 | Long distance operator | current dial string. The duration of the event (long or not long)
| xxxx | Local extension number(starts with 1-7)| is noted if and only if this is relevant in the current symbol
| 8xxxxxxx | Local number | position (because at least one of the candidate alternative event
| #xxxxxxx | Off-site extension | sequences includes the "Z" modifier at this position in the
| *xx | Star services | sequence).
| 91xxxxxxxxxx | Long distance number |
| 9011 + up to 15 digits | International number |
|__________________________|_________________________________________|
If the DTMF detection package described in Annex E (section E.6) is used 4. The current dial string is compared to the candidate alternative
to collect the dialled digits, then the dialling plan shown above event sequences. If and only if a sequence expecting a long-
results in the following digit map: 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 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.
Internet draft MEGACO Protocol February 21, 2000 5. If exactly one candidate remains, 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.
(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.) 6. If no completion event is reported out of step 5 (because the
candidate set still contains more than one alternative event
sequence), processing returns to step 2.
7.1.15. Statistics Descriptor 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 which
itself contains a digit map parameter. 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. 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.
The Statistics parameter provides information describing the status and Note that if a package contains a digit map completion event, then an
usage of a Termination during its existence within a specific Context. event specification consisting of the package name with a wildcarded
There is a set of standard statistics kept for each termination where ItemID (Property Name) will activate a digit map if the event
appropriate (number of octets sent and received for example). The par- includes a digit map parameter. Regardless of whether a digit map is
ticular statistical properties that are reported for a given Termination activated, this form of event specification will cause the individual
are determined by the Packages realized by the Termination. By default, events to be reported to the MGC as they are detected.
statistics are reported when the Termination is Subtracted from the Con-
text. This behavior can be overridden by including an empty Audit-
Descriptor 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. As an example, consider the following dial plan:
Statistics are reset when a Termination is Subtracted from a Context.
7.1.16. Packages Descriptor 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
Used only with the AuditValue command, the PackageDescriptor returns a If the DTMF detection package described in Annex E (section E.6) is
list of Packages realized by the Termination. used to collect the dialled digits, then the dialling plan shown
above results in the following digit map:
7.1.17. ObservedEvents Descriptor (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)
ObservedEvents is supplied with the Notify command to inform the MGC of 7.1.15 Statistics Descriptor
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
and the detection time(s). Detection times are reported with a precision
of hundredths of a second. Time is expressed in UTC.
7.1.18. Topology Descriptor The Statistics parameter 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
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 behavior 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.
A topology descriptor is used to specify flow directions between termi- Statistics are cumulative; reporting Statistics does not reset them.
nations in a Context. Contrary to the descriptors in previous sections, Statistics are reset when a Termination is Subtracted from a Context.
the topology descriptor applies to a Context instead of a Termination.
The default topology of a Context is that each termination's transmis-
sion is received by all other terminations. The Topology Descriptor is
optional to implement.
The Topology Descriptor occurs before the commands in an action. It is 7.1.16 Packages Descriptor
possible to have an action containing only a Topology Descriptor, pro-
vided that the context to which the action applies already exists.
A topology descriptor consists of a sequence of triples of the form (T1, Used only with the AuditValue command, the PackageDescriptor returns
a list of Packages realized by the Termination.
Internet draft MEGACO Protocol February 21, 2000 7.1.17 ObservedEvents Descriptor
T2, association). T1 and T2 specify Terminations within the Context, ObservedEvents is supplied with the Notify command to inform the MGC
possibly using the ALL or CHOOSE wildcard. The association specifies of which event(s) were detected. Used with the AuditValue command,
how media flows between these two Terminations as follows. 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 and the detection time(s). Detection times are reported
with a precision of hundredths of a second. Time is expressed in
UTC.
* (T1, T2, isolate) means that the Terminations matching T2 do not 7.1.18 Topology Descriptor
receive media from the Terminations matching T1, nor vice versa.
* (T1, T2, oneway) means that the Terminations that match T2 receive A topology descriptor is used to specify flow directions between
media from the Terminations matching T1, but not vice versa. In terminations in a Context. Contrary to the descriptors in previous
this case use of the ALL wildcard such that there are Terminations sections, the topology descriptor applies to a Context instead of a
that match both T1 and T2 is not allowed. 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.
* (T1, T2, bothway) means that the Terminations matching T2 receive The Topology Descriptor occurs before the commands in an action. It
media from the Terminations matching T1, and vice versa. In this is possible to have an action containing only a Topology Descriptor,
case it is allowed to use wildcards such that there are Termina- provided that the context to which the action applies already exists.
tions that match both T1 and T2. However, if there is a Termina-
tion that matches both, no loopback is introduced; loopbacks are
created by setting the TerminationMode.
CHOOSE wildcards may be used in T1 and T2 as well, under the following A topology descriptor consists of a sequence of triples of the form
restrictions: (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.
* the action (see section 8) of which the topology descriptor is part . (T1, T2, isolate) means that the Terminations matching T2 do not
contains an Add command in which a CHOOSE wildcard is used; receive media from the Terminations matching T1, nor vice versa.
* if a CHOOSE wildcard occurs in T1 or T2, then a partial name SHALL . (T1, T2, oneway) means that the Terminations that match T2
NOT be specified. The CHOOSE wildcard in a topology descriptor receive media from the Terminations matching T1, but not vice
matches the TerminationID that the MG assigns in the first Add com- versa. In this case use of the ALL wildcard such that there are
mand that uses a CHOOSE wildcard in the same action. An existing Terminations that match both T1 and T2 is not allowed.
Termination that matches T1 or T2 in the Context to which a Termi-
nation is added, is connected to the newly added Termination as
specified by the topology descriptor. The default association when
a termination is not mentioned in the Topology descriptor is both-
way (if T3 is added to a context with T1 and T2 with topology
(T3,T1,oneway) it will be connected bothway to T2).
The figure below and the table following it show some examples of the . (T1, T2, bothway) means that the Terminations matching T2 receive
effect of including topology descriptors in actions. In these examples media from the Terminations matching T1, and vice versa. In this
it is assumed that the topology descriptors are applied in sequence. 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;
loopbacks are created by setting the TerminationMode. CHOOSE
wildcards may be used in T1 and T2 as well, under the following
restrictions:
Internet draft MEGACO Protocol February 21, 2000 . the action (see section 8) of which the topology descriptor is
part contains an Add command in which a CHOOSE wildcard is used;
Context 1 Context 2 Context 3 . if a CHOOSE wildcard occurs in T1 or T2, then a partial name
+------------------+ +------------------+ +------------------+ SHALL NOT be specified.
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| ^ ^ | | ^ | | ^ |
| | | | | | | | | |
| +--+ +--+ | | +---+ | | +--+ |
| | | | | | | | | |
| v v | | v | | | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway
Context 1 Context 2 Context 3
+------------------+ +------------------+ +------------------+ The CHOOSE wildcard in a topology descriptor matches the
| +----+ | | +----+ | | +----+ | TerminationID that the MG assigns in the first Add command that uses
| | T2 | | | | T2 | | | | T2 | | 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. The default association when a termination is not
| +--+ | | +---+ | | +--+ +--+ | mentioned in the Topology descriptor is bothway (if T3 is added to a
| | | | | | | | | | context with T1 and T2 with topology (T3,T1,oneway) it will be
| v | | v | | v v | connected bothway to T2).
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. T2, T3 oneway 2. T2, T3 bothway 3. T1, T2 bothway
Figure 4: Example topologies The figure below 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.
Internet draft MEGACO Protocol February 21, 2000 Context 1 Context 2 Context 3
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| ^ ^ | | ^ | | ^ |
| | | | | | | | | |
| +--+ +--+ | | +---+ | | +--+ |
| | | | | | | | | |
| v v | | v | | | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway
_______________________________________________________________________ Context 1 Context 2 Context 3
|Topology | Description | +------------------+ +------------------+ +------------------+
|_________|____________________________________________________________| | +----+ | | +----+ | | +----+ |
|1 |No topology descriptors. When no topology descriptors are | | | T2 | | | | T2 | | | | T2 | |
| |included, all terminations have a both way connection to all| | +----+ | | +----+ | | +----+ |
| |other terminations. | | | | | ^ | | ^ ^ |
|_________|____________________________________________________________| | | | | | | | | | |
|2 |T1, T2, Isolate. Removes the connection between T1 and T2. | | +--+ | | +---+ | | +--+ +--+ |
| |T3 has a both way connection with both T1 and T2. | | | | | | | | | | |
|_________|____________________________________________________________| | v | | v | | v v |
|3 |T3, T2, oneway. A oneway connection from T3 to T2 (i.e. T2 | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| |receives media flow from T3). A bothway connection between | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| |T1 and T3. | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
|_________|____________________________________________________________| +------------------+ +------------------+ +------------------+
|4 |T2, T3, oneway. A oneway connection between T2 to T3. | 4. T2, T3 oneway 5. T2, T3 bothway 6. T1, T2 bothway
| |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 bothway and T1,T3 bothway may be |
| |implied or explicit). terminations have a bothway |
|_________|____________________________________________________________|
A oneway connection must implemented in such a way that the other Termi- Figure 4: A Sequence Of Example Topologies
nations in the Context are not aware of the change in topology. Topology Description
7.2. Command Application Programming Interface 1 No topology descriptors
When no topology descriptors are included, all
terminations have a both way connection to all
other terminations.
Following is an Application Programming Interface (API) describing the 2 T1, T2, Isolate
Commands of the protocol. This API is shown to illustrate the Commands Removes the connection between T1 and T2.
and their parameters and is not intended to specify implementation (e.g. T3 has a both way connection with both T1 and
via use of blocking function calls). It describes the input parameters T2. T1 and T2 have bothway connection to T3.
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 specified in later subsections. All parameters
enclosed by square brackets ([. . . ]) are considered optional.
7.2.1. Add 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.
TerminationID 4 T2, T3, oneway
[,MediaDescriptor] A oneway connection between T2 to T3.
[,ModemDescriptor] T1 and T3 remain bothway connected
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
Internet draft MEGACO Protocol February 21, 2000 5 T2, T3 bothway
T2 is bothway connected to T3. This results in
the same as 2.
[,DigitMapDescriptor] 6 T1, T2 bothway (T2, T3 bothway
[,ObservedEventsDescriptor] and T1,T3 bothway may be implied
[,EventBufferDescriptor] or explicit).
[,StatisticsDescriptor] All terminations have a bothway connection to
[,PackagesDescriptor] all other terminations.
Add( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
The TerminationID specifies the termination to be added to the Context. A oneway connection must implemented in such a way that the other
The Termination is either created, or taken from the null Context. For Terminations in the Context are not aware of the change in topology.
an existing Termination, the TerminationID would be specific. For a
Termination that does not yet exist, the TerminationID is specified as
CHOOSE in the command. The new TerminationID will be returned. Wild-
cards 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. 7.2 Command Application Programming Interface
The optional ModemDescriptor and MuxDescriptor specify a modem and mul- Following is an Application Programming Interface (API) describing
tiplexer if applicable. For convenience, if a Multiplex Descriptor is the Commands of the protocol. This API is shown to illustrate the
present in an Add command and lists any Terminations that are not Commands and their parameters and is not intended to specify
currently in the Context, such Terminations are added to the context as implementation (e.g. via use of blocking function calls). It
if individual Add commands listing the Terminations were invoked. If an describes the input parameters in parentheses after the command name
error occurs on such an implied Add, error 471 - Implied Add for Multi- and the return values in front of the Command. This is only for
plex failure shall be returned and further processing of the command descriptive purposes; the actual Command syntax and encoding are
shall cease. specified in later subsections. All parameters enclosed by square
brackets ([. . . ]) are considered optional.
The EventsDescriptor parameter is optional. If present, it provides the 7.2.1 Add
list of events that should be detected on the Termination.
The SignalsDescriptor parameter is optional. If present, it provides The Add Command adds a Termination to a Context.
the list of signals that should be applied to the Termination.
The DigitMapDescriptor parameter is optional. If present, defines a TerminationID
DigitMap definition that may be used in an EventsDescriptor. [,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Add( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
The AuditDescriptor is optional. If present, the command will return The TerminationID specifies the termination to be added to the
descriptors as specified in the AuditDescriptor. Context. The Termination is either created, or taken from the null
Context. For an existing Termination, the TerminationID would be
specific. For a Termination that does not yet exist, the
TerminationID is specified as CHOOSE in the command. The new
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.
Internet draft MEGACO Protocol February 21, 2000 The optional MediaDescriptor describes all media streams.
All descriptors that can be modified could be returned by MG if a param- The optional ModemDescriptor and MuxDescriptor specify a modem and
eter was underspecified or overspecified. ObservedEvents, Statistics, multiplexer if applicable. For convenience, if a Multiplex Descriptor
and Packages, and the EventBuffer Descriptors are returned only if is present in an Add command and lists any Terminations that are not
requested in the AuditDescriptor. Add SHALL NOT be used on a Termina- currently in the Context, such Terminations are added to the context
tion with a serviceState of "OutofService". 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.
7.2.2. Modify The EventsDescriptor parameter is optional. If present, it provides
the list of events that should be detected on the Termination.
TerminationID The SignalsDescriptor parameter is optional. If present, it provides
[,MediaDescriptor] the list of signals that should be applied to the Termination.
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Modify( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
The TerminationID may be specific if a single Termination in the Context The DigitMapDescriptor parameter is optional. If present, defines a
is to be modified. Use of wildcards in the TerminationID may be DigitMap definition that may be used in an EventsDescriptor.
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.
The remaining parameters to Modify are the same as those to Add. Possi- The AuditDescriptor is optional. If present, the command will return
ble return values are the same as those to Add. descriptors as specified in the AuditDescriptor.
7.2.3. Subtract 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".
The Subtract Command disconnects a Termination from its Context and 7.2.2 Modify
returns statistics on the Termination's participation in the Context.
TerminationID The Modify Command modifies the properties of a Termination.
Internet draft MEGACO Protocol February 21, 2000 TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Modify( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
[,MediaDescriptor] The TerminationID may be specific if a single Termination in the
[,ModemDescriptor] Context is to be modified. Use of wildcards in the TerminationID may
[,MuxDescriptor] be appropriate for some operations. If the wildcard matches more than
[,EventsDescriptor] one TerminationID, all possible matches are attempted, with results
[,SignalsDescriptor] reported for each one. The order of attempts when multiple
[,DigitMapDescriptor] TerminationIDs match is not specified. The CHOOSE option is an error,
[,ObservedEventsDescriptor] as the Modify command may only be used on existing Terminations.
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Subtract(TerminationID
[, AuditDescriptor]
)
TerminationID in the input parameters represents the Termination that is The remaining parameters to Modify are the same as those to Add.
being subtracted. The TerminationID may be specific or may be a wild- Possible return values are the same as those to Add.
card 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 CHOOSE option 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.
By default, the Statistics parameter is returned to report information 7.2.3 Subtract
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 The Subtract Command disconnects a Termination from its Context and
descriptors as specified in the AuditDescriptor. Possible return returns statistics on the Termination's participation in the Context.
values are the same as those to Add.
When a provisioned Termination is Subtracted from a context, its pro- TerminationID
perty values shall revert to: [,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Subtract(TerminationID
[, AuditDescriptor]
)
* the default value, if specified for the property and not overridden TerminationID in the input parameters represents the Termination that
by provisioning, 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
CHOOSE option 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.
* otherwise, the provisioned value. 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.
7.2.4. Move The AuditDescriptor is optional. If present, the command will return
descriptors as specified in the AuditDescriptor. Possible return
values are the same as those to Add.
The Move Command moves a Termination to another Context from its current When a provisioned Termination is Subtracted from a context, its
property values shall revert to:
Internet draft MEGACO Protocol February 21, 2000 . the default value, if specified for the property and not
overridden by provisioning,
. otherwise, the provisioned value.
Context in one atomic operation. The Move command is the only command 7.2.4 Move
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 Ter-
minations to or from the null Context.
TerminationID The Move Command moves a Termination to another Context from its
[,MediaDescriptor] current Context in one atomic operation. The Move command is the
[,ModemDescriptor] only command that refers to a Termination in a Context different from
[,MuxDescriptor] that to which the command is applied. The Move command shall not be
[,EventsDescriptor] used to move Terminations to or from the null Context.
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Move( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
The TerminationID specifies the Termination to be moved. It may be TerminationID
wildcarded. If the wildcard matches more than one TerminationID, all [,MediaDescriptor]
possible matches are attempted, with results reported for each one. The [,ModemDescriptor]
order of attempts when multiple TerminationIDs match is not specified. [,MuxDescriptor]
By convention, the Termination is subtracted from its previous Context. [,EventsDescriptor]
The Context to which the Termination is moved is indicated by the target [,SignalsDescriptor]
ContextId in the Action. If the last remaining Termination is moved out [,DigitMapDescriptor]
of a Context, the Context is deleted. [,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Move( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
The remaining descriptors are processed as in the Modify Command. The The TerminationID specifies the Termination to be moved. It may be
AuditDescriptor with the Statistics option, for example, would return wildcarded. If the wildcard matches more than one TerminationID, all
statistics on the Termination just prior to the Move. Possible descrip- possible matches are attempted, with results reported for each one.
tors returned from Move are the same as for Add. Move SHALL NOT be used The order of attempts when multiple TerminationIDs match is not
on a Termination with a serviceState of "OutofService". specified. By convention, the Termination is subtracted from its
previous Context. 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.
7.2.5. AuditValue The remaining descriptors are processed as in the Modify 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.
Move SHALL NOT be used on a Termination with a serviceState of
"OutofService".
The AuditValue Command returns the current values of properties, events, 7.2.5 AuditValue
signals and statistics associated with Terminations.
Internet draft MEGACO Protocol February 21, 2000 The AuditValue Command returns the current values of properties,
events, signals and statistics associated with Terminations.
TerminationID TerminationID
[,MediaDescriptor] [,MediaDescriptor]
[,ModemDescriptor] [,ModemDescriptor]
[,MuxDescriptor] [,MuxDescriptor]
[,EventsDescriptor] [,EventsDescriptor]
[,SignalsDescriptor] [,SignalsDescriptor]
[,DigitMapDescriptor] [,DigitMapDescriptor]
[,ObservedEventsDescriptor] [,ObservedEventsDescriptor]
[,EventBufferDescriptor] [,EventBufferDescriptor]
[,StatisticsDescriptor] [,StatisticsDescriptor]
[,PackagesDescriptor] [,PackagesDescriptor]
AuditValue(TerminationID, AuditValue(TerminationID,
AuditDescriptor AuditDescriptor
) )
TerminationID may be specific or wildcarded. If the wildcard matches TerminationID may be specific or wildcarded. If the wildcard matches
more than one TerminationID, all possible matches are attempted, with more than one TerminationID, all possible matches are attempted, with
results reported for each one. The order of attempts when multiple Ter- results reported for each one. The order of attempts when multiple
minationIDs match is not specified. If a wildcarded response is TerminationIDs match is not specified. If a wildcarded response is
requested, only one command return is generated, with the contents con- requested, only one command return is generated, with the contents
taining the union of the values of all Terminations matching the wild- containing the union of the values of all Terminations matching the
card. This convention may reduce the volume of data required to audit a wildcard. This convention may reduce the volume of data required to
group of Terminations. Use of CHOOSE is an error. audit a group of Terminations. Use of CHOOSE is an error.
The appropriate descriptors, with the current values for the Termina-
tion, 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, Packages-
Descriptor 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 Ter-
minationID 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.
AuditValue results depend on the Context, viz. specific, null, or wild-
carded. The TerminationID may be specific, or wildcarded.
The following illustrates other information that can be obtained with The appropriate descriptors, with the current values for the
the Audit Command: 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,
|ContextID |TerminationID| Information Obtained | 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.
Internet draft MEGACO Protocol February 21, 2000 AuditValue results depend on the Context, viz. specific, null, or
wildcarded. The TerminationID may be specific, or wildcarded. The
following illustrates other information that can be obtained with the
Audit Command:
|Specific | wildcard |Audit of matching Terminations in a Context| ContextID TerminationID Information Obtained
|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 |
|____________|_____________|___________________________________________|
7.2.6. AuditCapabilities Specific wildcard Audit of matching
Terminations in a Context
The AuditCapabilities Command returns the possible values of properties, Specific specific Audit of a single
events, signals and statistics associated with Terminations. Termination in a Context
TerminationID Null Root Audit of Media Gateway state
[,MediaDescriptor] and events
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
AuditCapabilities(TerminationID,
AuditDescriptor)
The appropriate descriptors, with the possible values for the Termina- Null wildcard Audit of all matching
tion are returned from AuditCapabilities. Descriptors may be repeated Terminations in the Null
where there are multiple possible values. values. If a wildcarded Context
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 Null specific Audit of a single
ContextID and TerminationID is the same as in AuditValue. Termination outside of any
Context
The EventsDescriptor returns the list of possible events on the Termina- All wildcard Audit of all matching
tion together with the list of all possible values for the Terminations and the Context
EventsDescriptor Parameters. The SignalsDescriptor returns the list of to which they are associated
possible signals that could be applied to the Termination together with
the list of all possible values for the Signals Parameters. Statis-
ticsDescriptor returns the names of the statistics being kept on the
Internet draft MEGACO Protocol February 21, 2000 All Root List of all ContextIds
termination. ObservedEventsDescriptor returns the names of active 7.2.6 AuditCapabilities
events on the termination. DigitMap and Packages are not legal in
AuditCapability
7.2.7. Notify The AuditCapabilities Command returns the possible values of
properties, events, signals and statistics associated with
Terminations.
The Notify Command allows the Media Gateway to notify the Media Gateway TerminationID
Controller of events occurring within the Media Gateway. [,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
Notify(TerminationID, [,StatisticsDescriptor]
ObservedEventsDescriptor, AuditCapabilities(TerminationID,
[ErrorDescriptor]) AuditDescriptor
)
The TerminationID parameter specifies the Termination issuing the Notify The appropriate descriptors, with the possible values for the
Command. The TerminationID shall be a fully qualified name. 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.
The ObservedEventsDescriptor contains the RequestID and a list of events Interpretation of what capabilities are requested for various values
that the Media Gateway detected in the order that they were detected. of ContextID and TerminationID is the same as in AuditValue.
Each event in the list is accompanied by parameters associated with the
event and an indication of the time that the event was detected. Pro-
cedures 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 The EventsDescriptor returns the list of possible events on the
result of detection of an event specified by an Events Descriptor which Termination together with the list of all possible values for the
is active on the termination concerned. The RequestID returns the EventsDescriptor Parameters. The SignalsDescriptor returns the list
RequestID parameter of the EventsDescriptor that triggered the Notify of possible signals that could be applied to the Termination together
Command. It is used to correlate the notification with the request that with the list of all possible values for the Signals Parameters.
triggered it. The events in the list must have been requested via the StatisticsDescriptor returns the names of the statistics being kept
triggering EventsDescriptor or embedded events descriptor unless the on the termination. ObservedEventsDescriptor returns the names of
RequestID is 0 (which is for further study). active events on the termination. DigitMap and Packages are not
legal in AuditCapability.
7.2.8. ServiceChange 7.2.7 Notify
The ServiceChange Command allows the Media Gateway to notify the Media The Notify Command allows the Media Gateway to notify the Media
Gateway Controller that a Termination or group of Terminations is about Gateway Controller of events occurring within the Media Gateway.
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, Notify(TerminationID,
[ServiceChangeDescriptor] ObservedEventsDescriptor,
ServiceChange(TerminationID, [ErrorDescriptor]
ServiceChangeDescriptor
) )
Internet draft MEGACO Protocol February 21, 2000 The TerminationID parameter specifies the Termination issuing the
Notify Command. The TerminationID shall be a fully qualified name.
The TerminationID parameter specifies the Termination(s) that are taken
out of or returned to service. Wildcarding of Termination names is per-
mitted, 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 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 an indication of the time that the
event was detected. Procedures for sending Notify commands with
RequestID equal to 0 are for further study.
* ServiceChangeDelay 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.
* ServiceChangeAddress 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).
* ServiceChangeProfile 7.2.8 ServiceChange
* ServiceChangeVersion 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.
* ServiceChangeMgcId TerminationID,
[ServiceChangeDescriptor]
ServiceChange(TerminationID,
ServiceChangeDescriptor
)
* TimeStamp 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 ServiceChangeMethod parameter specifies the type of ServiceChange The ServiceChangeDescriptor contains the following parameters as
that will or has occurred: required:
1) Graceful - indicates that the specified Terminations will be taken . ServiceChangeMethod
out of service after the specified ServiceChangeDelay; established . ServiceChangeReason
connections are not yet affected, but the Media Gateway Controller . ServiceChangeDelay
should refrain from establishing new connections and should attempt . ServiceChangeAddress
to gracefully tear down existing connections. The MG should set . ServiceChangeProfile
termination serviceState at the expiry of ServiceChangeDelay or the . ServiceChangeVersion
removal of the termination from an active context (whichever is . ServiceChangeMgcId
first), to "out of service". . TimeStamp
2) Forced - indicates that the specified Terminations were taken The ServiceChangeMethod parameter specifies the type of ServiceChange
abruptly out of service and any established connections associated that will or has occurred:
with them were lost. 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".
3) Restart - indicates that service will be restored on the specified 1) Graceful - indicates that the specified Terminations will be taken
Terminations after expiration of the ServiceChangeDelay. The ser- out of service after the specified ServiceChangeDelay; established
viceState should be set to "inService" upon expiry of Servi- connections are not yet affected, but the Media Gateway Controller
ceChangeDelay. should refrain from establishing new connections and should
attempt to gracefully tear down existing connections. 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".
Internet draft MEGACO Protocol February 21, 2000 2) Forced - indicates that the specified Terminations were taken
abruptly out of service and any established connections associated
with them were lost. 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".
4) Disconnected - always applied with the Root TerminationID, indi- 3) Restart - indicates that service will be restored on the specified
cates that the MG lost communication with the MGC, but it was sub- Terminations after expiration of the ServiceChangeDelay. The
sequently restored. Since MG state may have changed, the MGC may serviceState should be set to "inService" upon expiry of
wish to use the Audit command to resynchronize its state with the ServiceChangeDelay.
MG's.
5) Handoff - sent from the MGC to the MG, this reason indicates that 4) Disconnected - always applied with the Root TerminationID,
the MGC is going out of service and a new MGC association must be indicates that the MG lost communication with the MGC, but it was
established. Sent from the MG to the MGC, this indicates that the subsequently restored. Since MG state may have changed, the MGC
MG is attempting to establish a new association in accordance with may wish to use the Audit command to resynchronize its state with
a Handoff received from the MGC with which it was previously asso- the MG's.
ciated.
6) Failover - sent from MG to MGC to indicate the primary MG is out of 5) Handoff - sent from the MGC to the MG, this reason indicates that
service and a secondary MG is taking over. 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.
7) Another value whose meaning is mutually understood between the MG 6) Failover - sent from MG to MGC to indicate the primary MG is out
and the MGC. The ServiceChangeReason parameter specifies the rea- of service and a secondary MG is taking over.
son why the ServiceChange has or will occur. It consists of an
alphanumeric token (IANA registered) and an explanatory string.
The optional ServiceChangeAddress parameter specifies the address (e.g., 7) Another value whose meaning is mutually understood between the MG
IP port number for IP networks) to be used for subsequent communica- and the MGC.
tions. 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.
The optional ServiceChangeDelay parameter is expressed in seconds. If The ServiceChangeReason parameter specifies the reason why the
the delay is absent or set to zero, the delay value should be considered ServiceChange has or will occur. It consists of an alphanumeric
to be null. In the case of a "graceful" ServiceChangeMethod, a null token (IANA registered) and an explanatory string.
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 The optional ServiceChangeAddress parameter specifies the address
any) of the protocol supported. The ServiceChangeProfile includes the (e.g., IP port number for IP networks) to be used for subsequent
version of the profile supported. 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.
The optional ServiceChangeVersion parameter contains the protocol ver- The optional ServiceChangeDelay parameter is expressed in seconds.
sion and is used if protocol version negotiation occurs (see section If the delay is absent or set to zero, the delay value should be
11.3). 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.
Internet draft MEGACO Protocol February 21, 2000 The optional ServiceChangeProfile parameter specifies the Profile (if
any) of the protocol supported. The ServiceChangeProfile includes
the version of the profile supported.
The optional TimeStamp parameter specifies the actual time as kept by The optional ServiceChangeVersion parameter contains the protocol
the sender. It can be used by the responder to determine how its notion version and is used if protocol version negotiation occurs (see
of time differs from that of its correspondent. TimeStamp is sent with a section 11.3).
precision of hundredths of a second, and is expressed in UTC.
The optional Extension parameter may contain any value whose meaning is The optional TimeStamp parameter specifies the actual time as kept by
mutually understood by the MG and MGC. the sender. 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, and is expressed in
UTC.
A ServiceChange Command specifying the "Root" for the TerminationID and The optional Extension parameter may contain any value whose meaning
ServiceChangeMethod equal to Restart is a registration command by which is mutually understood by the MG and MGC.
a Media Gateway announces its existence to the Media Gateway Controller.
The Media Gateway is expected to be provisioned with the name of one
primary and optionally some number of alternate Media Gateway Controll-
ers. Acknowledgement of the ServiceChange Command completes the
registration process. The MG may specify the transport ServiceChangeAd-
dress to be used by the MGC for sending messages in the ServiceChangeAd-
dress 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 destina-
tion for all subsequent transaction requests within the association. At
the same time, as indicated in section 9, transaction replies and pend-
ing indications must be sent to the address from which the corresponding
rquests originated. This must be done even if it implies extra messag-
ing 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 an ServiceChangeMgcId parameter A ServiceChange Command specifying the "Root" for the TerminationID
that describes the Media Gateway Controller that should preferably be and ServiceChangeMethod equal to Restart is a registration command by
contacted for further service by the Media Gateway. In this case the which a Media Gateway announces its existence to the Media Gateway
Media Gateway shall reissue the ServiceChange command to the new Media Controller. The Media Gateway is expected to be provisioned with the
Gateway Controller. The Gateway specified in an ServiceChangeMgcId, if name of one primary and optionally some number of alternate Media
provided, shall be contacted before any further alternate MGCs. On a Gateway Controllers. Acknowledgement of the ServiceChange Command
HandOff message from MGC to MG, the ServiceChangeMgcId is the new MGC completes the registration process. The MG may specify the transport
that will take over from the current MGC. 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 section 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 return from ServiceChange is empty except when the Root termina- The Media Gateway Controller may return an ServiceChangeMgcId
tionID is used. In that case it includes the following parameters as parameter that describes the Media Gateway Controller that should
required: 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 Gateway specified in an
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.
* ServiceChangeAddress, if the responding MGC wishes to specify an The return from ServiceChange is empty except when the Root
new destination for messages from the MG for the remainder of the terminationID is used. In that case it includes the following
association; parameters as required:
* ServiceChangeMgcId, if the responding MGC does not wish to sustain . ServiceChangeAddress, if the responding MGC wishes to specify an
an association with the MG; new destination for messages from the MG for the remainder of the
association;
Internet draft MEGACO Protocol February 21, 2000 . ServiceChangeMgcId, if the responding MGC does not wish to
sustain an association with the MG;
* ServiceChangeProfile, if the responder wishes to negotiate the pro- . ServiceChangeProfile, if the responder wishes to negotiate the
file to be used for the association; profile to be used for the association;
* ServiceChangeVersion, if the responder wishes to negotiate the ver- . ServiceChangeVersion, if the responder wishes to negotiate the
sion of the protocol to be used for the association. version of the protocol to be used for the association.
The following ServiceChangeReasons are defined. This list may be The following ServiceChangeReasons are defined. This list may be
extended by an IANA registration as outlined in section 13.3 extended by an IANA registration as outlined in section 13.3
900 Service Restored 900 Service Restored
901 Cold Boot 901 Cold Boot
902 Warm Boot 902 Warm Boot
903 MGC Directed Change 903 MGC Directed Change
904 Termination malfunctioning 904 Termination malfunctioning
905 Termination taken out of service 905 Termination taken out of service
906 Loss of lower layer connectivity (e.g. downstream 906 Loss of lower layer connectivity (e.g. downstream sync)
sync)
907 Transmission Failure 907 Transmission Failure
908 MG Impending Failure 908 MG Impending Failure
909 MGC Impending Failure 909 MGC Impending Failure
910 Media Capability Failure 910 Media Capability Failure
911 Modem Capability Failure 911 Modem Capability Failure
912 Mux Capability Failure 912 Mux Capability Failure
913 Signal Capability Failure 913 Signal Capability Failure
914 Event Capability Failure 914 Event Capability Failure
915 State Loss 915 State Loss
7.2.9. Manipulating and Auditing Context Attributes 7.2.9 Manipulating and Auditing Context Attributes
The commands of the protocol as discussed in the preceding sections
apply to terminations. This section specifies how contexts are manipu-
lated and audited.
Commands are grouped into actions (see section 8). An action applies to The commands of the protocol as discussed in the preceding sections
one context. In addition to commands, an action may contain context apply to terminations. This section specifies how contexts are
manipulation and auditing instructions. manipulated and audited.
An action request sent to a MG may include a request to audit attributes Commands are grouped into actions (see section 8). An action applies
of a context. An action may also include a request to change the attri- to one context. In addition to commands, an action may contain
butes of a context. context manipulation and auditing instructions.
The context properties that may be included in an action reply are used An action request sent to a MG may include a request to audit
to return information to a MGC. This can be information requested by an attributes of a context. An action may also include a request to
audit of context attributes or details of the effect of manipulation of change the attributes of a context.
a context.
Internet draft MEGACO Protocol February 21, 2000 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.
If a MG receives an action which contains both a request to audit con- If a MG receives an action which contains both a request to audit
text attributes and a request to manipulate those attributes, the context attributes and a request to manipulate those attributes, the
response SHALL include the values of the attributes after processing the response SHALL include the values of the attributes after processing
manipulation request. the manipulation request.
7.2.10. Generic Command Syntax 7.2.10 Generic Command Syntax
The protocol can be encoded in a binary format or in a text format. The protocol can be encoded in a binary format or in a text format.
MGCs should support both encoding formats. MGs may support both for- MGCs should support both encoding formats. MGs may support both
mats. formats.
The protocol syntax for the binary format of the protocol is defined in The protocol syntax for the binary format of the protocol is defined
Annex A. Annex C specifies the encoding of the Local and Remote in Annex A. Annex C specifies the encoding of the Local and Remote
descriptors for use with the binary format. descriptors for use with the binary format.
A complete ABNF of the text encoding of the protocol per RFC2234 is A complete ABNF of the text encoding of the protocol per RFC2234 is
given in Annex B. SDP is used as the encoding of the Local and Remote given in Annex B. SDP is used as the encoding of the Local and
Descriptors for use with the text encoding as modified in section 7.1.8. Remote Descriptors for use with the text encoding as modified in
section 7.1.8.
7.3. Command Error Codes 7.3 Command Error Codes
Errors consist of an IANA registered error code and an explanatory Errors consist of an IANA registered error code and an explanatory
string. Sending the explanatory string is optional. Implementations string. Sending the explanatory string is optional. Implementations
are encouraged to append diagnostic information to the end of the are encouraged to append diagnostic information to the end of the
string. string.
When a MG reports an error to a MGC, it does so in an error descriptor. When a MG reports an error to a MGC, it does so in an error
An error descriptor consists of an error code and optionally the associ- descriptor. An error descriptor consists of an error code and
ated explanatory string. optionally the associated explanatory string.
The identified error codes are: The identified error codes are:
400 - Bad Request 400 - Bad Request
401 - Protocol Error 401 - Protocol Error
402 - Unauthorized 402 - Unauthorized
403 - Syntax Error in Transaction 403 - Syntax Error in Transaction
404 - Syntax Error in TransactionReply 404 - Syntax Error in TransactionReply
405 - Syntax Error in TransactionPending 405 - Syntax Error in TransactionPending
406 - Version Not Supported 406 - Version Not Supported
410 - Incorrect identifier 410 - Incorrect identifier
411 - The transaction refers to an unknown ContextId 411 - The transaction refers to an unknown ContextId
412 - No ContextIDs available 412 - No ContextIDs available
421 - Unknown action or illegal combination of actions 421 - Unknown action or illegal combination of actions
422 - Syntax Error in Action 422 - Syntax Error in Action
430 - Unknown TerminationID 430 - Unknown TerminationID
431 - No TerminationID matched a wildcard 431 - No TerminationID matched a wildcard
Internet draft MEGACO Protocol February 21, 2000
432 - Out of TerminationIDs or No TerminationID available 432 - Out of TerminationIDs or No TerminationID available
433 - TerminationID is already in a Context 433 - TerminationID is already in a Context
440 - Unsupported or unknown Package 440 - Unsupported or unknown Package
441 - Missing RemoteDescriptor 441 - Missing RemoteDescriptor
442 - Syntax Error in Command 442 - Syntax Error in Command
443 - Unsupported or Unknown Command 443 - Unsupported or Unknown Command
444 - Unsupported or Unknown Descriptor 444 - Unsupported or Unknown Descriptor
445 - Unsupported or Unknown Property 445 - Unsupported or Unknown Property
446 - Unsupported or Unknown Parameter 446 - Unsupported or Unknown Parameter
447 - Descriptor not legal in this command 447 - Descriptor not legal in this command
448 - Descriptor appears twice in a command 448 - Descriptor appears twice in a command
450 - No such property in this package 450 - No such property in this package
451 - No such event in this package 451 - No such event in this package
452 - No such signal in this package 452 - No such signal in this package
453 - No such statistic in this package 453 - No such statistic in this package
454 - No such parameter value in this package 454 - No such parameter value in this package
455 - Parameter illegal in this Descriptor 455 - Parameter illegal in this Descriptor
456 - Parameter or Property appears twice in this Descriptor 456 - Parameter or Property appears twice in this Descriptor
461 - TransactionIDs in Reply do not match Request 461 - TransactionIDs in Reply do not match Request
462 - Commands in Transaction Reply do not match commands in request 462 - Commands in Transaction Reply do not match commands in
463 - TerminationID of Transaction Reply does not match request request
464 - Missing reply in Transaction Reply 463 - TerminationID of Transaction Reply does not match
465 - TransactionID in Transaction Pending does not match any open
request request
464 - Missing reply in Transaction Reply
465 - TransactionID in Transaction Pending does not match any
open request
466 - Illegal Duplicate Transaction Request 466 - Illegal Duplicate Transaction Request
467 - Illegal Duplicate Transaction Reply 467 - Illegal Duplicate Transaction Reply
471 - Implied Add for Multiplex failure 471 - Implied Add for Multiplex failure
500 - Internal Gateway Error 500 - Internal Gateway Error
501 - Not Implemented 501 - Not Implemented
502 - Not ready. 502 - Not ready.
503 - Service Unavailable 503 - Service Unavailable
504 - Command Received from unauthorized entity 504 - Command Received from unauthorized entity
505 - Command Received before Restart Response 505 - Command Received before Restart Response
skipping to change at page 56, line 5 skipping to change at page 56, line 37
518 - Event buffer full 518 - Event buffer full
519 - Out of space to store digit map 519 - Out of space to store digit map
520 - Media Gateway does not have a digit map 520 - Media Gateway does not have a digit map
521 - Termination is "ServiceChangeing" 521 - Termination is "ServiceChangeing"
526 - Insufficient bandwidth 526 - Insufficient bandwidth
529 - Internal hardware failure 529 - Internal hardware failure
530 - Temporary Network failure 530 - Temporary Network failure
531 - Permanent Network failure 531 - Permanent Network failure
581 - Does Not Exist 581 - Does Not Exist
Internet draft MEGACO Protocol February 21, 2000 8. TRANSACTIONS
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 series of Commands 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.
Following is a graphic representation of the Transaction, Action and
Command relationships.
Commands between the Media Gateway Controller and the Media Gateway are +----------------------------------------------------------+
grouped into Transactions, each of which is identified by a Transac- | Transaction x |
tionID. Transactions consist of one or more Actions. An Action con- | +----------------------------------------------------+ |
sists of a series of Commands that are limited to operating within a | | Action 1 | |
single Context. Consequently each Action typically specifies a Contex- | | +---------+ +---------+ +---------+ +---------+ | |
tID. However, there are two circumstances where a specific ContextID is | | | Command | | Command | | Command | | Command | | |
not provided with an Action. One is the case of modification of a Ter- | | | 1 | | 2 | | 3 | | 4 | | |
mination outside of a Context. The other is where the controller | | +---------+ +---------+ +---------+ +---------+ | |
requests the gateway to create a new Context. Following is a graphic | +----------------------------------------------------+ |
representation of the Transaction, Action and Command relationships. | |
| +----------------------------------------------------+ |
| | Action 2 | |
| | +---------+ | |
| | | Command | | |
| | | 1 | | |
| | +---------+ | |
| +----------------------------------------------------+ |
| |
| +----------------------------------------------------+ |
| | Action 3 | |
| | +---------+ +---------+ +---------+ | |
| | | Command | | Command | | Command | | |
| | | 1 | | 2 | | 3 | | |
| | +---------+ +---------+ +---------+ | |
| +----------------------------------------------------+ |
+----------------------------------------------------------+
+----------------------------------------------------------+ Figure 5 Transactions, Actions and Commands
| 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 5 Transactions, Actions and Commands
Transactions are presented as TransactionRequests. Corresponding Transactions are presented as TransactionRequests. Corresponding
responses to a TransactionRequest are received in a single reply, possi- responses to a TransactionRequest are received in a single reply,
bly preceded by a number of TransactionPending messages (see section possibly preceded by a number of TransactionPending messages (see
8.2.3). section 8.2.3).
Internet draft MEGACO Protocol February 21, 2000 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.
Transactions guarantee ordered Command processing. That is, Commands At the first failing Command in a Transaction, processing of the
within a Transaction are executed sequentially. Ordering of Transactions remaining Commands in that Transaction stops. If a command contains
is NOT guaranteed - transactions may be executed in any order, or simul- a wildcarded TerminationID, the command is attempted with each of the
taneously. 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. 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. 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.
At the first failing Command in a Transaction, processing of the remain- Applications SHOULD implement an application level timer per
ing Commands in that Transaction stops. If a command contains a wild- transaction. Expiration of the timer should cause a retransmission
carded TerminationID, the command is attempted with each of the actual of the request. Receipt of a Reply should cancel the timer. Receipt
TerminationIDs matching the wildcard. A response within the Transac- of Pending should restart the timer.
tionReply 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. 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.
A TransactionReply includes the results for all of the Commands in the 8.1 Common Parameters
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. Transaction-
Pending 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 transac- 8.1.1 Transaction Identifiers
tion. 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 Transactions are identified by a TransactionID, which is assigned by
sender and is unique within the scope of the sender.
8.1.1. Transaction Identifiers 8.1.2 Context Identifiers
Transactions are identified by a TransactionID, which is assigned by Contexts are identified by a ContextID, which is assigned by the
sender and is unique within the scope of the sender. 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.
8.1.2. Context Identifiers The CHOOSE wildcard is used to request that the Media Gateway create
a new Context. The MGC shall not use partially specified ContextIDs
containing the CHOOSE wildcard.
Contexts are identified by a ContextID, which is assigned by the Media The MGC may use the ALL wildcard to address all Contexts on the MG.
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 8.2 Transaction Application Programming Interface
Internet draft MEGACO Protocol February 21, 2000 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 subsections.
new Context. The MGC shall not use partially specified ContextIDs con- 8.2.1 TransactionRequest
taining the CHOOSE wildcard. The MGC may use the ALL wildcard to
address all Contexts on the MG.
8.2. Transaction Application Programming Interface 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.
Following is an Application Programming Interface (API) describing the TransactionRequest(TransactionId {
Transactions of the protocol. This API is shown to illustrate the Tran- ContextID {Command _ Command},
sactions and their parameters and is not intended to specify implementa- . . .
tion (e.g. via use of blocking function calls). It will describe the ContextID {Command _ Command } })
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 subsections.
8.2.1. TransactionRequest The TransactionID parameter must specify a value for later
correlation with the TransactionReply or TransactionPending response
from the receiver.
The TransactionRequest is invoked by the sender. There is one Transac- The ContextID parameter must specify a value to pertain to all
tion per request invocation. A request contains one or more Actions, Commands that follow up to either the next specification of a
each of which specifies its target Context and one or more Commands per ContextID parameter or the end of the TransactionRequest, whichever
Context. comes first.
TransactionRequest(TransactionId { The Command parameter represents one of the Commands mentioned in the
ContextID {Command ... Command}, "Command Details" subsection titled "Application Programming
. . . Interface".
ContextID {Command ... Command } })
The TransactionID parameter must specify a value for later correlation 8.2.2 TransactionReply
with the TransactionReply or TransactionPending response from the
receiver.
The ContextID parameter must specify a value to pertain to all Commands The TransactionReply is invoked by the receiver. There is one reply
that follow up to either the next specification of a ContextID parameter invocation per transaction. A reply contains one or more Actions,
or the end of the TransactionRequest, whichever comes first. each of which must specify its target Context and one or more
Responses per Context.
The Command parameter represents one of the Commands mentioned in the TransactionReply(TransactionID {
"Command Details" subsection titled "Application Programming Interface". ContextID { Response _ Response },
. . .
ContextID { Response _ Response } })
8.2.2. TransactionReply The TransactionID parameter must be the same as that of the
corresponding TransactionRequest.
The TransactionReply is invoked by the receiver. There is one reply The ContextID parameter must specify a value to pertain to all
invocation per transaction. A reply contains one or more Actions, each Responses for the action. The ContextID may be specific or null.
of which must specify its target Context and one or more Responses per
Context.
TransactionReply(TransactionID { Each of the Response parameters represents a return value as
ContextID { Response ... Response }, mentioned in section 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.
Internet draft MEGACO Protocol February 21, 2000 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.
ContextID { Response ... Response } }) 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.
The TransactionID parameter must be the same as that of the correspond- If the receiver encounters an error such that it cannot determine a
ing TransactionRequest. 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 Actions 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
Transaction).
The ContextID parameter must specify a value to pertain to all Responses If the end of a transaction can not be reliably determined and one or
for the action. The ContextID may be specific or null. 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 Transaction as the only reply
Each of the Response parameters represents a return value as mentioned If the terminationID cannot be reliably determined it will send 442
in section 7.2, or an error descriptor if the command execution encoun- Syntax Error in Command as the action reply.
tered 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 If the end of a command cannot be reliably determined it will return
the Transaction request. If the optional command generates an error, 442 Syntax Error in Transaction as the reply to the last action it
the transaction still continues to execute, so the Reply would, in this can parse.
case, have Responses after an Error.
If the receiver encounters an error in processing a ContextID, the 8.2.3 TransactionPending
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 The receiver invokes the TransactionPending. A TransactionPending
legal Action, it will return a TransactionReply consisting of the Tran- indicates that the Transaction is actively being processed, but has
sactionID and a single error descriptor, 422 Syntax Error in Action. If not been completed. It is used to prevent the sender from assuming
the end of an action cannot be reliably determined but one or more the TransactionRequest was lost where the Transaction will take some
Actions can be parsed, it will process them and then send 422 Syntax time to complete.
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 Transaction).
If the end of a transaction can not be reliably determined and one or TransactionPending(TransactionID { } )
more Actions can be parsed, it will process them and then return 403
Syntax Error in Transaction as the last action reply for the transac-
tion. If no Actions can be parsed, it will return 403 Syntax Error in
Transaction as the only reply
If the terminationID cannot be reliably determined it will send 442 Syn- The TransactionID parameter must be the same as that of the
tax Error in Command as the action reply. 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
expects a response to any transaction from the MGC. Senders may
receive more than one TransactionPending for a command. If a
duplicate request is received when pending, the responder may send a
duplicate pending immediately, or continue waiting for its timer to
trigger another Transaction Pending.
If the end of a command cannot be reliably determined it will return 442 8.3 Messages
Syntax Error in Transaction as the reply to the last action it can
parse.
8.2.3. TransactionPending 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.
The receiver invokes the TransactionPending. A TransactionPending 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.
Internet draft MEGACO Protocol February 21, 2000 The transactions in a message are treated independently. There is no
order implied, there is no application or protocol acknowledgement of
a message.
indicates that the Transaction is actively being processed, but has not 9. TRANSPORT
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 transport mechanism for the protocol should allow the reliable
transport of transactions between an 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 normative
Annexes to this document. Additional Transports may be defined as
additional annexes in subsequent editions of this document, or in
separate documents. For transport of the protocol over IP, MGCs
shall implement both TCP and UDP/ALF, an MG shall implement TCP or
UDP/ALF or both.
The TransactionID parameter must be the same as that of the correspond- The MG is provisioned with a name or address (such as DNS name or IP
ing TransactionRequest. A property of root (normalMGExecutionTime) is address) of a primary and zero or more secondary MGCs (see section
settable by the MGC to indicate the interval within which the MGC 7.2.8) that is the address the MG uses to send messages to the MGC.
expects a response to any transaction from the MG. Another property If TCP or UDP is used as the protocol transport and the port to which
(normalMGCExecutionTime) is settable by the MGC to indicate the interval the initial ServiceChange request is to be sent is not otherwise
within which the MG should expects a response to any transaction from known, that request should be sent to the default port number for the
the MGC. Senders may receive more than one TransactionPending for a protocol. This port number is 2944 for text-encoded operation or
command. If a duplicate request is received when pending, the responder 2945 for binary-encoded operation, for either UDP or TCP. The MGC
may send a duplicate pending immediately, or continue waiting for its receives the message containing the ServiceChange request from the MG
timer to trigger another Transaction Pending. and can determine the MG's address from it. As described in section
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.
8.3. Messages 9.1 Ordering of Commands
Multiple Transactions can be concatenated into a Message. Messages have This document does not mandate that the underlying transport protocol
a header, which includes the identity of the sender. The Message Iden- guarantees the sequencing of transactions sent to an entity. This
tifier (MID) of a message is set to a provisioned name (e.g. domain property tends to maximize the timeliness of actions, but it has a
address/domain name/device name) of the entity transmitting the message. few drawbacks. For example:
Domain name is a suggested default.
Every Message contains a Version Number identifying the version of the . Notify commands may be delayed and arrive at the MGC after the
protocol the message conforms to. Versions consist of one or two transmission of a new command changing the EventsDescriptor
digits, beginning with version 1 for the present version of the proto-
col.
The transactions in a message are treated independently. There is no . If a new command is transmitted before a previous one is
order implied, there is no application or protocol acknowledgement of a acknowledged, there is no guarantee that prior command will be
message. executed before the new one.
9. TRANSPORT 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
section 8).