Internet Engineering Task Force                        Fernando Cuervo
INTERNET DRAFT                                         Nortel Networks
September 21, 1999
January 27, 2000                                            Bryan Hill
Expires March 21, July 27, 2000                                  Gotham Networks
<draft-ietf-megaco-protocol-04.txt>
<draft-ietf-megaco-protocol-05.txt>                       Nancy Greene
                                                       Nortel Networks
                                                     Christian Huitema
                                                Telcordia Technologies
                                                       Abdallah Rayhan
                                                       Nortel Networks
                                                           Brian Rosen
                                                            FORE Systems
                                                               Marconi
                                                           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 nappropriate inappropriate to use Internet-Drafts 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 March July 2000.

Internet draft              MEGACO Protocol           September 21, 1999

                           Table of Contents             January 27, 2000

1.  SCOPE .....................................................  6  7
2.  REFERENCES ................................................  6  7
   2.1.  Normative References references .................................  6  7
   2.2.  Informative References references ...............................  7  8
3.  DEFINITIONS ...............................................  7  9
4.  ABBREVIATIONS .............................................  9 10
5.  CONVENTIONS ...............................................  9 10
6.  CONNECTION MODEL ..........................................  9 10
   6.1.  Contexts ............................................. 12 14
      6.1.1.  Context Properties Attributes and Descriptors .............. 13 15
      6.1.2.  Creating, Deleting and Modifying Contexts ....... 13 15
   6.2.  Terminations ......................................... 13 15
      6.2.1.  Termination Dynamics ............................ 14 16
      6.2.2.  TerminationIDs .................................. 14 16
      6.2.3.  Packages ........................................ 14 17
      6.2.4.  Termination Properties and Descriptors .......... 15 17
      6.2.5.  Root Termination ................................ 16 19
7.  COMMANDS .................................................. 17 20
   7.1.  Descriptors .......................................... 18 21
      7.1.1.  Wildcarding Parameter Values in Commands ........ 18
      7.1.2.  Specifying Parameters ........................... 19
      7.1.3. 21
      7.1.2.  Modem Descriptor ................................ 19
      7.1.4. 22
      7.1.3.  Multiplex Descriptor ............................ 19
      7.1.5. 22
      7.1.4.  Media Descriptor ................................ 20
      7.1.6. 22
      7.1.5.  Termination State Descriptor .................... 20
      7.1.7. 23
      7.1.6.  Stream Descriptor ............................... 20
      7.1.8. 24
      7.1.7.  LocalControl Descriptor ......................... 21
      7.1.9. 24
      7.1.8.  Local and Remote Descriptors .................... 21
      7.1.10. 25
      7.1.9.  Events Descriptor .............................. 22 ............................... 28
      7.1.10.  EventBuffer Descriptor ......................... 29
      7.1.11.  Signals Descriptor ............................. 23 29
      7.1.12.  RequestedInfo  Audit Descriptor ....................... 23 ............................... 31
      7.1.13.  ServiceChange Descriptor ....................... 24 32
      7.1.14.  DigitMap Descriptor ............................ 24 32
      7.1.15.  Statistics Descriptor .......................... 25 34
      7.1.16.  Packages Descriptor ............................ 35
      7.1.17.  ObservedEvents Descriptor ...................... 35
      7.1.18.  Topology Descriptor ............................ 26 35
   7.2.  Command Application Programming Interface ............ 28 38
      7.2.1.  Add ............................................. 29 38
      7.2.2.  Modify .......................................... 30 40
      7.2.3.  Subtract ........................................ 30 41
      7.2.4.  Move ............................................ 31 42
      7.2.5.  AuditValue ...................................... 32 43
      7.2.6.  AuditCapabilities ............................... 33 44
      7.2.7.  Notify .......................................... 34 45
      7.2.8.  ServiceChange ................................... 34 45
      7.2.9.  Manipulating and Auditing Context Attributes .... 49
      7.2.10.  Generic Command Syntax .......................... 36 ......................... 50

Internet draft              MEGACO Protocol             January 27, 2000

   7.3.  Command Error Codes .................................. 37

Internet draft              MEGACO Protocol           September 21, 1999 50
8.  TRANSACTIONS .............................................. 38 52
   8.1.  Common Parameters .................................... 39 53
      8.1.1.  Transaction Identifiers ......................... 39 53
      8.1.2.  Context Identifiers ............................. 39 53
   8.2.  Transaction Application Programming Interface ........ 39 54
      8.2.1.  TransactionRequest .............................. 40 54
      8.2.2.  TransactionReply ................................ 40 54
      8.2.3.  TransactionPending .............................. 41 56
   8.3.  Messages ............................................. 41 56
9.  TRANSPORT ................................................. 42 56
   9.1.  Ordering of Commands ................................. 57
   9.2.  Protection against Restart Avalanche ................. 58
10.  SECURITY CONSIDERATIONS .................................. 42 59
   10.1.  Protection of Protocol Connections .................. 42 59
   10.2.  Interim AH-within-MEGACO/H.248 AH scheme ............... 43 ................................... 60
   10.3.  Protection of Media Connections ..................... 44 61
11.  MG-MGC CONTROL INTERFACE ................................. 44 61
   11.1.  Multiple Virtual MGs ................................ 45 62
   11.2.  Cold Start .......................................... 45 62
   11.3.  Negotiation of Protocol Version ..................... 63
   11.4.  Failure of an MG .................................... 46
   11.4. 63
   11.5.  Failure of an MGC ................................... 46 64
12.  PACKAGE DEFINITION ....................................... 47 65
   12.1.  Guidelines for defining packages .................... 47
   12.2.  Example 65
      12.1.1.  Package ........................................ 65
      12.1.2.  Properties ..................................... 66
      12.1.3.  Events ......................................... 66
      12.1.4.  Signals ........................................ 67
      12.1.5.  Statistics ..................................... 67
      12.1.6.  Procedures ..................................... 48 67
   12.2.  Guidelines to defining Properties, Statistics ....... 68
   12.3.  Lists ............................................... 68
   12.4.  Identifiers ......................................... 68
   12.5.  Package Registration ................................ 52 68
13.  IANA CONSIDERATIONS ...................................... 52 68
   13.1.  Packages ............................................ 52 68
   13.2.  Error Codes ......................................... 53 69
   13.3.  ServiceChange Reasons ............................... 70
14.  CONTACT INFORMATION ...................................... 53 70
ANNEX A - ASN.1 DESCRIPTION BINARY ENCODING OF THE PROTOCOL (NORMATIVE) ....... 54 ........... 71
   A.1.   Specification language .............................. 54  Coding of wildcards .................................. 71
   A.2.   Syntax  ASN.1 syntax specification ................................ 54 ........................... 73
   A.3.  Digit maps and path names ............................ 88
ANNEX B - TEXT ENCODING OF THE PROTOCOL (NORMATIVE) ........... 55 ............. 89
   B.1.   Translation Mechanism ............................... 55  Coding of wildcards .................................. 89
   B.2.  ABNF specification .................................. 55 ................................... 89
ANNEX C - BINARY ENCODING OF THE PROTOCOL ..................... 65
   C.1.   Translation mechanism ............................... 65
ANNEX D - TAGS FOR MEDIA STREAM PROPERTIES .................... 66
   D.1. (NORMATIVE) ..........100

Internet draft              MEGACO Protocol             January 27, 2000

   C.1.  General Media Attributes ............................ 66
   D.2.   Multiplex properties ................................ 66
   D.3. .............................101
   C.2.  Mux Properties for BearerDescriptor ..................... 67
   D.4.   For DS0 ............................................. 67
   D.5.   For .......................................101
   C.3.  General bearer properties ............................101
   C.4.  General ATM VC .......................................... 67
   D.6. properties ...............................101
   C.5.  Frame Relay ......................................... 67
   D.7.   RTP Stream .......................................... 67
Annex E - ..........................................102
   C.6.  IP ...................................................103
   C.7.  ATM AAL2 .............................................103
   C.8.  ATM AAL1 .............................................103
   C.9.  Bearer Capabilities ..................................104
   C.10.  AAL5 Properties .....................................104
   C.11.  SDP Equivalents .....................................105
   C.12.  H.245 ...............................................105
ANNEX D TRANSPORT USING UDP AND APPLICATION LAYER FRAMING ... 68
   E.1. OVER IP (NORMATIVE) .........................105
   D.1.  Transport over IP/UDP using Application Level ........105
      D.1.1.  Providing At-Most-Once functionality ................ 68
   E.2. Functionality ............105
      D.1.2.  Transaction identifiers and three-way handshake ..... 69
   E.3.  106
      D.1.3.  Computing retransmission timers ..................... 69
   E.4. .................108
      D.1.4.  Provisional responses Executing some transactions ... 70

Internet draft              MEGACO Protocol           September 21, 1999

   E.5.   Ordering of commands ................................ 73
   E.6.   Fighting the restart avalanche ...................... 74
ANNEX F - TRANSPORT USING ...........................109
      D.1.5.  Repeating Requests, Responses and ...............109
   D.2.  Using TCP ................................. 75
   F.1. ............................................110
      D.2.1.  Providing the At-Most-Once functionality ............ 75
   F.2. ........111
      D.2.2.  Transaction identifiers and three way handshake ..... 76
   F.3.  111
      D.2.3.  Computing retransmission timers ..................... 76
   F.4. .................111
      D.2.4.  Provisional responses ............................... 76
   F.5. ...........................111
      D.2.5.  Ordering of commands ................................ 76
   F.6.   Fighting the restart avalanche ...................... 77 ............................112
ANNEX G E BASIC PACKAGES ........................................112
   E.1.  Generic ..............................................112
      E.1.1.  Properties ......................................112
      E.1.2.  Events ..........................................112
      E.2.2.  Events ..........................................116
      E.2.3.  Signals .........................................116
      E.2.4.  Statistics ......................................116
      E.2.5.  Procedures ......................................116
   E.3.  Tone Generator Package ...............................116
      E.3.1.  Properties ......................................116
      E.3.2.  Events ..........................................116
      E.3.3.  Signals .........................................116
      E.3.4.  Statistics ......................................117
      E.3.5.  Procedures ......................................117
   E.4.  Tone Detection Package ...............................117
      E.4.1.  Properties ......................................117
      E.4.2.  Events ..........................................117
      E.4.3.  Signals .........................................119
      E.4.4.  Statistics ......................................119
      E.4.5.  Procedures ......................................119
   E.5.  Basic DTMF Generator Package .........................119
      E.5.1.  Properties ......................................119
      E.5.2.  Events ..........................................119

Internet draft              MEGACO Protocol             January 27, 2000

      E.5.3.  Signals .........................................120
      E.5.4.  Statistics ......................................120
      E.5.5.  Procedures ......................................120
   E.6.  DTMF detection Package ...............................121
      E.6.1.  Properties ......................................121
      E.6.2.  Events ..........................................121
      E.6.3.  Signals .........................................121
      E.6.4.  Statistics ......................................121
      E.6.5.  Procedures ......................................121
   E.7.  Call Progress Tones Generator Package ................122
      E.7.1.  Properties ......................................122
      E.7.2.  Events ..........................................122
      E.7.3.  Signals .........................................122
      E.7.4.  Statistics ......................................122
      E.7.5.  Procedures ......................................123
   E.8.  Call Progress Tones Detection Package ................123
      E.8.1.  Properties ......................................123
      E.8.2.  Events ..........................................123
      E.8.3.  Signals .........................................123
      E.8.4.  Statistics ......................................123
      E.8.5.  Procedures ......................................123
   E.9.  Analog Line Supervision Package ......................124
      E.9.1.  Properties ......................................124
      E.9.2.  Events ..........................................124
      E.9.3.  Signals .........................................124
      E.9.4.  Statistics ......................................125
      E.9.5.  Procedures ......................................125
   E.10.  Basic Continuity Package ............................125
      E.10.1.  Properties .....................................125
      E.10.2.  Events .........................................125
      E.10.3.  Signals ........................................126
      E.10.4.  Statistics .....................................126
      E.10.5.  Procedures .....................................126
   E.11.  Network Package .....................................126
      E.11.1.  Properties .....................................127
      E.11.2.  Events .........................................127
      E.11.3.  Signals ........................................128
      E.11.4.  Statistics .....................................128
      E.11.5.  Procedures .....................................128
   E.12.  RTP Package .........................................128
      E.12.1.  Properties .....................................128
      E.12.2.  Events .........................................129
      E.12.3.  Signals ........................................129
      E.12.4.  Statistics .....................................129
      E.12.5.  Procedures .....................................130
   E.13.  DS0 Package .........................................130
      E.13.1.  Properties .....................................130
      E.13.2.  Events .........................................131

Internet draft              MEGACO Protocol             January 27, 2000

      E.13.3.  Signals ........................................131
      E.13.4.  Statistics .....................................131
      E.13.5.  Procedures .....................................131
APPENDIX A      EXAMPLE CALL FLOWS .................................... 77
   G.1. (INFORMATIVE) ..............131
   A.1.  Residential Gateway to Residential Gateway Call ..... 77
      G.1.1. ......131
      A.1.1.  Programming Residential GW Analog Line ......... 77
   G.2.   Multimedia Gateway Examples ......................... 88
      G.2.1.   H.320 Gateway .................................. 88
      G.2.2.   Multipoint Context Example ..................... 96
      G.2.3.   Single Media Call The single media the call .... 97
      G.2.4.   H.323 and FAS Signaling in MG ..................101
      G.2.5.   Simple text telephone call .....................103
         G.2.5.1.   Basic operation ...........................106
         G.2.5.2.   Voice channels in the simple text only ....106
         G.2.5.3.   Operation with the alternating text and ...106

Internet draft              MEGACO Protocol           September 21, 1999

TABLE OF FIGURES

Figure 1 Example of MEGACO Connection Model ..................... 10
Figure 2 Example Call Waiting Scenario / Alerting Applied to T1 . 11
Figure 3 Example Call Waiting Scenario / Answer by T1 ........... 12
Figure 4 Example topologies ..................................... 27
Figure 5 Transactions, Actions ..........131
      A.1.2.  Collecting Digits and Commands ..................... 38
Figure 6 H.320 Gateway Context .................................. 89
Figure 7 Multimedia Context Example ............................. 97
Figure 8 Single Media Call Example .............................. 98 Initiating Termination.....132

Internet draft              MEGACO Protocol           September 21, 1999             January 27, 2000

1.  SCOPE

MEGACO defines the protocols used between elements of a physically
decomposed multimedia Gateway consisting of a Media Gateway and a Media
Gateway Controller.  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.
This document does not define how gateways, multipoint control units or
integrated voice response units (IVRs) work.  Instead it creates a gen-
eral 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 signaling signalling systems, including
tone signaling, signalling, ISDN, ISUP, QSIG, and GSM. National variants of these
signaling
signalling systems will be supported where applicable.

The protocol definition in this document is common text with ITU Recom-
mendation H.248.

2.  REFERENCES

2.1.  Normative References references

ITU-T Recommendation H.225.0 (1998): "Call Signaling Signalling Protocols and
Media Stream Packetization for Packet Based Multimedia Communications Sys-
tems".
Systems".

ITU-T Recommendation H.235 (02/98): "Security and encryption for H-
Series (H.323 and other H.245-based) multimedia terminals".

ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia Com-
munication"
munication".

ITU-T Recommendation H.323 (1998): "Packet Based Multimedia Communica-
tion Systems" Systems".

ITU-T Recommendation I.363.1 (08/96), "B-ISDN ATM Adaptation Layer
specification: Type 1 AAL".

ITU-T Recommendation I.366.1 (06/98), "Segmentation and Reassembly

Internet draft              MEGACO Protocol             January 27, 2000

Service Specific Convergence Sublayer for the AAL type 2".

ITU-T Recommendation I.366.2 (02/99), "AAL type 2 service specific con-
vergence sublayer for trunking".

ITU-T Recommendation Q.931 (05/98): "Digital Subscriber Signalling Sys-
tem No.  1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification
for Basic Call Control"

ITU-T Recommendation X.680 (1997): "Information technology-Abstract Syn-
tax Notation One (ASN.1): Specification of basic notation".

ITU-T Draft draft Recommendation H.246 (1998), "Interworking of H-series mul-
timedia terminals with H-series multimedia terminals and voice/voiceband
terminals on GSTN and ISDN" ISDN".

RFC 1006, "ISO Transport Service on top of the TCP, Version 3", Marshall
T. Rose, Dwight E. Cass, May 1987.

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels",
Scott Bradner, March 1997.  RFC 2145, "Use and Interpretation of HTTP Version Numbers", J. C. Mogul,
R. Fielding, J. Gettys, H. Frystyk, May 2234, "Augmented BNF for Syntax Specifi-
cations: ABNF", D. Crocker, P. Overell, November 1997.

RFC 2327, "SDP: Session Description Protocol", M. Handley, V. Jacobson,
April 1998.

Internet draft              MEGACO Protocol           September 21, 1999

RFC 2402, "IP Authentication Header", S. Kent, R. Atkinson, November
1998.

RFC 2406, "IP Encapsulating Security Payload (ESP)", S. Kent, R. Atkin-
son, November 1998.

2.2.  Informative References references

ITU-T Recommendation Q.931 (1993): "Digital Subscriber Signalling System
No.  1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification E.180/Q.35 (1998): "Technical characteristics of
tones for
Basic Call Control" the telephone service"

ITU-T Recommendation Q.724 (1988): "Signalling procedures"

RFC 768, "User Datagram Protocol", J.Postel, August 1980.

RFC 793, "TRANSMISSION CONTROL PROTOCOL", J.Postel, September 1981.

RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", H.
Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996.

RFC 1890, "RTP Profile for Audio and Video Conferences with Minimal Con-
trol", H. Schulzrinne, January 1996.

RFC 2234, " Augmented BNF for Syntax Specifications: ABNF", D. Crocker,
P. Overell, November 1997.

Internet draft              MEGACO Protocol             January 27, 2000

RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R.
Atkinson, November 1998.

RFC 2543, " SIP: Session Initiation Protocol", M. Handley, H.
Schulzrinne, E. Schooler, J. Rosenberg, March 1999.

RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", S. Deer-
ing, R. Hinden, December 1998.

3.  DEFINITIONS

Access Gateway: A type of gateway that provides a User to Network Inter-
face (UNI) such as ISDN.

Back-haul: The transport of signaling information from a media termina-
tion gateway containing a signaling gateway function to a call process-
ing entity. For example, a layer 3 protocol such as Q.931 might be tran-
sported between MG and MGC such that the MGC terminates layer 3,
although the MG terminates layers 1 and 2.  The signalling gateway func-
tion terminates layers 1 and 2 and replaces them with an appropriate
equivalent on the packet network.

Descriptor: A syntactic element of the protocol that groups related pro-
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.

Gatekeeper (GK): A functional entity serving a gateway, providing ser-
vices such as authentication, authorization, alias resolution and call
routing.

Internet draft              MEGACO Protocol           September 21, 1999

H.323 Signaling: This function in the decomposed gateway supports normal
H.323 signaling, such as H.225.0, H.245, or H.450.x as described in
H.323.

Media Gateway (MG): The media gateway converts media provided in one
type of network to the format required in another type of network. For
example, a MG could terminate bearer channels from a switched circuit
network (i.e., 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 mes-
sages and perform performs other IVR functions, or may perform media con-
ferencing. conferenc-
ing.

Media Gateway Controller (MGC): Controls the parts of the call state
that pertain to connection control for media channels in a MG.

Multipoint Control Unit (MCU): An entity that controls the setup and
coordination of a multi- user conference that typically includes pro-
cessing of audio, video and data.

Network Access Server: A gateway function in a MG that converts modem
signals from an SCN network and provides data access to the Internet.

Residential Gateway: A gateway that interworks an analog analogue line to a
packet network. A residential gateway typically contains one or two ana-
log
analogue lines and is located at the customer premises.

SCN FAS Signaling Signalling Gateway: This function contains the SCN Signaling Signalling
Interface that terminates SS7, ISDN and or other signaling signalling links where the
call control channel and bearer channels are collocated in the same phy-
sical span.

SCN NFAS Signaling Signalling Gateway: This function contains the SCN Signaling Signalling
Interface that terminates SS7 and or other signaling signalling links where the call
control channels are separated from bearer channels.

Internet draft              MEGACO Protocol             January 27, 2000

Stream: Bidirectional media or control flow received/sent by a media
gateway as part of a call or conference.

Trunk: A communication channel between two switching systems such as a
DS0 on a T1 or E1 line.

Trunking Gateway: A gateway between SCN network and packet network that
typically terminates a large number of digital circuits.

Internet draft              MEGACO Protocol           September 21, 1999

4.  ABBREVIATIONS

This recommendation defines the following terms.
ATM             Asynchronous Transfer Mode
BRI             Basic Rate Interface
CAS             Channel Associated Signaling Signalling
DTMF            Dual Tone Multi Frequency Multi-Frequency
FAS             Facility Associated Signaling
GK      GateKeeper Signalling
GW              GateWay
IP              Internet Protocol
ISUP            ISDN User Part
MG              Media Gateway
MGC             Media Gateway Controller
NAS     Network Access Server
NFAS    Non Facility            Non-Facility Associated Signaling Signalling
PRI             Primary Rate Interface
PSTN            Public Switched Telephone Network
QoS             Quality of Service
RTCP    Real-time Transport Control Protocol
RTP             Real-time Transport Protocol
SCN             Switched Circuit Network
SG      Signaling              Signalling Gateway
SS7             Signalling System No7 No. 7

5.  CONVENTIONS

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.

6.  CONNECTION MODEL

The connection model for the protocol describes the logical entities, or
objects, within the Media Gateway that can be controlled by the Media
Gateway Controller.  The main abstractions used in the connection model
are Terminations and Contexts.

A Termination sources and/or sinks one or more media streams.  In a mul-
timedia multimedia
conference, a Termination can be multimedia and sources or sinks
multiple multi-
ple media streams.  The media stream parameters, as well as modem, and
bearer parameters are encapsulated within the Termination.

Internet draft              MEGACO Protocol             January 27, 2000

A Context is an association between a collection of Terminations. There
is a special type of Context, the null Context, which contains all Ter-
minations that are not associated to any other Termination.  For
instance, in a decomposed access gateway, all idle lines are represented
by Terminations in the null Context.

Internet draft              MEGACO Protocol           September 21, 1999

Following is a graphical depiction of these concepts.  The diagram of
Figure 1 gives several examples and is not meant to be an all-inclusive
illustration.  The asterisk box in each of the Contexts represents the
logical association of Terminations implied by the Context.

Internet draft              MEGACO Protocol             January 27, 2000

          +------------------------------------------------------+
          |Media Gateway                                         |
          | +-------------------------------------------------+  |
          | |Context                          +-------------+ |  |
          | |                                 | Termination | |  |
          | |                                 |-------------| |  |
          | |  +-------------+             +->| SCN Bearer  |<---+->
          | |  | Termination |   +-----+   |  |   Channel   | |  |
          | |  |-------------|   |     |---+  +-------------+ |  |
        <-+--->| RTP Stream  |---|  *  |                      |  |
          | |  |             |   |     |---+  +-------------+ |  |
          | |  +-------------+   +-----+   |  | Termination | |  |
          | |                              |  |-------------| |  |
          | |                              +->| SCN Bearer  |<---+->
          | |                                 |   Channel   | |  |
          | |                                 +-------------+ |  |
          | +-------------------------------------------------+  |
          |                                                      |
          |                                                      |
          |                    +------------------------------+  |
          |                    |Context                       |  |
          |  +-------------+   |              +-------------+ |  |
          |  | Termination |   | +-----+      | Termination | |  |
          |  |-------------|   | |     |      |-------------| |  |
        <-+->| SCN Bearer  |   | |  *  |------| SCN Bearer  |<---+->
          |  |   Channel   |   | |     |      |   Channel   | |  |
          |  +-------------+   | +-----+      +-------------+ |  |
          |                    +------------------------------+  |
          |                                                      |
          |                                                      |
          | +-------------------------------------------------+  |
          | |Context                                          |  |
          | |  +-------------+                +-------------+ |  |
          | |  | Termination |   +-----+      | Termination | |  |
          | |  |-------------|   |     |      |-------------| |  |
        <-+--->| SCN Bearer  |---|  *  |------| SCN Bearer  |<---+->
          | |  |   Channel   |   |     |      |   Channel   | |  |
          | |  +-------------+   +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          | ___________________________________________________  |
          +------------------------------------------------------+
                Figure 1: Example of MEGACO Connection Model

Internet draft              MEGACO Protocol           September 21, 1999

The example below shows an example of one way to accomplish a call-
waiting scenario in a decomposed access gateway, illustrating the relo-
cation 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

Internet draft              MEGACO Protocol             January 27, 2000

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                                         |
          | +-------------------------------------------------+  |
          | |Context C1                                       |  |
          | |  +-------------+                +-------------+ |  |
          | |  | Term. T2    |   +-----+      | Term. T1    | |  |
          | |  |-------------|   |     |      |-------------| |  |
        <-+--->| RTP Stream  |---|  *  |------| SCN Bearer  |<---+->
          | |  |             |   |     |      |   Channel   | |  |
          | |  +-------------+   +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          |                                                      |
          | +-------------------------------------------------+  |
          | |Context C2                                       |  |
          | |                                 +-------------+ |  |
          | |                    +-----+      | Term. T3    | |  |
          | |                    |     |      |-------------| |  |
          | |                    |  *  |------| SCN Bearer  |<---+->
          | |                    |     |      |   Channel   | |  |
          | |                    +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          +------------------------------------------------------+
        Figure 2 Example Call Waiting Scenario / Alerting Applied to T1

Internet draft              MEGACO Protocol           September 21, 1999             January 27, 2000

          +------------------------------------------------------+
          |Media Gateway                                         |
          | +-------------------------------------------------+  |
          | |Context C1                                       |  |
          | |  +-------------+                                |  |
          | |  | Term. T2    |   +-----+                      |  |
          | |  |-------------|   |     |                      |  |
        <-+--->| RTP Stream  |---|  *  |                      |  |
          | |  |             |   |     |                      |  |
          | |  +-------------+   +-----+                      |  |
          | +-------------------------------------------------+  |
          |                                                      |
          | +-------------------------------------------------+  |
          | |Context C2                                       |  |
          | |  +-------------+                +-------------+ |  |
          | |  | Term. T1    |   +-----+      | Term. T3    | |  |
          | |  |-------------|   |     |      |-------------| |  |
        <-+--->| SCN Bearer  |---|  *  |------| SCN Bearer  |<---+->
          | |  |   Channel   |   |     |      |   Channel   | |  |
          | |  +-------------+   +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          +------------------------------------------------------+
        Figure 3. Example Call Waiting Scenario / Answer by T1

6.1.  Contexts

A Context is an association between a number of Terminations.  The 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 exists 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           September 21, 1999             January 27, 2000

conferences might allow three or more terminations per Context.

6.1.1.  Context Properties Attributes and Descriptors

The properties attributes of Contexts include

* are:

ContextID, a 32 bit unsigned integer chosen by the MG.  It may be specified
     as ALL "*" or NULL "-" in some circumstances.

*    the  The topology
(who hears/sees whom).  The topology of a Context describes the flow of
media between the Terminations within a Context.  In contrast, the mode
of a Termina-
     tion Termination (send/receive/...) describes the flow of the media at
the ingress/egress of the media gateway.

6.1.2.  Creating, Deleting and Modifying Contexts

The protocol can be priority is used for a context in order to (implicitly) create Contexts and modify provide the
parameter values of existing Contexts.  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

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 Contexts, subtract them from Contexts, and to move Termi-
nations Ter-
minations between Contexts.  Contexts are deleted implicitly when the
last remaining Termination is subtracted from it. or moved out.

6.2.  Terminations

A Termination is a logical entity on a MG that sources and/or sinks
media and/or control streams.  A Termination is described by a number of
characterizing Properties, which are grouped in a set of Descriptors
that are included in commands. Terminations have unique identities (Ter-
minationIDs), assigned by the MG at the time of their creation.

Terminations representing physical entities have a semi-permanent
existence.  For example, a Termination representing a TDM channel might
exist for as long as it is provisioned in the gateway.  Terminations
representing ephemeral information flows, such as RTP flows, would usu-
ally exist only for the duration of their use.

Ephemeral Terminations are created by means of an Add command.  They are
destroyed by means of a Subtract command.  In contrast, when a physical
Termination is Add'ed Added to or Subtract'ed Subtracted from a Context, it is taken from
or to the null Context, respectively.

Internet draft              MEGACO Protocol             January 27, 2000

Terminations may have signals applied to them.  Signals are MG 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.

Internet draft              MEGACO Protocol           September 21, 1999
Statistics are reported to the MGC upon request (by means of the Audit-
Value command, see Section 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,
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 MediaDescriptors. 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
an ATM AAL2. When a new multiplexed bearer is to be created, an ephem-
eral termination is created in a context established for this purpose.
When the termination is subtracted, the multiplexed bearer is destroyed.

6.2.1.  Termination Dynamics

The protocol can be used to create new Terminations and to modify pro-
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

Terminations are referenced by a TerminationID, which is an arbitrary
schema chosen by the MG.

TerminationIDs of physical Terminations are provisioned in the Media
Gateway.

In a text encoding of the protocol, while The TerminationIDs are arbitrary,
by judicious choice of names, the wildcard character, "*" may be made
more useful.  When the wildcard character is encountered, it will
"match" all TerminationIDs having the same previous and following char-
acters (if appropriate). chosen to have structure.  For example, if there were TerminationIDs
instance, a TerminationID may consist of
R13/3/1, R13/3/2 trunk group and R13/3/3, a trunk within
the TerminationID R13/3/* would match all group.

A wildcarding mechanism using two types of them.  There are some circumstances where ALL Terminations must wildcards can be
referred to. used with

Internet draft              MEGACO Protocol             January 27, 2000

TerminationIDs.  The TerminationID "*" suffices, two wildcards are ALL and CHOOSE.  The former is referred
used to as
"ALL".  When 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 required, but ident-
ical to repeating the Termination does command with each of the matching TerminationIDs.
Since each of these commands may generate a response, the size of the
entire response may be large.  If individual responses are not
yet exist, required,
a wildcard response may be requested.  In such a case, a single response
is generated, which contains the "CHOOSE" TerminationID "$" UNION of all of the individual
responses which otherwise would have been generated.  Wildcard response
may be used. particularly useful in the Audit commands.

The encoding of the wildcarding mechanism is detailed in Annexes A and
B.

6.2.3.  Packages

Different types of gateways may implement Terminations that have widely
differing characteristics.  Variations in Terminations are accommodated

Internet draft              MEGACO Protocol           September 21, 1999
in the protocol by allowing Terminations to have optional Properties,
Events, Signals and Statistics implemented by MGs.

In order to achieve MG/MGC interoperability, such options are grouped
into Packages, and a Termination realizes a set of such Packages.  More
information on definition of packages can be found in Section section 12.  An
MGC can audit a Termination to determine which Packages it realizes.

Properties, Events, Signals and Statistics defined in Packages, as well
as parameters to them, are referenced by identifiers (Ids).  Identifiers
are scoped. For each package, PropertyIds, EventIds, SignalIds, Statis-
ticsIds and ParameterIds have unique name spaces and the same identifier
may be used in each of them.  Two PropertyIds in different packages may
also have the same identifier, etc.

6.2.4.  Termination Properties and Descriptors

Terminations have properties.  The properties have unique PropertyIDs.
Most properties have default values.  When a Termination is created,
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
this default value.

Internet draft              MEGACO Protocol             January 27, 2000

There are a number of common properties for Terminations and properties
specific to media streams. The common properties are also called the
termination state properties.  For each media stream, there are local
properties and properties of the received and transmitted flows.

Properties not included in the base protocol are defined in Packages.
These properties are referred to by a name consisting of the PackageName
and a PropertyID. PropertyId.  Most properties have default values described in the
Package description. Actual Properties may be read-only or allowed 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 be set
and inspected their values.  A
property may be declared as "Global" which has a single value shared by MGCs.
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 property values read/write
properties can be set by including the appropriate descriptors as parameters param-
eters to the Add com-
mand. 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.

When a Proper-
ties may also have their values changed when a Termination is Subtracted moved from
one Context to another as a Context, properties result of a Move command.  In some cases,
descriptors are reset to
the values they had just prior to the most recent Add returned as output from a command.  The following table
lists all of the possible Descriptors and their use.  Not all descriptors descrip-
tors are legal as input or output parameters to every command.  Descriptors

Internet draft              MEGACO Protocol           September 21, 1999

______________________________________________________________________________  Descrip-
tors

|Descriptor Name|  Description Name   |Description                                         |
|_______________|____________________________________________________________|
|__________________|____________________________________________________|
|Modem          |  Identifies             |Identifies modem type and properties when applicable           |
|_______________|____________________________________________________________|
|Mux
|  Describes                  |applicable                                          |
|__________________|____________________________________________________|
|Mux               |Describes multiplex type for multimedia terminations      | terminations|
|               |   (e.g.                  |(e.g. H.221, H.223, H.225.0) and Terminations forming    |       |
|                  |forming the input mux mux.                              |
|_______________|____________________________________________________________|
|__________________|____________________________________________________|
|Media          |  A             |A list of media stream specifications (see below) 7.1.4)   |
|_______________|____________________________________________________________|
|Events
|__________________|____________________________________________________|
|TerminationState  |Properties of a Termination (which can be defined in|
|  Describes                  |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 MG receives from the remote entity.            |
|__________________|____________________________________________________|
|                  |                                                    |

Internet draft              MEGACO Protocol             January 27, 2000

|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 listened for detected by the MG and what to |  |
|                  |to do when an event is detected                     |
|_______________|____________________________________________________________|
|Signals |__________________|____________________________________________________|
|EventBuffer       |Describes events to be detected by the MG when Event|
|  Describes                  |Buffering is active                                 | |__________________|____________________________________________________|
|Signals           |Describes signals and/or actions to be applied (e.g.      |
|               |   ringback) (e.g.|
|
|_______________|____________________________________________________________|
|Requested Info                  |Busy Tone) to the Terminations                      |  In Audit, |__________________|____________________________________________________|
|Audit             |In Audit commands, identifies which information is desired  |    |_______________|____________________________________________________________|
|Packages
|  In Audit,                  |desired                                             |
|__________________|____________________________________________________|
|Packages          |In AuditValue, returns a list of Packages realized by          |  |
|                  |by a Termination                                    |
|_______________|____________________________________________________________| |__________________|____________________________________________________|
|DigitMap       |  Instructions          |Instructions for handling DTMF tones at the MG      | |_______________|____________________________________________________________|
|__________________|____________________________________________________|
|ServiceChange  |  In     |In ServiceChange, what, why, etc. why service change occurred,|
|
|_______________|____________________________________________________________|
|ObservedEvents                  |etc.                                                |  In Notify,
|__________________|____________________________________________________|
|ObservedEvents    |In Notify or AuditValue, report of events observed  | |_______________|____________________________________________________________|
|__________________|____________________________________________________|
|Statistics     |  In        |In Subtract and Audit, Report of Statistics kept on a     |
| |    Termination                                             |
|_______________|____________________________________________________________|
|Extension
|  Allows inclusion of vendor-specific extensions                  |a Termination.                                      |
|_______________|____________________________________________________________|

Within the Media descriptor, there is the |__________________|____________________________________________________|

6.2.5.  Root Termination State descriptor
and one or more Stream Descriptors.  A stream is identified by

Occasionally, a
streamID.  The streamID is used command must refer to link the streams in a Context that
belong together. Within the Stream Descriptor, there are up to three
subsidiary descriptors, LocalControl, Local and Remote. The relationship
between these descriptors is thus:

Media Descriptor

      TerminalStateDescriptor

      Stream Descriptor

             LocalControl Descriptor

             Local Descriptor

             Remote Descriptor

As a convenience for the audio-only case, a LocalControl, Local or
Remote descriptor may be included in the Media Descriptor without an
enclosing Stream descriptor.  In this case, the StreamID is assumed to
be 1, designating an audio stream.

6.2.5.  Root Termination

Occasionally, a command must refer to the entire gateway, rather than entire gateway, rather than a
termination within it.  A special TerminationID, "ROOT" "Root" is reserved for
this purpose.  A package (MG) defines the properties of  Packages may be defined on Root. Root thus

Internet draft              MEGACO Protocol           September 21, 1999 may have properties pro-
perties and events (signals and statistics  are not appropri-
ate appropriate for root).  Accordingly,  Accord-
ingly, the root terminationID TerminationID may appear in:

*    a Modify command - to change a property or set an event

*    a Notify command - to report an event

*    an AuditValue return - to examine the values of properties imple-
     mented on root

*    an AuditCapability - to determine what properties of root are
     implemented

*    a ServiceChange - to declare the gateway in or out of service Any
     other use of the root terminationID TerminationID is an error.

Internet draft              MEGACO Protocol             January 27, 2000

7.  COMMANDS

The protocol provides Commands commands for manipulating the logical entities of
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
things such as
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 commands are for the specific use of the Media Gateway Controller
as command initiator in controlling Media Gateways as command
responders.  However, there are several Commands for the Media Gateway
to use as command initiator in reporting events that have occurred to
the controller as command responder.

The protocol has commands.  The commands exceptions are sent to the MG by the MGC,
except Notify. Notify and ServiceChange commands:
Notify is sent from Media Gateway to the MGC by the MG.  ServiceChange Media Gateway Controller, and Ser-
viceChange may be sent by either entity to entity.  Below is an overview of the other.
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-
     mand on the first Termination in a Context is used to create a Con-
     text.

2.   Modify. The Modify command modifies the properties, events and sig-
     nals of a termination.

3.   Subtract. The Subtract command disconnects a Termination from its
     Context and returns statistics on the Termination's participation

Internet draft              MEGACO Protocol           September 21, 1999
     in the Context.  The Subtract command on the last Termination in a
     Context deletes the Context.

4.   Move. The Move command atomically moves a Termination to another
     context.

5.   AuditValue. The Audit AuditValue command returns the current state of proper-
     ties, events and
     properties, events,  signals and statistics of Terminations.

6.   AuditCapabilities. The AuditCapabilities command returns all the
     possible values for Termination properties, events and signals
     allowed by the Media Gateway Gateway.

7.   Notify. The Notify command allows the Media Gateway to inform the
     Media Gateway Controller of the occurrence of events in the Media
     Gateway.

8.   ServiceChange. The ServiceChange Command allows the Media Gateway
     to notify the Media Gateway Controller that a Termination or group

Internet draft              MEGACO Protocol             January 27, 2000

     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 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 sections 7.2.1 through 7.2.8

7.1.  Descriptors

The parameters to a command are termed Descriptors. A Descriptor con-
sists of a name and a list of items. Some items may have values.  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.

7.1.1.  Wildcarding Parameter Values in Commands

Some parameter values may be wildcarded in commands.  Two wildcard con-
structs are provided: "all" and "choose".  The "all" construct allows a
Command to specify all possible values of a name component.  For exam-
ple, all Terminations can be subtracted from a Context by means of this
construct.  The "choose" construct allows a command initiator to specify
that it would like the command responder to select and return a possible
value for a parameter.  This mechanism, for example, allows the MGC to
have the MG select a DS0 within a DS1.

Internet draft              MEGACO Protocol           September 21, 1999

7.1.2.  Specifying Parameters

Command parameters are structured into a number of descriptors. In gen-
eral, descriptors are of the form text format of descriptors is
DescriptorName=<someID>{parm=value, parm=value....}

Properties

Parameters may be fully specified, overspecified over-specified or under-specified:

1.   Fully specified parameters have a single, unambiguous value that
     the command initiator is instructing the command responder to use
     for the specified parameter.

2.   Under-specified parameters, using the "choose" CHOOSE value, allow the
     command com-
     mand responder to choose any value it can support.

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.

Unspecified,

Unspecified mandatory parameters (i.e.-mandatory (i.e. mandatory parameters not speci-
fied in any a descriptor) result in the command responder retaining the
previous pre-
vious value for that property.

7.1.3. parameter.  Unspecified optional parameters result
in the command responder using the default value of the parameter. When-
ever a parameter is underspecified or overspecified, the descriptor con-
taining the value chosen by the responder is included as output from the
command.

Each command specifies the TerminationId the command operates on.  This

Internet draft              MEGACO Protocol             January 27, 2000

TerminationId may be "wildcarded".  When the TerminationId of a command
is wildcarded, the effect shall be as if the command was repeated with
each of the TerminationIds matched.

7.1.2.  Modem Descriptor

The Modem descriptor specifies the modem type and parameters, if any. 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.

7.1.4.

7.1.3.  Multiplex Descriptor

In multimedia calls, a number of media streams are carried on a (possi-
bly different) number of bearers.  The multiplex descriptor associates
the media and the bearers. The descriptor includes the multiplex type:

*    H.221

*    H.223,

*    H.226,

*    H.225.0,

*    V.75.    V.76,

*    Possible Extensions (e.g. X-SpecialMux)

Internet draft              MEGACO Protocol           September 21, 1999

and a set of TerminationIDs representing the multiplexed inputs, in
order.  For example:

     Mux {H.225, = H.221{ MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22}

7.1.5.

7.1.4.  Media Descriptor

The Media Descriptor specifies the parameters for all the media streams.
These parameters are structured into two descriptors, a Termination
State Descriptor, which specifies the properties of a termination that
are not stream dependent, and one or more Stream Descriptors each of
which describes a single media stream.

7.1.6.  Termination State Descriptor

A stream is identified by a StreamID.  The Termination State Descriptor contains the TerminationBuffered param-
eter, StreamID is used to link the serviceStates parameter and properties of a termination
(defined
streams in Packages) a Context that belong together. Multiple streams exiting a
termination shall be synchronized with each other. Within the Stream
Descriptor, there are not stream specific.

The TerminationBuffered parameter describes actions taken by the MG when
events are not immediately notified up to the controller.

1.   BufferedEventProcessingMode - specifies whether buffered events
     should be processed three subsidiary descriptors, LocalControl,
Local, and Remote. The relationship between these descriptors is thus:

Internet draft              MEGACO Protocol             January 27, 2000

Media Descriptor
        TerminationStateDescriptor
        Stream Descriptor
                LocalControl Descriptor
                Local Descriptor
                Remote Descriptor

StreamIDs are numbered from 1 upward.  As a convenience a LocalControl,
Local, or discarded.

2.   BufferedEventNotificationMode - specifies whether Remote descriptor may be included in the Media Gateway Descriptor
without an enclosing Stream descriptor.  In this case, the StreamID is expected
assumed to detect be 1.

7.1.5.  Termination State Descriptor

The Termination State Descriptor contains the requested event and notify ServiceStates property,
the controller
     once (step by step) or repeatedly. EventBuffer flag and properties of a termination (defined in Pack-
ages) that are not stream specific.

The serviceStates parameter ServiceStates property describes the overall state of the termina-
tion (not stream-specific).  A Termination can be in one of the following follow-
ing states: "test", "out of service", or "in service".  The "test" state
indicates that the termination is not used for normal traffic, but for
testing.  A Termination with state "test" cannot be seized for traffic.
The state "out of service" indicates a fault in the termination and can-
not be used for traffic.  The state "in service" indicates that a termi-
nation can be used or is being used for normal traffic.  "in service" is
the default state.

7.1.7.  Stream Descriptor

A Stream descriptor specifies

Values assigned to Properties may be simple values
(integer/string/enumeration) or may be underspecified, where more than
one value is supplied and the parameters of MG may make a single bi-directional
media stream.  These parameters are structured into three descriptors,
one that contains termination properties specific to choice:

*    Alternative Values - multiple values in a stream, and list, one
each for local of which must
     be selected

*    Ranges - minimum and remote flows. Stream Descriptor

Internet draft              MEGACO Protocol           September 21, 1999

 ______________________________________________________________________________
|       Parameter       |                   Description                        |
|_______________________|______________________________________________________|
|       StreamID        | Identifies the context stream to be associated       |
|                       |    with this termination media flow (e.g., 1, 2,     |
|                       |    3, ... )                                          |
|_______________________|______________________________________________________|
|LocalControl Descriptor| Contains properties that are of interest 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 and chooses from the MGC                                       |
|_______________________|______________________________________________________|
|   Local Descriptor    | Contains properties that specify allowed values for the Local side of a |
|                       | media flow, and
     property The EventBuffer flag specifies whether events are buffered
     following detection of interest between two MGs      |
|_______________________|______________________________________________________|
|   Remote an event in the Events Descriptor, or pro-
     cessed immediately.  See section 7.1.9 for details.

Internet draft              MEGACO Protocol             January 27, 2000

7.1.6.  Stream Descriptor   | Contains properties that specify

A Stream descriptor specifies the Remote side parameters of  |
|                       | a media flow, and single bi-directional
stream.  These parameters are of interest between two MGs    |
|_______________________|______________________________________________________|

7.1.8.  LocalControl Descriptor

The LocalControl Descriptor structured into three descriptors: one
that contains the Mode parameter and termination properties
of specific to a termination (defined in Packages) that are stream specific, and are
of interest between the MG one each
for local and the MGC. remote flows. The allowed values for Stream Descriptor includes a StreamID
which identifies the mode parameter stream.  Streams are "send only" (sendonly),
"receive only" (recvonly), "send/receive" (sendrecv),  "inactive" (inac-
tive), "loop back" (looback) and "delete" (delete).  "Send" and
"Receive" created by specifiying a new
StreamID on one of the terminations in a Context. Streams are with respect deleted by
setting the Mode property in LocalControl to "delete" on one of the stream within ter-
minations in a termination, so that,
for example, Context.

If a stream set to mode=sendonly can talk but it cannot
listen.

Mode set to delete termination is used moved from one context to remove another, the following
applies:

*    if a streamID of an active stream from a termination.

7.1.9.  Local and Remote Descriptors

The Local and Remote Descriptors contain in the parameters describing moved termination matches
     a streamID in the
flows sent to and received from context it was moved to, the MG, and are associated stream
     remains active on that termination;

*    if a streamID of interest between two
MGs.  They are encoded as SDP strings as specified an active stream in RFC2327, or tag-
value pairs as specified the moved termination does not
     match any streamID in Annex D.  Local is the capability of context it was moved to, the
local MG and is typically sent from MG stream SHALL
     be set to MGC, and subsequently used as
part of inactive;

*    if a capability negotiation between two MGCs.  Remote stream is inactive on the param-
eters describing the flows moved termination, it SHALL remain
     inactive in the remote MG will send/receive, is typically
sent from MCG to MG, and new context until its mode is changed explicitly;

*    the result modes of streams on terminations already present in the capability negotiation.
Between two MGs A and B, MG A receives a negotiated version of MG B's
Local Descriptor as its Remote Descriptor, and MG B receives new
     context are unaffected by the fact that a nego-
tiated version of MG A's Local Descriptor as its Remote Descriptor.

Internet draft              MEGACO Protocol           September 21, 1999

7.1.10.  Events termination is moved into
     the context.

7.1.7.  LocalControl Descriptor

The EventsDescriptor parameter LocalControl Descriptor contains a RequestIdentifier the Mode property, the Reserve pro-
perty and a list properties of events a termination (defined in Packages) that the Media Gateway is requested to detect are
stream specific, and report.  The
RequestIdentifier is used to correlate are of interest between the request with MG and the notifica-
tions that it MGC.  Values
of properties may trigger.  Requested events include, be underspecified as in section  7.1.5

The allowed values for example, fax
tones, continuity tones, the mode property are send-only, receive-only,
send/receive, inactive, loop-back and on-hook delete.  "Send" and off-hook transitions.

Each event in the descriptor contains "receive" are
with respect to the Event name, an optional
Action, and optional parameters.  The Event name consists exterior of a Package
Name (where the event is defined) and an EventID.  Events can have
parameters.  This allows context, so that, for example, a single event description
stream set to have some varia-
tion in meaning without creating large numbers of individual events.
Parameters are defined in mode=sendonly does not pass received media into the package con-
text. Signals and Events are named.  The Action parame-
ter specifies one of several possible actions not affected by mode.  Mode set to take upon the
occurrence of the event:

                            Event Actions
 ______________________________________________________________________________
|NotifyAction        | A Notify message delete
is sent by used to remove a stream from a termination.

The boolean-valued Reserve property of a Termination indicates what the
MG when the Event is    |
|                    | detected                                                |
|____________________|_________________________________________________________|
|AccumulateByValue   | The Event is added expected to do when it receives a  local and/or remote descriptor.

If the Event Buffer                  |
|____________________|_________________________________________________________|
|AccumulateByDigitMap| The Event value of Reserve is processed by True, the specified Digit Map       |
|____________________|_________________________________________________________|

When Accumulate by Digit Map is MG SHALL reserve resources for all
alternatives specified in an Action, a Digit Map or the name local and/or remote descriptors it

Internet draft              MEGACO Protocol             January 27, 2000

currently has resources available for.  It SHALL respond with the alter-
natives it reserves resources for.  If it cannot not support any of a pre- stored DigitMap is specified the
alternatives, it SHALL respond with a reply to the Action parame-
ter.  For example:

     Event=1139 { Line/DTMF {ACTION=AccumulateByDigitMap{GenMap} } }

An Action can also include an Embedded Signals descriptor or an Embedded
Events Descriptor which, if present, is used as a replacement for the
current Signals/Events descriptor.  It is possible, for example, to
specify that the dial-tone Signal be generated when an off-hook Event is
detected, or MGC that the dial-tone Signal be stopped when a digit is
detected. contains
empty local and/or remote descriptors.

If no embedded Signals descriptor the value of Reserve is specified, False, the produc-
tion MG SHALL choose one of Signals continues as the alter-
natives specified in the command.

Only local descriptor (if present) and one level of embedding is permitted.  An embedded Signals Descrip-
tor SHALL NOT contain another embedded Signals Descriptor.  Similarly,
An embedded Events Descriptor SHALL NOT contain another embedded Events
Descriptor.

Internet draft              MEGACO Protocol           September 21, 1999

7.1.11.  Signals Descriptor

A SignalsDescriptor is a parameter that contains the set of signals that
alternatives specified in the Media Gateway is asked to apply remote descriptor (if present).  If the MG
has not yet reserved resources to a Termination.  Signals are named
with a Package name (where support the signal is defined) and a SignalID.

There are three types of signals:

*    on/off - selected alternative, it
SHALL reserve the signal lasts until resources.  If, on the other hand, it is turned off,

*    timeout - already reserved
resources for the signal lasts until Termination addressed (because of a prior exchange
with Reserve equal to True), it is turned off or SHALL release any excess resources it
reserved previously.  Finally, the MG shall send a specific
     period of time elapses,

*    brief - reply to the signal duration is so short MGC con-
taining the alternatives for the local and/or remote descriptor that it will stop on its
     own unless a new signal is applied that causes it to stop; no
     timeout value is needed.

Signals can
selected.  If the MG does not have parameters.  This allows a single signal description sufficient resources to
have some variation in meaning without creating large numbers support any
of indivi-
dual signals.  A common use for this capability the alternatives specified, is to produce signals
such as dialtone that have national variants.

     Signal{ Line/Dialtone{US} } SHALL respond with error 510 (insuffi-
cient resources).

The default value of Reserve is False.

A new SignalDescriptor setting of the LocalControl Descriptor completely replaces any existing SignalDescriptor.  Any sig-
nals applied the
previous setting of that descriptor in the MG.  Thus to retain informa-
tion from the Termination not previous setting the MGC must include that information in
the replacement descriptor are
stopped, and new signals are applied.

7.1.12.  RequestedInfo Descriptor

Audit commands (AuditValue and AuditCapabilities) may specify what
information is to be audited.  The RequestedInfo Descriptor contains setting.  If the
list of descriptors MGC wishes to be returned delete some information from the Audit command.  Possible
items in the RequestedInfo Descriptor are:

                      ____________________
                      | TerminationState  |
                      |___________________|
                      | Modem             |
                      |___________________|
                      | Mux               |
                      |___________________|
                      | Stream            |
                      |___________________|
                      | Events            |
                      |___________________|
                      | Signals           |
                      |___________________|

Internet draft              MEGACO Protocol           September 21, 1999

                     | ObservedEvents            |
                     |___________________________|
                     | DigitMap                  |
                     |___________________________|
                     | Statistics                |
                     |___________________________|
                     | Extension (e.g. X-Special)|
                     |___________________________|

7.1.13.  ServiceChange Descriptor

The ServiceChangeDescriptor contains
existing descriptor, it merely resends the following parameters:

*    ServiceChangeMethod

*    ServiceChangeReason

*    Port

*    Delay

*    Version

*    MGCIdToTry

7.1.14.  DigitMap Descriptor

A DigitMap is descriptor (in a dialing plan resident in Modify com-
mand) with the Media Gateway used for
detecting unwanted information stripped out

7.1.8.  Local and reporting digit events received on a Termination. Remote Descriptors

The
DigitMap Descriptor contains a DigitMap name MGC uses Local and the DigitMap Remote descriptors to be
assigned.  A digit map may be preloaded into the reserve and commit MG by management action
resources for media decoding and referenced by name encoding for the given Stream(s) and
Termination to which they apply.  The MG includes these descriptors in an EventDescriptor, may be defined dynamically
its response to indicate what it is actually prepared to support.  The
MG SHALL include additional properties and subsequently referenced their values in its response
if these properties are mandatory yet not present in the requests made
by name, or the actual digitmap itself may
be MGC (e.g., by specifying detailed video encoding parameters where
the MGC only specified in the EventDescriptor.

DigitMaps defined in a DigitMapDescriptor can occur in any of payload type).

Local refers to the stan-
dard Termination manipulation Commands of media received by the protocol.  A DigitMap,
once defined, can be used on all Terminations specified MG and Remote refers to the
media sent by the (possibly
wildcarded) TerminationID in such a command. MG.

When a DigitMap is text encoding the protocol, the descriptors consist of session
descriptions as defined
dynamically in a DigitMap Descriptor:

*    A new DigitMap is created by specifying a name SDP (RFC2327), except that is not yet
     defined.  The value the "s=", "t=" and
"o=" lines are optional. When multiple session descriptions are provided
in one descriptor, the "v=" lines are required as delimiters; otherwise
they are optional.  Implementations shall be present.

*    A DigitMap value is updated by supplying a new value for a name accept session descriptions
that is already defined. are fully conformant to RFC2327. When binary encoding the protocol
the descriptor consists of groups of properties (tag-value pairs) as

Internet draft              MEGACO Protocol           September 21, 1999

*    A DigitMap is deleted by supplying an empty value for a name that
     is already defined.

The collection of digits according to a DigitMap             January 27, 2000

specified in Annex C.  Each such group may be protected by
three timers, viz. a start timer, short timer, and long timer.

1.   The start timer is used prior to any digits having been dialed.

2.   If contain the Media Gateway can determine that at least one more digit is
     needed for a digit string to match any parameters of the allowed patterns in
     the digit map, then the interdigit timer value should be set to a
     long duration (e.g.-16 seconds).

3.   If
session description.

Below, the DigitMap specifies that a variable number semantics of additional
     digits may be needed then the short timer is used.

The timers local and remote descriptors are configurable parameters to a DigitMap. specified
in detail.  The formal syntax specification consists of two parts.  The first part
specifies the digit map is described by the DigitMap rule in interpretation of the formal syntax description contents of the protocol (See Annex A descriptor.  The
second part specifies the actions the MG must take upon receiving the
local and Annex B).
A DigitMap, according remote descriptors.  The actions to this syntax, is defined either by a string or taken by a list of strings. Each string in the list is an alternative number-
ing scheme, specified either as a set of digits or timers, or as regular
expression. A MG that detects digits, letters or timers while a DigitMap
is active SHALL:

1.   Add depend on
the event parameter to value of the end Reserve property of an internal state variable
     called the "current dial string"

2.   Apply LocalControl descriptor.

Either the current dial string to local or the DigitMap, attempting a match
     to each regular expression 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 proper-
     ties.

Where the DigitMap in lexical order

3.   If descriptors have been passed from the result is under-qualified (partially matches at least one
     entry in MGC to the DigitMap), do nothing further.

4.   If MG, they are
interpreted according to the result matches, rules given in section 7.1.1, with the fol-
lowing additional comments for clarification:

a)   An unspecified Local or Remote descriptor is over-qualified (i.e. no further digits
     could possibly produce considered to be a match), send
     missing mandatory parameter.  It requires the current dial string MG to
     the MGC.

Note that unexpected timers, use whatever
     was last specified for example, can cause over-qualified
matches.

7.1.15.  Statistics Descriptor

The Statistics parameter provides information describing that descriptor.  It is possible that there
     was no previously-specified value, in which case the status and
usage descriptor
     concerned is ignored in further processing of the command.

b)   An empty Local (Remote) descriptor in a Termination during its existence within a specific Context.
There is message from the MGC signi-
     fies a set of standard statistics kept request to release any resources reserved for each termination where
appropriate (number of octets sent and the media flow
     received for example).  The

Internet draft              MEGACO Protocol           September 21, 1999

particular statistical (sent).

c)   If multiple groups of properties that are reported for present in a given Termina-
tion are determined by Local or Remote
     descriptor, the Packages realized order of preference is descending.

d)   Underspecified or overspecified properties within a group of pro-
     perties sent by the Termination.
Statistics MGC are reported when the Termination is Subtracted from the Con-
text.  Statistics may also be returned from requests for  the AuditValue command.

7.1.16.  Topology Descriptor

A topology descriptor MG to choose a value
     which it can support for each of those properties.  In case of an
     overspecified property, the list of values is used specify flow directions between termina-
tions in a conference. Contrary descending order
     of preference.

Subject to the descriptors above rules, subsequent action depends on the value of
the "Reserve" parameter in previous sections, LocalControl.

Internet draft              MEGACO Protocol             January 27, 2000

If Reserve is true, the topology descriptor applies MG reserves the resources required to a Context instead support
any of the alternatives that it can currently support.

NOTE - If a Termination.
The default topology Local or Remote descriptor contains multiple groups of a Context is that pro-
perties, the MG is requested to reserve resources so that each termination's
transmission is received by all other terminations.  The Topology
Descriptor optional it can decode
or encode one media stream according to implement.

A topology descriptor consists of a sequence of  triples any of the form
(T1, T2, association). T1 alternatives.  For
instance, if the Local descriptor contains two groups of properties, one
specifying packetized G.711 A-law audio and T2 specify Terminations within the Con-
text, possibly using other G.723.1 audio, the ALL wildcard.
MG reserves resources so that it can decode one audio stream encoded in
G.711 A-law format or G.723.1 format.  The association specifies how
media flows between these MG should not reserve
resources to Terminations as follows. decode two audio streams, one encoded in G.711 A-law and
one in G.723.1.

*    (T1, T2, isolate) means that the Terminations matching T2 do not
     receive media from    If the Terminations matching T1, nor vice versa.

*    (T1, T2, oneway) means that MG has insufficient resources to support all alternatives
     requested by the Terminations that match T2 receive
     media from MGC and the Terminations matching T1, but not vice versa.  In
     this case it is not allowed to use wildcards such that there are
     Terminations that match MGC requested resources in both T1 Local
     and T2. Remote,  the MGC should reserve resources to support at least
     one alternative each within Local and Remote.

*    (T1, T2, bothway) means that    If the Terminations matching T2 receive
     media MG has insufficient resources to support at least one alter-
     native  within a Local  (Remote) descriptor received from the Terminations matching T1, and vice versa.  In this
     case MGC,
     it is allowed shall return an empty Local (Remote) in response.

*    In its response to use wildcards such that there are Termina-
     tions that match both T1 the MGC, the MG SHALL include local and T2.  However, if there is a Termina-
     tion that matches both, no loopback remote
     descriptors for all groups of properties it reserved resources for.
     If the MG is introduced; loopbacks are
     created by setting incapable of supporting at least one of the TerminationMode.

The Figure below and alterna-
     tives within the Table following Local (Remote) descriptor received from the MGC,
     it show some examples SHALL return an empty Local (Remote) descriptor.

*    If the Mode property of the
effect TerminationState descriptor is RecvOnly
     or SendRecv, the MG must be prepared to receive media encoded
     according to any of including topology descriptors the alternatives included in commands.

Internet draft              MEGACO Protocol           September 21, 1999

               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

         +------------------+  +------------------+  +------------------+
         |      +----+      |  |      +----+      |  |      +----+      |
         |      | T2 |      |  |      | T2 |      |  |      | T2 |      |
         |      +----+      |  |      +----+      |  |      +----+      |
         |          |       |  |          ^       |  |       ^  ^       |
         |          |       |  |          |       |  |       |  |       |
         |          +--+    |  |          +---+   |  |    +--+  +--+    |
         |             |    |  |              |   |  |    |        |    |
         |             v    |  |              v   |  |    v        v    |
         | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
         | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |
         | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
         +------------------+  +------------------+  +------------------+
          1. T2, T3 oneway      2. T2, T3 bothway     3. T1, T2 bothway

                            Figure 4: Example topologies

Internet draft              MEGACO Protocol           September 21, 1999

 __________________________________________________________________________
|Topology|  Description                                                    |
|________|_________________________________________________________________|
|1       |  No topology descriptors.                                       |
|        |                                                                 |
|        |  When no topology descriptors included, all terminations have a |
|        |  both way connection to all other terminations.                 |
|________|_________________________________________________________________|
|2       |  T1, T2, Isolated.                                              |
|        |                                                                 |
|        |  Removes the connection between T1 and T2.                      |
|        |  T3 has a both way connection with both T1 and T2.  T1 and T2   |
|        |  have bothway connection to T3.                                 |
|________|_________________________________________________________________|
|3       |  T3, T2, oneway.                                                |
|        |                                                                 |
|        |  A oneway connection from T3 to T2 (i.e. T2 receives media flow |
|        |  from T3).  A bothway connection between T1 and T3.             |
|________|_________________________________________________________________|
|4       |  T2, T3, oneway.                                                |
|        |                                                                 |
|        |  A oneway connection between T2 to T3.  T1 and T3 remain        |
|        |  bothway connected                                              |
|________|_________________________________________________________________|
|5       |  T2, T3 bothway.                                                |
|        |                                                                 |
|        |  T2 is bothway connected to T3.  This results in the same as 2. |
|________|_________________________________________________________________|
|6       |  T1, T2 bothway.                                                |
|        |                                                                 |
|        |  All terminations are considered connected to each other.       |
|        |  This is the same as 1.                                         |
|________|_________________________________________________________________|

A topology change is performed by including a topology descriptor in an
Add or Modify command.  Allowing a topology descriptor in an Add command
facilitates addition of a Termination to a Context and setting the
topology in one atomic action.

When the topology is included in the "Add" command, then either "Ter-
minationA" or "TerminationB" shall be of value "*" to indicate the ter-
mination being added to the context.

7.2.  Command Application Programming Interface

Following is an Application Programming Interface (API) describing the
Commands of the protocol.  This API is shown to illustrate the Commands
and their parameters and is not intended to specify implementation
(e.g.-via use of blocking function calls).  It will describe the input
parameters in parentheses after the command name and the return values
in front of the Command. This is only for descriptive purposes; the

Internet draft              MEGACO Protocol           September 21, 1999

actual Command syntax and encoding are specified in later subsections.
All parameters enclosed by square brackets ([. . . ]) are considered
optional.

7.2.1.  Add

The Add Command adds a Termination to a Context.

[TerminationID]
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
      Add( TerminationID
        [, MediaDescriptor]
        [, ModemDescriptor]
        [, MuxDescriptor]
        [, EventsDescriptor]
        [, SignalsDescriptor]
        [, DigitMapDescriptor]
        [, AuditDescriptor]
      )

The TerminationID specifies the termination to be added to the Context.
For an existing Termination, the TerminationID would be specific.  For a
Termination which 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.

The optional MediaDescriptor describes all media streams.

The optional ModemDescriptor and MuxDescriptor specify a modem and mul-
tiplexer if applicable. For convenience, if a Multiplex Descriptor is
present in an Add command and lists any Terminations that are not
currently in the Context, such Terminations are added its response to
     the context as
if individual Add commands listing the Terminations were invoked.

The EventsDescriptor parameter is optional. MGC.

If present, it provides Reserve is False then the
list of events that should be detected on MG SHOULD apply the Termination.

Internet draft              MEGACO Protocol           September 21, 1999

The SignalsDescriptor parameter is optional. following rules to
resolve Local and Remote to a single alternative each:

*    If present, it provides symmetric coding is not possible, the list of signals that should be applied to MG chooses the Termination.

The DigitMapDescriptor parameter is optional.  If present, defines a
DigitMap definition that may be used first
     alternative in an EventsDescriptor.

The AuditDescriptor Local for which it is optional.  If present, the command will return
descriptors as specified able to support at least one
     alternative in Remote.

*    If the AuditDescriptor.

7.2.2.  Modify MG is unable to support at least one Local and one Remote
     alternative, it returns Error 510 (Insufficient Resources).

*    The Modify Command modifies the properties MG returns its selected alternative in Local and Remote.

A new setting of a Termination.

        [TerminationID]
        [,MediaDescriptor]
        [,ModemDescriptor]
        [,MuxDescriptor]
        [,EventsDescriptor]
        [,SignalsDescriptor]
        [,DigitMapDescriptor]
        [,ObservedEventsDescriptor]
        [,StatisticsDescriptor]
        [,PackagesDescriptor]
             Modify( TerminationID
                   [, MediaDescriptor]
                   [, ModemDescriptor]
                   [, MuxDescriptor]
                   [, EventsDescriptor]
                   [, SignalsDescriptor]
                   [, DigitMapDescriptor]
                   [, AuditDescriptor]
             )

The TerminationID may be specific if a single Termination in Local or Remote Descriptor completely replaces the Context
is to be modified. Use
previous setting of wildcards that descriptor in the TerminationID may be
appropriate for some operations. MG.  Thus to retain informa-
tion from the previous setting the MGC must include that information in

Internet draft              MEGACO Protocol             January 27, 2000

the new setting.  If the wildcard matches more than one
TerminationID, all possible matches are attempted, MGC wishes to delete some information from the
existing descriptor, it merely resends the descriptor (in a Modify com-
mand) with results reported
for each one. the unwanted information stripped out.

7.1.9.  Events Descriptor

The order EventsDescriptor parameter contains a RequestIdentifier and a list
of attempts when multiple TerminationIDs match events that the Media Gateway is not specified. requested to detect and report.  The "choose" option
RequestIdentifier is an error, as modify may only be used on existing Terminations.

The remaining parameters to Modify are correlate the same as those to Add.  The
Media Descriptor is optional request with the notifica-
tions that it may trigger.  Requested events include, for Modify.

7.2.3.  Subtract

The Subtract Command disconnects a Termination from its Context example, fax
tones, continuity tones, and

Internet draft              MEGACO Protocol           September 21, 1999

returns statistics on the Termination's participation on-hook and off-hook transitions.

Each event in the Context.

        [TerminationID]
        [,MediaDescriptor]
        [,ModemDescriptor]
        [,MuxDescriptor]
        [,EventsDescriptor]
        [,SignalsDescriptor]
        [,DigitMapDescriptor]
        [,ObservedEventsDescriptor]
        [,StatisticsDescriptor]
        [,PackagesDescriptor]
              Subtract(TerminationID
                    [, AuditDescriptor]
              )

TerminationID in descriptor contains the input parameters represents Event name, an optional
streamID, an optional KeepActive flag, and optional parameters.  The
Event name consists of a Package Name (where the Termination that event is
being subtracted. defined) and
an EventID. The TerminationID may be specific or ALL wildcard may be a wild-
card value used for the EventID, indicating
that all (or events from the specified package have to be detected.  The
default streamIDis 0, indicating that the event to be detected is not
related to a set particular media stream. Events can have parameters.  This
allows a single event description to have some variation in meaning
without creating large numbers of related) Terminations individual events.  Further event
parameters are defined in the
Context of the Subtract Command are package.

The MG shall send a Notify command 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 MGC when multiple
TerminationIDs match is not specified. The "choose" option it detects an event
in the Events Descriptor.  If the EventBuffer flag is "on", following
detection of such an error,
as subtract may only be used on existing Terminations.

The Statistics parameter event, normal handling of events is returned to report information collected on
the Termination or Terminations specified suspended, and
any event found in the Command.  The informa-
tion reported applies EventBuffer Descriptor which is subsequently
detected is added to the Termination's or Terminations' existence in end of a FIFO queue, along with the Context from which time that
it or they are being subtracted.

The AuditDescriptor was detected.   A command containing an Events Descriptor which is optional.  If present,
received  when the command will return
descriptors as specified in EventBuffer flag is on causes the AuditDescriptor.

7.2.4.  Move

The Move Command moves a Termination following sequence
to another Context from its current
Context in one atomic operation.

        [TerminationID]
        [,MediaDescriptor]
        [,ModemDescriptor]
        [,MuxDescriptor]
        [,EventsDescriptor]
        [,SignalsDescriptor]
        [,DigitMapDescriptor]
        [,ObservedEventsDescriptor]
        [,StatisticsDescriptor]

Internet draft              MEGACO Protocol           September 21, 1999

        [,PackagesDescriptor]
                  Move( TerminationID
                     [, MediaDescriptor]
                     [, ModemDescriptor]
                     [, MuxDescriptor]
                     [, EventsDescriptor]
                     [, SignalsDescriptor]
                     [, DigitMapDescriptor]
                     [, AuditDescriptor]
                  ) be executed:

1.   The TerminationID specifies first event in the Termination to be moved.  It may be
wildcarded. FIFO queue is examined.  If it is in the wildcard matches more than one TerminationID, all
possible matches are attempted, with results reported for each one.
     Events listed in the new events descriptor, the MG shall send a
     Notify command to the MGC and remove the event from the FIFO queue.
     The
order time stamp of attempts when multiple TerminationIDs match the Notify shall be the time the event was actu-
     ally detected.

2.   If the event is not specified.
By convention, in the Termination new Events Descriptor, it shall be dis-
     carded.

3.   If the queue is subtracted from its previous Context.

The remaining descriptors empty, the sequence shall be stopped, and normal
     event processing shall be resumed.  If there are processed as any events remain-
     ing in the Modify Command.  The
AuditDescriptor with queue, the Statistics option, for example, would return
statistics on sequence repeats.

If the Termination just prior to EventBuffer flag is off when the Move.

7.2.5.  AuditValue

The AuditValue Command returns new Events Descriptor is
received, the current values of properties, events,
signals queue is flushed, and statistics associated with Terminations.

        [TerminationID]
        [,MediaDescriptor]
        [,ModemDescriptor]
        [,MuxDescriptor]
        [,EventsDescriptor]
        [,SignalsDescriptor]
        [,DigitMapDescriptor]
        [,ObservedEventsDescriptor]
        [,StatisticsDescriptor]
        [,PackagesDescriptor]
              AuditValue(TerminationID,
                         AuditDescriptor
              )

TerminationID may be specific or wildcarded. If the wildcard matches
more than one TerminationID, all possible matches no events are attempted, with
results reported for each one. added to it.  The order of attempts when multiple Ter-
minationIDs match is not specified. Use
default state of "choose" EventBuffer is an error.

The appropriate descriptors, with the current values for the off.

Internet draft              MEGACO Protocol           September 21, 1999

Termination, are returned from AuditValue.  ObservedEvents returns a
list             January 27, 2000

Normally, detection of events an event shall cause any active signals to stop.
When KeepActive is specified in the EventBuffer (BufferedEventDescriptor returns Buf-
ferMode and ProcessingMode).  PackagesDescriptor returns a list of pack-
ages realized by event, the MG shall not interrupt
any signals active on the Termination on which the event is detected.

An event can include an Embedded Signals descriptor and/or an Embedded
Events Descriptor which, if present, replaces the Termination.

AuditValue results depend on current Signals/Events
descriptor when the Context, viz. Specific, null, or
unspecified.  The TerminationID may event is detected.  It is possible, for example, to
specify that the dial-tone Signal be specific, generated when an off-hook Event is
detected, or wildcarded.

The following illustrates other information that can be obtained with the Audit Command:

 ______________________________________________________________________________
|ContextID  |  TerminationID|  Information Obtained                            |
|Specific   |  all          |  List of Terminations in a Context               |
|Specific   |  wildcard     |  List of matching Terminations in a Context      |
|Specific   |  specific     |  Audit of a single Termination in dial-tone Signal be stopped when a Context      |
|Null       |  Root         |  Audit of Media Gateway state digit is
detected.  A media gateway controller shall not send EventsDescriptors
with an event both marked KeepActive and events         |
|Null       |  all          |  List of all Terminations in the Media Gateway   |
|Null       |  wildcard     |  List of all matching Terminations               |
|Null       |  specific     |  Audit containing an embedded Sig-
nalsDescriptor.

Only one level of embedding is permitted.  An  embedded EventsDescriptor
SHALL NOT contain another embedded EventsDescriptor.

An Events Descriptor received by a single Termination in outside of media gateway replaces any |
|           |                      Context                                     |
|Unspecified|  Root         |  Audit of Media Gateway state and events         |
|Unspecified|  all          |  List of all Terminations previous
Events Descriptor. Event notification in the Media Gateway   |
|           |               | process shall complete, and
events detected after the Context(s) to which they are associated |
|Unspecified|  wildcard     |  List of all matching Terminations and command containing the       |
|           |               |      Context to which they are associated        |
|___________|_______________|__________________________________________________|

7.2.6.  AuditCapabilities

The AuditCapabilities Command returns new EventsDescriptor
executes, shall be processed according to the possible values new EventsDescriptor.

7.1.10.  EventBuffer Descriptor

The EventBuffer Descriptor contains a list of properties, events, signals and statistics associated with Terminations.

        [TerminationID]
        [,MediaDescriptor]
        [,ModemDescriptor]
        [,MuxDescriptor]
        [,EventsDescriptor]
        [,SignalsDescriptor]
        [,DigitMapDescriptor]
        [,ObservedEventsDescriptor]
        [,StatisticsDescriptor]
        [,PackagesDescriptor]
             AuditCapabilities(TerminationID,
                               AuditDescriptor
             )

The appropriate descriptors, with their parame-
ters if any, that the possible values for the Termina-
tion are returned from AuditCapabilities.  Descriptors may be repeated

Internet draft              MEGACO Protocol           September 21, 1999

where there are multiple possible values.

Interpretation of what capabilities are MG is requested for various values of
ContextID to detect and TerminationID buffer when no
Events Descriptor is active  (See 7.1.9).

7.1.11.  Signals Descriptor

A SignalsDescriptor is a parameter that contains the same as in AuditValue.

7.2.7.  Notify

The Notify Command allows set of signals that
the Media Gateway is asked to notify the Media Gateway
Controller apply to a Termination. A SignalsDescrip-
tor contains a number of events occurring within the Media Gateway.

                Notify(TerminationID,
                           ObservedEventsDescriptor)

The TerminationID parameter specifies the Termination issuing signals and/or sequential signal lists.  A Sig-
nalsDescriptor may contain zero signals and sequential signal lists.
Support of sequential signal lists is optional.

Signals are defined in packages.  Signals shall be named with a Package
name (in which the Notify
Command.  The TerminationID signal is defined) and a SignalID.  No wildcard shall
be used in the SignalID.  Signals that occur in a fully qualified name.

The ObservedEventsDescriptor contains SignalsDescriptor have
an optional StreamID parameter (default is 0, to indicate that the RequestID 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, there is an optional parameter
"notifyCompletion" that allows a list MGC to request being notified of com-
pletion of events
that the Media Gateway detected in the order that they were detected. signal.  The RequestID returns the RequestID parameter value of the EventsDescriptor
that triggered the Notify Command.  It this parameter is used a RequestIdentif-
ier, allowing the MGC to correlate the notifi-
cation Notify with the request that triggered it. corresponding
signal.

Internet draft              MEGACO Protocol             January 27, 2000

The events duration is an integer value that is expressed in the list must
have been requested via the RequestedEvents parameter hundredths of a
second.

There are three types of signals:

*    on/off - the triggering
EventsDescriptor.  The list must contain signal lasts until it is turned off,

*    timeout - the events that were either
accumulated (but not notified) signal lasts until it is turned off or treated according to digit map (but no
match found yet) and well as a specific
     period of time elapses,

*    brief - the final event signal duration is so short that triggered the detec-
tion or provided it will stop on its
     own unless a final match in the digit map.  Each event in the list new signal is accompanied by properties associated with the event and an indication
of the time applied that the event was detected.  Unsolicited Notify Commands
are not possible.

7.2.8.  ServiceChange

The ServiceChange Command allows the Media Gateway causes it to notify stop; no
     timeout value is needed.

If the Media
Gateway Controller that signal type is specified in a Termination or group of Terminations SignalsDescriptor, it overrides the
default signal type (see Section 12.1.4). If duration is about
to specified for
an on/off signal, it SHALL be taken out ignored.

A sequential signal list consists of a signal list identifier, a
sequence of service or has just been returned signals to service.  It
also allows be played sequentially, and a MGC to hand over control signal type.  Only
the trailing element of a MG to another MGC.

        [ServiceChangeDescriptor]
              ServiceChange(TerminationID,
                            ServiceDescriptor
              )

The TerminationID parameter specifies the Termination(s) that are taken
out sequence of or returned to service.  Wildcarding signals in a sequential signal
list may be an on/off signal.  If the trailing element of Termination names the sequence
is
quite useful here, with an on/off signal, the exception that signal type of the "choose" mechanism sequential signal list shall
not
be used.  Use of on/off as well.  If the "Root" TerminationID indicates sequence of signals in a ServiceChange

Internet draft              MEGACO Protocol           September 21, 1999

affecting the entire Media Gateway.

The ServiceDescriptor sequential signal
list contains signals of type timeout and the following parameters:

*    ServiceChangeMethod

*    ServiceChangeReason

*    ServiceChangeDelay

*    Port

*    Profile

*    MGCIdToTry

The ServiceChangeMethod parameter specifies trailing element is not of
type on/off, the type of ServiceChange
that will or has occurred:

1.   Graceful - indicates that the specified Terminations will sequential signal list SHALL be taken
     out set to
timeout.  The duration of service after a sequential signal list with type timeout is
the specified ServiceChangeDelay; established
     connections are not yet affected, but sum of the Media Gateway Controller
     should refrain from establishing new connections and should attempt
     to gracefully tear down existing connections IP P

2.   Forced - indicates that durations of the specified Terminations were taken
     abruptly out signals it contains.  If the sequence of service and any established connections associated
     with them were lost

3.   Restart - indicates that service will be restored on
signals in a sequential signal list contains only signals of type brief,
the specified
     Terminations after expiration type of the sequential signal list SHALL be set to brief.  A signal
list is treated as a single signal of the ServiceChangeDelay; specified type when played
out.

Multiple signals and sequential signal lists in the Termi-
     nations are assumed to now not same SignalsDescrip-
tor shall be associated with any Context

4.   Disconnected - always applied with the Root TerminationID, indi-
     cates that played simultaneously.

Signals are defined as proceeding from the MG lost communication with termination towards the MGC, but it was sub-
     sequently restored.  Since MG state may have changed, exte-
rior of the MGC may
     wish to use Context unless otherwise specified in a package.  When the Audit command
same Signal is applied to resynchronize its state with multiple Terminations within one Transaction,
the
     MG's.

5.   Handoff - sent from MG should consider using the MGC same resource to the MG, this reason indicates that
     the MGC generate these Sig-
nals.

Production of a Signal on a Termination is going out stopped by application of service and a
new MGC association must be
     established.

The ServiceChangeReason parameter specifies the reason why the Servi-
ceChange has SignalsDescriptor, or will occur.  It consists detection of an alphanumeric token (IANA
registered) and an explanatory string.

The optional Port parameter specifies Event on the port number Termination (see
section 7.1.9).

A new SignalsDescriptor replaces any existing SignalsDescriptor.  Any
signals applied to be used for the Termination not in the replacement descriptor

Internet draft              MEGACO Protocol           September 21, 1999

subsequent communications.  It can             January 27, 2000

shall be specified stopped, and new signals are applied. Signals present in both
the existing and replacement descriptor, with the same parameters in
both, shall be continued.  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
     list in the input parameter
descriptor or replacement descriptor shall be ignored, and

*    the playing of the returned result descriptor.

The optional ServiceChangeDelay parameter is expressed signals in seconds.  If the delay is absent or set to zero sequential signal list in the delay value should be considered
to
     existing descriptor shall not be null.  In interrupted.

If the case MGC requested notification of completion for a "graceful" ServiceChangeMethod, signal, a null
delay indicates that the Media Gateway Controller should wait for Notify
command SHALL be sent by the
natural removal MG upon completion of existing connections and should not establish new
connections.  The ServiceChangeDelay is always considered null in that signal.  A
Notify triggered by completion of a signal SHALL NOT affect the
case state of
the "forced" method. eventbuffer or any active events descriptor.

7.1.12.  Audit Descriptor

Specifies what information is to be audited.  The Profile parameter Audit Descriptor
specifies the Profile (if any) list of descriptors to be returned.  Audit may be used in
any command to force the protocol
supported.  The Profile includes the version return of a descriptor even if the profile supported.

A ServiceChange Command specifying descriptor
in the "Root" for command was not present, or had no underspecified parameters.
Possible items in the TerminationID Audit Descriptor are:

                            ________________
                           | Modem         |
                           |_______________|
                           | Mux           |
                           |_______________|
                           | Events        |
                           |_______________|
                           | Media         |
                           |_______________|
                           | Signals       |
                           |_______________|
                           | ObservedEvents|
                           |_______________|
                           | DigitMap      |
                           |_______________|
                           | Statistics    |
                           |_______________|
                           | Packages      |
                           |_______________|
                           | EventBuffer   |
                           |_______________|

Internet draft              MEGACO Protocol             January 27, 2000

Audit may be empty, in which case, no descriptors are returned.  This is
useful in Subtract, to inhibit return of statistics, especially when
using wildcard.

7.1.13.  ServiceChange Descriptor

The ServiceChangeDescriptor contains the following parameters:

*    ServiceChangeMethod

*    ServiceChangeReason

*    ServiceChangeAddress

*    ServiceChangeDelay

*    Profile

*    Version

*    MGCIdToTry

*    TimeStamp

See section 7.2.8

7.1.14.  DigitMap Descriptor

A DigitMap is a
registration command by which a Media Gateway announces its existence to dialing plan resident in the Media Gateway Controller. used for
detecting and reporting digit events received on a Termination.  The Media Gateway is expected to be pro-
visioned with the
DigitMap Descriptor contains a DigitMap name of one primary and some number of alternate Media
Gateway Controllers.  The ServiceChangeMethod shall be "forced" for this
usage.  Acknowledgement of the ServiceChange Command completes the
registration process.  Normally, the MG will specify the transport port
number DigitMap to be used by the MGC for sending messages in the Port parameter
in the input ServiceChangeDescriptor.  The MGC specifies the port number
for
assigned.  A digit map may be preloaded into the MG to use by management action
and referenced by name in the returned result ServiceDescriptor.

The Media Gateway Controller an EventsDescriptor, may return a MGCIdToTry parameter that
describes the Media Gateway Controller that should preferably be con-
tacted for further service defined dynami-
cally and subsequently referenced by name, or the Media Gateway.  In this case the Media
Gateway shall reissue the ServiceChange command to the new Media Gateway
Controller.   The Gateway actual digitmap itself
may be specified in the EventsDescriptor.

DigitMaps defined in a MGCIdToTry, if provided, shall
be contacted before DigitMapDescriptor can occur in any further alternate MGCs.  On a HandOff message
from MGC to MG, the MGCIdToTry is of the new MGC that will take over from stan-
dard Termination manipulation Commands of the current MGC.

7.2.9.  Generic Command Syntax

The protocol protocol.  A DigitMap,
once defined, can be encoded in a binary format or in a text format.
MGCs should support both encoding formats.  MGs may support both for-
mats.

The protocol syntax used on all Terminations specified by the (possibly
wildcarded) TerminationID in such a command.  When a DigitMap is defined
dynamically in Annex A. a DigitMap Descriptor:

*    A complete ABNF of the text encoding of the protocol per RFC2234 new DigitMap is
given in Annex B. created by specifying a name that is not yet
     defined.  The mechanism value shall be present.

*    A DigitMap value is updated by supplying a new value for binary encoding a name
     that is specified in Annex C. already defined.  Terminations presently using the digitmap
     shall continue to use the old definition; subsequent

Internet draft              MEGACO Protocol           September 21, 1999

7.3.  Command Error Codes

Errors consist of an IANA registered alphanumeric token and             January 27, 2000

     EventsDescriptors specifying the name, including any EventsDescrip-
     tor in the command containing the DigitMap descriptor, shall use
     the new one.

*    A DigitMap is deleted by supplying an explana-
tory string.

The identified error codes are:

Note: we need empty value for a name that
     is already defined. Terminations presently using the digitmap shall
     continue to renumber use the error codes.

400 - Bad Request
401 - Protocol Error
402 - Unauthorized
403 - Syntax Error in Transaction
410 - Incorrect identifier
411 - old definition.

The transaction refers collection of digits according to an unknown ContextId
412 - No ContextIDs available
420 - No such Event or signal in this package
421 - Unknown action or illegal combination a DigitMap may be protected by
three timers, viz. a start timer (T), short timer (S), and long timer
(L).

1.   The start timer (T) is used prior to any digits having been dialed.

2.   If the Media Gateway can determine that at least one more digit is
     needed for a digit string to match any of actions
422 - Syntax Error the allowed patterns in Action
430 - Unknown TerminationID
431 - No TerminationID matched
     the digit map, then the interdigit timer value should be set to a wildcard
432 - Out
     long (L) duration (e.g.-16 seconds).

3.   If the DigitMap specifies that a variable number of TerminationIDs or No TerminationID available
433 - TerminationID additional
     digits may be needed then the short timer (S) is already in used.

The timers are configurable parameters to a Context
440 - Unsupported or unknown Package
441 - Missing RemoteDescriptor
442 - Syntax Error in Command
443 - Unsupported or Unknown Command
444 - Unsupported or Unknown Descriptor
445 - Descriptor not legal DigitMap.  The Start timer
is started at the beginning of every digit map use, but can be overrid-
den.

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 command
446 - Descriptor appears twice in syntax, is defined either by a command
450 - No such property in this package
451 - Parameter illegal in this Descriptor
453 - Parameter string or Property appears twice
by a list of strings. Each string in this Descriptor

500 - Internal Gateway Error
501 - Not Implemented
502 - Not ready.
503 - Service Unavailable
510 - Insufficient resources
512 - Gateway unequipped to detect requested Event
513 - Gateway unequipped to generate requested Signals
514 - Gateway cannot send the specified announcement
515 - Unsupported Media Type
517 - Unsupported list is an alternative number-
ing scheme, specified either as a set of digits or invalid mode
518 - Out timers, or as regular
expression of space digits and timers. Within a string, the digits "0" through
"9" and letters "A" through a maximum value depending on the signalling
system concerned, but never exceeding "K", correspond to store digit map
519 - Gateway does not have specified
events within a package which has been designated in the Events Descrip-
tor on the termination to which the digit map
520 - Termination is "ServiceChangeing"
526 - Insufficient bandwidth

Internet draft              MEGACO Protocol           September 21, 1999

529 - Internal hardware failure"
581 - Does Not Exist

8.  TRANSACTIONS

Commands being applied.  (The
mapping between the Media Gateway Controller events and digit map symbols is defined in the Media Gateway are
grouped into Transactions, each documen-
tation for packages associated with channel-associated signalling sys-
tems 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 which
range notation for alternative events.)  The letter "x" is identified by used as a Transac-
tionID.  Transactions consist of one or
wildcard, designating any event corresponding to symbols in the range
"0"-"9".  The string may also contain explicit ranges and, more Actions.  An Action con-
sists gen-
erally, explicit sets of a series symbols, designating alternative events any one
of Commands which satisfies that are limited position of the digit map.

In addition to operating within a
single Context.   Consequently each Action typically specifies these event symbols, the string may contain "S" and "L"

Internet draft              MEGACO Protocol             January 27, 2000

duration modifiers.  An "L" designates a Contex-
tID.  However, there are two circumstances where long event: placed in front of
the symbol(s) designating the event(s) which satisfy a specific ContextID is
not provided with an Action.  One given digit posi-
tion, it indicates that that position is satisfied only if the case of modification duration
of a Ter-
mination outside the event exceeds the long-duration threshold.  The value of this
threshold is assumed to be provisioned in the MG. A MG that detects
digits, letters or timers while a Context.  The other DigitMap is where active SHALL:

1.   Add the controller
requests event parameter to the gateway end of an internal state variable
     referred to create as the "current dial string".

2.   Apply the current dial string to the DigitMap, attempting a new Context.  Following match
     to each regular expression in the DigitMap in lexical order.

3.   If the result is under-qualified (partially matches at least one
     entry in the DigitMap), do nothing further.

4.   If the result matches, or is over-qualified (i.e. no further digits
     could possibly produce a graphic
representation of match), send the Transaction, Action and Command relationships.

          +----------------------------------------------------------+
          | Transaction x                                            |
          |  +----------------------------------------------------+  |
          |  | Action 1                                           |  |
          |  | +---------+  +---------+  +---------+  +---------+ |  |
          |  | | Command |  | Command |  | Command |  | Command | |  |
          |  | |    1    |  |    2    |  |    3    |  |    4    | |  |
          |  | +---------+  +---------+  +---------+  +---------+ |  |
          |  +----------------------------------------------------+  |
          |                                                          |
          |  +----------------------------------------------------+  |
          |  | Action 2                                           |  |
          |  | +---------+                                        |  |
          |  | | Command |                                        |  |
          |  | |    1    |                                        |  |
          |  | +---------+                                        |  |
          |  +----------------------------------------------------+  |
          |                                                          |
          |  +----------------------------------------------------+  |
          |  | Action 3                                           |  |
          |  | +---------+  +---------+  +---------+              |  |
          |  | current dial string to
     the MGC in the digit string parameter of the completion event in
     the DTMF package (see section E.4.2).

Note that unexpected timer expiries, for example, can cause over-
qualified matches.  The MG shall clear the current dial string when
starting a new dial plan specified in an events descriptor or embedded
events descriptor.

As an example, consider the following dial plan:

        _______________________________________________________
       | Command 0                        |  Local operator           | Command
       | 00                       | Command  Long distance operator   |
       | xxxx                     |  Local extension number   |
       | 8xxxxxxx                 |    1  Local number             |
       |    2 #xxxxxxx                 |  Off-site extension       |    3
       | *xx                      |  Star services            |
       | 91xxxxxxxxxx             | +---------+  +---------+  +---------+  Long distance number     |
       | 9011 + up to 15 digits   |  +----------------------------------------------------+  International number     |
          +----------------------------------------------------------+
                  Figure 5 Transactions, Actions
       |__________________________|___________________________|

following digit map:

          (0S| 00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x.S)

7.1.15.  Statistics Descriptor

The Statistics parameter provides information describing the status and Commands

Transactions are presented as TransactionRequests.  Corresponding
responses to
usage of a TransactionRequest are received in Termination during its existence within a single reply.  There specific Context.

Internet draft              MEGACO Protocol           September 21, 1999

are two types of replies,             January 27, 2000

There is a TransactionReply, set of standard statistics kept for each termination where
appropriate (number of octets sent and received for example).  The par-
ticular statistical properties that are reported for a TransactionPending.

Transactions guarantee ordered Command processing.  That is, Commands
within a Transaction given Termination
are executed sequentially. At determined by the first failing
Command Packages realized by the Termination.  By default,
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.
Statistics are reset when a Termination is Subtracted from a Context.

7.1.16.  Packages Descriptor

Used only with the AuditValue command, the PackageDescriptor returns a Transaction, processing
list of Packages realized by the remaining Commands in that
Transaction stops.  If a Termination.

7.1.17.  ObservedEvents Descriptor

ObservedEvents is supplied with the Notify command contains a wildcarded terminationID,
each of to inform the actual TerminatioIDs matching MGC of
which event(s) were detected.  Used with the wildcard is attempted.  A
response within AuditValue command, the TransactionReply is included for each matching Ter-
minationID, even if one or more instances generated an error.  If any
TerminationID matching a wildcard results
ObservedEventsDescriptor returns events in an error when executed, any
commands following the wildcarded command are event buffer which have
not attempted.

A TransactionReply includes been Notified.  ObservedEvents contains the return values for all RequestIdentifier of the Commands in
EventsDescriptor that triggered the corresponding TransactionRequest.  The TransactionReply includes notification, the
return values for event(s) detected
and the Commands detection time(s). If a Notify is sent as a result of a signal
completion, the ObservedEventsDescriptor contains the name of the signal
that were executed successfully, completed and the
Command and error time at which it completed.  Detection times are
reported with a precision of hundredths of a second.  Time is expressed
in UTC.

7.1.18.  Topology Descriptor

A topology descriptor for any Command that failed. Transaction-
Pending is used specify flow directions between termina-
tions in a Context. Contrary to periodically notify the receiver that descriptors in previous sections,
the topology descriptor applies to a Transaction
has not completed yet, but Context instead of a Termination.
The default topology of a Context is actively being processed.

8.1.  Common Parameters

8.1.1.  Transaction Identifiers

Transactions are identified 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
possible to have an action containing only a TransactionID, Topology Descriptor, pro-
vided that the context to which is assigned by
sender and is unique within the scope action applies already exists.

A topology descriptor consists of the sender.

8.1.2.  Context Identifiers

Contexts are identified by a ContextID, which is assigned by sequence of triples of the Media
Gateway form (T1,
T2, association). T1 and is unique T2 specify Terminations within the scope of Context,
possibly using the Media Gateway. ALL or CHOOSE wildcard.  The Media
Gateway Controller shall use association specifies
how media flows between these two Terminations as follows.

Internet draft              MEGACO Protocol             January 27, 2000

*    (T1, T2, isolate) means that the ContextID supplied by Terminations matching T2 do not
     receive media from the Media Gateway
in all subsequent Transactions relating to Terminations matching T1, nor vice versa.

*    (T1, T2, oneway) means that Context.  The protocol
makes reference to two distinguished values the Terminations that may be used by match T2 receive
     media from the
Media Gateway Controller when it has no ContextID to Terminations matching T1, but not vice versa.  In
     this case use in a Transac-
tion:

1.   The "null" Context, which is used to refer to a Termination of the ALL wildcard such that there are Terminations
     that match both T1 and T2 is
     currently not associated with a Context.

2.   The "unspecified" Context, which is used to request allowed.

*    (T1, T2, bothway) means that the Media
     Gateway create a new Context.

8.2.  Transaction Application Programming Interface

Following is an Application Programming Interface (API) describing the
Transactions of the protocol.  This API is shown to illustrate Terminations matching T2 receive
     media from the Tran-
sactions and their parameters Terminations matching T1, and vice versa.  In this
     case it is not intended allowed to specify implementa-
tion (e.g.-via use of blocking function calls).  It will describe the

Internet draft              MEGACO Protocol           September 21, 1999

input parameters wildcards such that there are Termina-
     tions that match both T1 and return values expected to 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 by in T1 and T2 as well, under the various
Transactions of following
restrictions:

*    the protocol from a very high level.  Transaction syntax
and encodings are specified in later subsections.

8.2.1.  TransactionRequest

The TransactionRequest is invoked by action (see section 8) of which the sender.  There topology descriptor is one Transac-
tion per request invocation.  A request part
     contains one or more Actions,
each of an Add command in which specifies its target Context and one or more Commands per
Context.

        TransactionRequest(TransactionId {
               ContextID {Command ... Command},
                                . . .
               ContextID  {Command ... Command } })

The TransactionID parameter must specify a value for later correlation
with the TransactionReply CHOOSE wildcard is used;

*    if a CHOOSE wildcard occurs in T1 or TransactionPending response from the
receiver. T2, then a partial name SHALL
     NOT be specified.

The ContextID parameter must specify CHOOSE wildcard in a value to pertain to all Commands topology descriptor matches the TerminationID
that follow up to either the next specification of a ContextID parameter
or MG assigns in the end of first Add command that uses a CHOOSE wildcard
in the TransactionRequest, whichever comes first.  The Con-
textID may be specific, unspecified, same action.  An existing Termination that matches T1 or null.

The Command parameter represents one of T2 in
the Context to which a Termination is added, is connected to the Commands mentioned in newly
added Termination as specified by the
"Command Details" subsection titled "Application Programming Interface".

8.2.2.  TransactionReply topology descriptor. The TransactionReply default
association when a termination is invoked by not mentioned in the receiver.  There Topology descrip-
tor is one reply
invocation per transaction. A reply contains one or more Actions, each bothway (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 which must specify its target the
effect of including topology descriptors in actions.

Internet draft              MEGACO Protocol             January 27, 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 and one or more Responses per
Context.

        TransactionReply(TransactionID {
              ContextID { Response ... Response },
                       . . .
              ContextID { Response ... Response } })

The TransactionID parameter must specify a keyword value for correlation
with the corresponding TransactionRequest from the sender.

The ContextID parameter must specify a value to pertain to all Responses
for the action.  The ContextID may be specific or null.

Internet draft              MEGACO Protocol           September 21, 1999

Each of the Response parameters represents a return value as mentioned
in Section 7.2, or an error descriptor if the command execution encoun-
tered an error. Commands after the point of failure are not processed
and, therefore, Responses 2           Context 3

         +------------------+  +------------------+  +------------------+
         |      +----+      |  |      +----+      |  |      +----+      |
         |      | T2 |      |  |      | T2 |      |  |      | T2 |      |
         |      +----+      |  |      +----+      |  |      +----+      |
         |          |       |  |          ^       |  |       ^  ^       |
         |          |       |  |          |       |  |       |  |       |
         |          +--+    |  |          +---+   |  |    +--+  +--+    |
         |             |    |  |              |   |  |    |        |    |
         |             v    |  |              v   |  |    v        v    |
         | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
         | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |  | | T1 |<-->| T3 | |
         | +----+    +----+ |  | +----+    +----+ |  | +----+    +----+ |
         +------------------+  +------------------+  +------------------+
          1. T2, T3 oneway      2. T2, T3 bothway     3. T1, T2 bothway

                            Figure 4: Example topologies

Internet draft              MEGACO Protocol             January 27, 2000

        _______________________________________________________________________
        |Topology |  Description                                               |
        |_________|____________________________________________________________|
        |1        |No topology descriptors.  When no topology descriptors are not issued for them.

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.

If the receiver encounters an error such that it cannot determine a
legal Action, it will return  |
        |         |included, all terminations have a TransactionReply consisting of both way connection to all|
        |         |other terminations.                                         | |_________|____________________________________________________________|
        |2        |T1, T2, Isolated.  Removes the Tran-
sactionID connection between T1 and T2.|
        |         |T3 has a single error descriptor.

If the receiver encounters an error such that is cannot determine a
legal Transaction, it will return a TransactionReply both way connection with a null Tran-
sactionID both T1 and a single error descriptor.

8.2.3.  TransactionPending

The receiver invokes the TransactionPending. T2.           |
        |_________|____________________________________________________________|
        |3        |T3, T2, oneway.  A TransactionPending indi-
cates that the Transaction is actively being processed, but has not been
completed.  It is used oneway connection from T3 to prevent the sender T2 (i.e. T2 |
        |         |receives media flow from assuming the Transac-
tionRequest was lost where the Transaction will take some time T3).  A bothway connection between |
        |         |T1 and T3.                                                  |
        |_________|____________________________________________________________|
        |4        |T2, T3, oneway.  A oneway connection between T2 to com-
plete.

TransactionPending(TransactionID { } )

The TransactionID parameter T3.      |
        |         |T1 and T3 remain bothway connected                          |
        |_________|____________________________________________________________|
        |5        |T2, T3 bothway.  T2 is bothway connected to T3.             |
        |         |This results in the same as 2.                              |
        |_________|____________________________________________________________|
        |6        |T1, T2 bothway. (T2, T3 bothway and T1,T3 bothway may be    |
        |         |implied or explicit).  terminations have a bothway          |
        |_________|____________________________________________________________|

A oneway connection must specify implemented in such a keyword value for correlation
with way that the corresponding TransactionRequest from other Termi-
nations in the sender.  A property Context are not aware of root (normalMGExecutionTime) is settable by the MGC to indicate change in topology.

7.2.  Command Application Programming Interface

Following is an Application Programming Interface (API) describing the
interval within which
Commands of the MGC expects a response protocol.  This API is shown to any transaction from illustrate the MG.  Another property (normalMGCExecutionTime) Commands
and their parameters and is settable by the
MGC not intended to indicate the interval within which specify implementation (e.g.
via use of blocking function calls).  It describes the MG should expects a
response to any transaction from input parameters
in parentheses after the MGC.  Senders may receive more than
one TransactionPending for a command.

8.3.  Messages

Multiple Transactions can be concatenated into a Message.  Messages have
a header, which includes command name and the identity return values in front of
the sender. 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

The Message Iden-
tifier (MID) of Add Command adds a message is set Termination to a provisioned name (e.g. domain
address/domain name/device name) of the entity transmitting Context.

TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]

Internet draft              MEGACO Protocol             January 27, 2000

[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
     Add( TerminationID
          [, MediaDescriptor]
           [, ModemDescriptor]
           [, MuxDescriptor]
           [, EventsDescriptor]
           [, SignalsDescriptor]
           [, DigitMapDescriptor]
           [, AuditDescriptor]
     )

The TerminationID specifies the message.
Domain name is a suggested default.

Every Message contains a Version Number identifying termination to be added to the version of Context.
The Termination is either created, or taken from the
protocol null Context.  For
an existing Termination, the message conforms to.  Versions are defined as in RFC2145,
and consist of TerminationID would be specific.  For a major/minor version with one or two digits each.

Internet draft              MEGACO Protocol           September 21, 1999

9.  TRANSPORT

The transport mechanism for
Termination that does not yet exist, the protocol should allow TerminationID is specified as
CHOOSE  in the reliable tran-
sport of transactions between an MGC and MG. command. The transport shall remain
independent of what particular commands are being sent and shall new TerminationID will 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 returned.  Wild-
cards may be defined as additional annexes in
subsequent editions of this document, or used in separate documents.

The MG is provisioned an Add, but such usage would be unusual.  If the
wildcard matches more than one TerminationID, all possible matches are
attempted, with a DNS name or IP address results reported for each one.  The order of attempts
when multiple TerminationIDs match is not specified.

The optional MediaDescriptor describes all media streams.

The optional ModemDescriptor and MuxDescriptor specify a primary modem and
zero or more secondary MGCs (see section 7.2.8) which mul-
tiplexer if applicable. For convenience, if a Multiplex Descriptor is the address the
MG uses to send messages to the MGC.   The MGC receives the Servi-
ceChange message from the MG
present in an Add command and can determine the MGs IP address.
Responses to commands lists any Terminations that are not
currently in the Context, such Terminations are sent back added to the source address of context as
if individual Add commands listing the com-
mands.  The initial ServiceChange message should Terminations were invoked.  If an
error occurs on such an implied Add, error 471 - Implied Add for Multi-
plex failure shall be sent to port ???? if
using TCP returned and port ???? if using UDP. The ServiceChange further processing of the command contains
a ServiceChangePort parameter.
shall cease.

The MG specifies the TCP/UDP port number EventsDescriptor parameter is optional.  If present, it wishes the MGC to use for communication.  The MGC replies with provides the
Port set to
list of events that should be detected on the TCP/UDP port number Termination.

The SignalsDescriptor parameter is optional.  If present, it wishes provides
the MG to use for further
communications.

10.  SECURITY CONSIDERATIONS

10.1.  Protection list of signals that should be applied to the Termination.

The DigitMapDescriptor parameter is optional.  If present, defines a
DigitMap definition that may be used in an EventsDescriptor.

Internet draft              MEGACO Protocol Connections

A security mechanism             January 27, 2000

The AuditDescriptor is clearly needed to prevent unauthorized entities
from using optional.  If present, the MEGACO/H.248 protocol for setting up unauthorized calls command will return
descriptors as specified in the AuditDescriptor.

All descriptors that can be modified could be returned by MG if a param-
eter was underspecified or interfering overspecified.  ObservedEvents, Statistics,
and Packages, and the EventBuffer Descriptors are returned only if
requested in the AuditDescriptor.  Add SHALL NOT be used on a Termina-
tion with authorized calls. a serviceState of "OutofService".

7.2.2.  Modify

The Modify Command modifies the properties of a Termination.

TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
     Modify( TerminationID
             [, MediaDescriptor]
             [, ModemDescriptor]
             [, MuxDescriptor]
             [, EventsDescriptor]
             [, SignalsDescriptor]
             [, DigitMapDescriptor]
             [, AuditDescriptor]
     )

The security mechanism for TerminationID may be specific if a single Termination in the
MEGACO/H.248 protocol Context
is IPsec [RFC2401 to RFC2411].

The AH header [RFC2402] affords data origin authentication, connection-
less integrity and optional anti-replay protection be modified. Use of messages passed
between wildcards in the MG and TerminationID may be
appropriate for some operations. If the MGC. The ESP header[RFC2406] provides wildcard matches more than one
TerminationID, all the
above security services plus confidentiality possible matches are attempted, with results reported
for each one.  The order of messages, if desired.
For instance, attempts when multiple TerminationIDs match
is not specified. The CHOOSE option is an error, as the ESP encryption service should Modify command
may only be requested if the ses-
sion descriptions are used on existing Terminations.

The remaining parameters to carry session keys, Modify are the same as defined in SDP.

MEGACO/H.248 implementations employing those to Add.  Possi-
ble return values are the ESP header same as those to Add.  Modify SHALL comply NOT be
used on a Termination with
section 5 of [RFC2406], which defines a minimum set serviceState of algorithms for
integrity checking "OutofService".

Internet draft              MEGACO Protocol             January 27, 2000

7.2.3.  Subtract

The Subtract Command disconnects a Termination from its Context and encryption. Similarly, MEGACO/H.248 implementa-
tions employing
returns statistics on the AH header SHALL comply with section 5 of [RFC2402],
which defines Termination's participation in the Context.

TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
     Subtract(TerminationID
              [, AuditDescriptor]
     )

TerminationID in the input parameters represents the Termination that is
being subtracted.  The TerminationID may be specific or may be a wild-
card value indicating that all (or a minimum set of algorithms for integrity checking using
manual keys.

MEGACO/H.248 implementations SHOULD use IKE [RFC2409] related) Terminations in the
Context of the Subtract Command are to permit be subtracted. If the wildcard
matches more
robust keying options. MEGACO/H.248 implementations employing IKE SHOULD
support authentication than one TerminationID, all possible matches are attempted,
with RSA signatures and RSA public key

Internet draft              MEGACO Protocol           September 21, 1999

encryption.

10.2.  Interim AH-within-MEGACO/H.248 scheme

Implementation results reported for each one.  The order of IPsec requires that attempts when multiple
TerminationIDs match is not specified. The CHOOSE option is an error, as
the AH or ESP header Subtract command may only be inserted
immediately after the IP header. This cannot used on existing Terminations.  ALL may
be easily done at used as the
application level.  Therefore, this presents ContextID as well as the TerminationId in a deployment problem for Subtract,
which would have the MEGACO/H.248 protocol where effect of deleting all contexts, deleting all
ephemeral terminations, and returning all physical terminations to Null
context.

By default, the underlying network implementation
does not support IPsec.

As an interim solution, Statistics parameter is returned to report information
collected on the MEGACO/H.248 protocol defines an optional AH
header within Termination or Terminations specified in the MEGACO/H.248 protocol header. Command.
The header fields information reported applies to the Termination's or
Terminations'Termination's or Terminations' existence in the Context
from which it or they are
exactly those of being subtracted.

The AuditDescriptor is optional.  If present, the SPI, SEQUENCE NUMBER and DATA fields command will return
descriptors as defined specified in
[RFC2402]. The semantics of the header fields AuditDescriptor.   Possible return
values are the same as the "tran-
sport mode" of [RFC2402], except those to Add.

When a provisioned Termination is Subtracted from a context, its pro-
perty values shall revert to:

Internet draft              MEGACO Protocol             January 27, 2000

*    The default value, if specified for the calculation of property and not overridden
     by provisioning or modification within the Integrity
Check null context

*    The provisioned value, if not overridden by modification in the
     null context

*    The last value (ICV). In IPsec, set by a modification while the ICV is calculated over termination was in
     the entire IP
packet including null context.

7.2.4.  Move

The Move Command moves a Termination to another Context from its current
Context in one atomic operation.  The Move command is the IP header. This prevents spoofing of only command
that refers to a Termination in a Context different from that to which
the IP
addresses.  To retain command is applied.  The Move command shall not be used to move Ter-
minations to or from the same functionality, null Context.

TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
     Move( TerminationID
           [, MediaDescriptor]
           [, ModemDescriptor]
           [, MuxDescriptor]
           [, EventsDescriptor]
           [, SignalsDescriptor]
           [, DigitMapDescriptor]
           [, AuditDescriptor]
     )

The TerminationID specifies the ICV calculation should Termination to be performed across moved.  It may be
wildcarded.  If the entire transaction prepended by a synthesized IP
header consisting wildcard matches more than one TerminationID, all
possible matches are attempted, with results reported for each one.  The
order of a 32 bit source IP address, a 32 bit destination
address and an 16 bit UDP encoded as 10 hex digits. When attempts when multiple TerminationIDs match is not specified.
By convention, the AH-within-
MEGACO/H.248 mechanism Termination is employed when TCP subtracted from its previous Context.
The Context to which the Termination is moved is indicated by the target
ContextId in the transport Layer, Action.  If the
UDP Port above becomes last remaining Termination is moved out
of a Context, the TCP port, and all other operations Context is deleted.

Internet draft              MEGACO Protocol             January 27, 2000

The remaining descriptors are processed as in the
same.

Implementations of Modify Command.  The
AuditDescriptor with the MEGACO/H.248 protocol SHALL implement IPsec where Statistics option, for example, would return
statistics on the underlying operating system supports IPsec.  Implementations of Termination just prior to the
MEGACO/H.248 protocol using IPv4 SHALL implement Move.  Possible descrip-
tors returned from Move are the interim AH-within-
MEGACO/H.248 scheme. However, this interim scheme same as for Add.  Move SHALL NOT be used when
on a Termination with a serviceState of "OutofService".

7.2.5.  AuditValue

The AuditValue Command returns the underlying network layer supports IPsec. IPv6 Implementations are
assumed to support IPsec current values of properties, events,
signals and SHALL NOT use statistics associated with Terminations.

TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
        AuditValue(TerminationID,
                AuditDescriptor
        )

TerminationID may be specific or wildcarded. If the AH-within- MEGACO/H.248
interim scheme.

All implementations wildcard matches
more than one TerminationID, all possible matches are attempted, with
results reported for each one.  The order of attempts when multiple Ter-
minationIDs match is not specified. If a wildcarded response is
requested, only one command return is generated, with the contents con-
taining the union of the AH-within-MEGACO/H.248 interim mechanism
SHALL comply values of all Terminations matching the wild-
card.  This convention may reduce the volume of data required to audit a
group of Terminations.  Use of CHOOSE is an error.

The appropriate descriptors, with section 5 the current values for the Termina-
tion, are returned from AuditValue.  Values appearing in multiple
instances of [RFC2402] which defines a minimum set descriptor are defined to be alternate values supported,
with each parameter in a descriptor considered independent.

ObservedEvents returns a list of
algorithms for integrity checking using manual keys.

The AH-within-MEGACO/H.248 interim scheme does not provide protection
against eavesdropping; thus forbidding third parties from monitoring events in the
connections set up by EventBuffer, Packages-
Descriptor returns a given termination. Also, it does not provide
protection against replay attacks.  These procedures do not necessarily
protect against denial list of service attacks packages realized by misbehaving MGs the Termination.
DigitMapDescriptor returns the name or mis-
behaving MGCs. However, they will provide an identification value of these
misbehaving entities, which should then be deprived the current DigitMap for
the Termination.  DigitMap applied to the root Termination returns all
named DigitMaps in the gateway.  Statistics returns the current values
of their authoriza-
tion through maintenance procedures. all statistics being kept on the Termination.  Specifying an empty

Internet draft              MEGACO Protocol           September 21, 1999

10.3.  Protection of Media Connections

The protocol allows the MGC to provide MGs with "session keys" that can
be used to encrypt             January 27, 2000

Audit Descriptor results in only the audio messages, protecting against eavesdropping.

A specific problem of packet networks is "uncontrolled barge-in." TerminationID being returned.  This
attack can
may be performed by directing media packets useful to the IP address and
UDP port used by get a connection. If no protection is implemented, the
packets must be decompressed and the signals must be played list of TerminationIDs when used with wildcard.

AuditValue results depend on the "line
side".

A basic protection against this attack is to only accept packets from
known sources, checking for example Context, viz. specific, null, or
unspecified.  The TerminationID may be specific, or wildcarded.

The following illustrates other information that the IP source address and UDP
source port match the values announced in the RemoteDescriptor.  This
has two inconveniences: it slows down connection establishment and it can be fooled by source spoofing:

-    To enable the address-based protection, the MGC must obtain obtained with
the
     remote session description Audit Command:

________________________________________________________________________
|ContextID   |TerminationID|  Information Obtained                     |
|Specific    |  wildcard   |Audit of the egress MG and pass it to the
     ingress MG.  This requires at least one network roundtrip, matching Terminations in a Context|
|Specific    |  specific   |Audit of a single Termination in a Context |
|Null        |  Root       |Audit of Media Gateway state and
     leaves us with events    |
|Null        |  wildcard   |Audit of all matching Terminations         |
|Null        |  specific   |Audit of a dilemma: either allow single Termination outside of   |
|            |             |any Context                                |
|All         |  wildcard   |Audit of all matching Terminations and the call |
|            |             |Context to proceed without
     waiting for which they are associated       |
|All         |  Root       |  List of all ContextIds                   |
|____________|_____________|___________________________________________|

7.2.6.  AuditCapabilities

The AuditCapabilities Command returns the round trip to complete, possible values of properties,
events, signals and risk for example,
     "clipping" a remote announcement, or wait for statistics associated with Terminations.

TerminationID
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,ObservedEventsDescriptor]
[,EventBufferDescriptor]
[,StatisticsDescriptor]
        AuditCapabilities(TerminationID,
                AuditDescriptor)

The appropriate descriptors, with the full roundtrip
     and settle possible values for slower call-set-up procedures.

-    Source spoofing is only effective if the attacker can obtain valid
     pairs of source destination addresses and ports, for example by
     listening to Termina-
tion are returned from AuditCapabilities.  Descriptors may be repeated
where there are multiple possible values.  values.  If a fraction of the traffic. To fight source spoofing, wildcarded
response is requested, only one could try to control all access points to the network.  But
     this command return is in practice very hard to achieve.

An alternative to checking generated, with the source address is to encrypt and authen-
ticate
contents containing the packets, using a secret key that is conveyed during union of the call
set-up procedure. values of all Terminations matching
the wildcard.  This will not slow down convention may reduce the call set- up, and provides
strong protection against address spoofing.

11.  MG-MGC CONTROL INTERFACE

The control association between MG volume of data required to

Internet draft              MEGACO Protocol             January 27, 2000

audit a group of Terminations.

Interpretation of what capabilities are requested for various values of
ContextID and MGC TerminationID is initiated at MG cold
start, and announced by a ServiceChange message, but can be changed by
subsequent events, such the same as failures or manual service events.  While in AuditValue.

The EventsDescriptor returns the
protocol does not have an explicit mechanism to support multiple MGCs
controlling a physical MG, it has been designed to support list of possible events on the multiple
logical MG (within a single physical MG) Termina-
tion together with the list of all possible values for the
EventsDescriptor Parameters.  The SignalsDescriptor returns the list of
possible signals that can could be associated applied to the Termination together with
different MGCs.

Internet draft              MEGACO Protocol           September 21, 1999

11.1.  Multiple Virtual MGs

A virtual MG consists
the list of a set all possible values for the Signals Parameters.  Statis-
ticsDescriptor returns the names of statically partitioned Terminations.
The model does the statistics being kept on the
termination.  ObservedEventsDescriptor returns the names of active
events on the termination.  DigitMap and Packages are not require that other resources be statically allocated,
just Terminations. legal in
AuditCapability

7.2.7.  Notify

The mechanism for allocating Terminations Notify Command allows the Media Gateway to virtual
MGs is a management method outside notify the scope Media Gateway
Controller of events occurring within the protocol.  Each of Media Gateway.

        Notify(TerminationID,
                   ObservedEventsDescriptor)

The TerminationID parameter specifies the virtual MGs appears to Termination issuing the MGC as a complete MG client.

In many cases, a physical MG may have only one network interface, which
must Notify
Command.  The TerminationID shall be shared across virtual MGs.  In such a case, fully qualified name.

The ObservedEventsDescriptor contains the packet/cell side
Termination is shared.  It should be noted however, RequestID and a list of events
that the Media Gateway detected in use, such
interfaces require an ephemeral instance of the Termination to be
created per flow, and thus sharing order that they were detected.
Each event in the Termination list is straightforward.
This mechanism does lead to a complication, namely accompanied by parameters associated with the
event and an indication of the time that the MG must
always know which event was detected. Notify
Commands shall occur only as the result of detection of its controlling MGCs should be notified if an event
occurs on the interface.

In normal operation, the MG will be instructed speci-
fied by the MGC to create net-
work flows (if it an Events Descriptor which is active on the originating side), termination con-
cerned, or to expect flow requests
(if it is the terminating side), and no confusion will arise.  However,
if an unexpected event occurs, the MG must know what to do.

If recovering from the event requires manipulation as a result of completion of a signal for which the interface
state, there can be only one MGC who can do so.  These issues are
resolved by allowing any
requested notification of completion.

The RequestID returns the MGCs to create EventDescriptors to be
notified RequestID parameter of such events, but only one MGC can have read/write access to the physical interface properties; all other MGCs have read-only access.
The management mechanism EventsDescriptor
that triggered the Notify Command.  It is used to designate which MGC has read/write
capability, and is designated the Master MGC.

Each virtual MG has its own Root Termination.  In most cases correlate the values
for notifi-
cation with the properties of request that triggered it.  The events in the Root Termination are independently settable by
each MGC.  Where there can only be one value, list must
have been requested via the parameter is read-only
to all but triggering EventsDescriptor, embedded events
descriptor or the Master MGC.

11.2.  Cold Start triggering SignalsDescriptor.

A MG is pre-provisioned Notify triggered by completion of a management mechanism outside signal, contains the scope of
this protocol with corresponding
signal name in the ObservedEventsDescriptor.

7.2.8.  ServiceChange

The ServiceChange Command allows the Media Gateway to notify the Media

Internet draft              MEGACO Protocol             January 27, 2000

Gateway Controller that a Primary and (optionally) an ordered list Termination or group of Secon-
dary MGCs.  Upon a cold start 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 MG, it will issue MGC
that the capability of a ServiceChange
command with Termination has changed.  It also allows a MGC
to hand over control of a "Restart" method, on the Root Termination MG to its primary another MGC.  If the MGC accepts

[ServiceChangeDescriptor]
        ServiceChange(TerminationID,
                ServiceChangeDescriptor
        )

The TerminationID parameter specifies the MG, it will send a Transaction Accept, Termination(s) that are taken
out of or returned to service.  Wildcarding of Termination names is per-
mitted, with the MGCIdToTry set to itself.  If exception that the MG receives a MGCIdToTry CHOOSE mechanism shall not equal
to be used.
Use of the MGC it contacted, it sends "Root" TerminationID indicates a ServiceChange to affecting the MGC specified
in
entire Media Gateway.

The ServiceChangeDescriptor contains the MGCIdToTry.  It continues this process until it gets a control-
ling MGC to accept its registration, or it fails to get a reply. Upon
failure to obtain a reply, either from following parameters as
required:

*    ServiceChangeMethod

*    ServiceChangeReason

*    ServiceChangeDelay

*    ServiceChangeAddress

*    Profile

*    Version

*    MGCIdToTry

*    TimeStamp

The ServiceChangeMethod parameter specifies the Primary MGC, type of ServiceChange
that will or a designated
successor, has occurred:

1)   Graceful - indicates that the MG tries it's pre-provisioned Secondary MGCs, in order.

Internet draft              MEGACO Protocol           September 21, 1999

11.3.  Failure specified Terminations will be taken
     out of an MG

If a MG fails, service after the specified ServiceChangeDelay; established
     connections are not yet affected, but is capable of sending a message the Media Gateway Controller
     should refrain from establishing new connections and should attempt
     to gracefully tear down existing connections. The MG should set
     termination serviceState to "test" until the MGC, it sends
a ServiceChange with an appropriate method (graceful expiry of Servi-
     ceChangeDelay or forced) and
specifies the Root TerminationID.  When it returns to service, it sends
a ServiceChange with a "Restart" method.

Allowing removal of the MGC to send duplicate messages termination from an active

Internet draft              MEGACO Protocol             January 27, 2000

     context (whichever is first), then set it to both MGs accommodates
pairs "out of MGs service".

2)   Forced - indicates that are capable of redundant failover of one of the MGs.
Only the Working MG shall accept or reject transactions.  Upon failover, the Primary MG sends a ServiceChange command with a "Failover" method specified Terminations were taken
     abruptly out of service and a "Failed MG" reason. any established connections associated
     with them were lost. The MGC then uses the primary MG as the
active MG.  When the error condition is repaired, responsible for cleaning up the Working MG can
send a "ServiceChange"
     context (if any) with a "Restart" method.

11.4.  Failure of an MGC

If which the MG detects failed termination is associated.
     At a failure of it's controlling MGC, it attempts to con-
tact minimum the next MGC on its pre-provisioned list.  It starts it's attempts
at termination shall be subtracted from the beginning (Primary MGC), unless context.
     The termination serviceState should be "out of service".

3)   Restart - indicates that was service will be restored on the MGC that failed, in
which case it starts at it's first Secondary MGC.  It sends a specified
     Terminations after expiration of the ServiceChangeDelay. The ser-
     viceState should be set  to "inService" upon expiry of Servi-
ceChange message
     ceChangeDelay.

4)   Disconnected - always applied with a "Failover" method and a "Failed MGC" reason.

In partial failure, or manual maintenance reasons, an MGC may wish to
direct its controlled MGs to use a different MGC.  To do so, it sends a
ServiceChange method to the Root TerminationID, indi-
     cates that the MG lost communication with a "HandOff" method, and it's desig-
nated replacement in MGCIdToTry. The MG should send a ServiceChange mes-
sage with a "Forced" method and a "MGC directed change" reason to the
designated MGC.  If it fails to get a reply, or fails to see an Audit
command subsequently, MGC, but it should behave as if it's MGC failed, and start
contacting secondary MGCs.

When was sub-
     sequently restored.  Since MG state may have changed, the MGC initiates a HandOff, the handover should be transparent may
     wish to
Operations on use the Media Gateway.  Commands in progress continue, tran-
saction replies are sent Audit command to resynchronize its state with the new MGC, and the MG should expect out-
standing transaction replies
     MG's.

5)   Handoff - sent from the new MGC.  All connections should
stay up.

It is possible MGC to the MG, this reason indicates that
     the MGC could be implemented in such a way that is going out of service and a
failed new MGC association must be
     established.

6)   Failover - sent from MG to MGC to indicate the primary MG is replaced by out of
     service and a working secondary MG is taking over, and sent from MG to
     (new) MGC where in response to the identity of MG having received a ServiceChange
     with ServiceChangeMethod equal to Handoff.

The ServiceChangeReason parameter specifies the new
MGC is reason why the same as Servi-
ceChange has or will occur.  It consists of an alphanumeric token (IANA
registered) and an explanatory string.

The optional ServiceChangeAddress parameter specifies the failed one.  In such a case, MGCIdToTry would address (e.g.,
IP port number for IP networks) to be used for subsequent communica-
tions.  It can be specified with in the previous value.  In such a case, input parameter descriptor or the
returned result descriptor.

The optional ServiceChangeDelay parameter is expressed in seconds.  If
the MG shall behave
as if delay is absent or set to zero, the delay value was changed, and send should be considered
to be null.  In the case of a ServiceChange message, as above.

failover by "graceful" ServiceChangeMethod, a null
delay indicates that the above mechanism.

Internet draft              MEGACO Protocol           September 21, 1999

12.  PACKAGE DEFINITION

The primary mechanism Media Gateway Controller should wait for extension is by means the
natural removal of Packages.  Packages
define additional Properties, Events, Signals existing connections and Statistics that may
occur on Terminations.

Packages defined by IETF will appear in separate RFCs.

Packages relevant should not establish new
connections.  .  For "graceful" only, null delay means the MG should set
serviceState to H.323 systems are listed in an Annex "test" immediately, then wait indefinitely for the ter-
mination to Recommenda-
tion H.323.

Packages defined by ITU-T will be described in Annexes removed from any active context before setting service-
State to H.248.

12.1.  Guidelines for defining packages

Packages define properties, events, signals and statistics.  Names of
all such defined constructs shall consist "out of service".  For "restart", null means immediate return
to service.

Internet draft              MEGACO Protocol             January 27, 2000

The optional Profile parameter specifies the ID Profile (if any) of the package, the
character "/" and
protocol supported.  The Profile includes the ID version of the item, for example, "tone/ring".  A Pack-
age shall contain profile
supported.

The optional Version parameter contains the following sections:

1.   Full Package name, PackageID, protocol version and description.  PackageIDs shall is used
if protocol version negotiation occurs (see section 11.3).

The optional TimeStamp parameter specifies the actual time as kept by
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 string
precision of up to 64 characters, containing no spaces, and consist-
     ing hundredths of alphas and digits, a second, and possibly including the special char-
     acter underscore ("_").  The PackageID is used expressed in a TerminationSta-
     teDescriptor, or UTC.

A ServiceChange Command specifying the LocalControl Descriptor, "Root" for example,
     "tone/dialtone" specifies a signal "dialtone" in the package
     "tone".  The Package name TerminationID and
ServiceChangeMethod equal to Restart is descriptive only.

2.   Properties defined by the package, specifying a Property name, Pro-
     pertyID, possible values, and description.  PropertyID shall be registration command by which
a
     string of up Media Gateway announces its existence to 64 characters, containing no spaces, and consisting
     of alphas and digits, and possibly including the special character
     underscore ("_"). Media Gateway Controller.
The PropertyID Media Gateway is used in a TerminationSta-
     teDescriptor, or the LocalControl Descriptor.  For example
     "foo/color" specifies the "color" property defined in expected to be provisioned with the package
     "foo".  The Property name is descriptive only.

3.   Events defined by the package, specifying an Event name, EventID,
     possible Parameter names, ParameterIDs and possible values for each
     parameter.  EventIDs and ParameterIDs shall be a string of up to 64
     characters, containing no spaces, one
primary and consisting optionally some number of alternate Media Gateway Controll-
ers.    Acknowledgement of alphas and
     digits, and possibly including the special character underscore
     ("_").  EventIDs and PropertyIDs are ServiceChange Command completes the
registration process.  The MG may specify the transport ServiceChangeAd-
dress to be used by the MGC for sending messages in an Event Descriptor.
     For example "line/offhook" specifies the "offhook" event defined ServiceChangeAd-
dress parameter in the "line" package. input ServiceChangeDescriptor.  The Event name is descriptive only.

4.   Signals defined by the package, specifying a Signal name, SignalID,
     possible Parameter names, ParameterIDs and possible values for each

Internet draft              MEGACO Protocol           September 21, 1999

     parameter. SignalID and ParameterIDs MGC shall be a string of up use
this Address, if specified, in its response to 64
     characters, containing no spaces, and consisting of alphas the ServiceChange command
and
     digits, any subsequent commands and possibly including responses.  The MGC may specify the special character underscore
     ("_"). SignalID and PropertyIDs are used Ser-
viceChangeAddress for the MG to use in a Signal Descriptor. the returned result Servi-
ceDescriptor.  The Signal name is descriptive only.

5.   Statistics defined by MG shall use this address for any subsequent communi-
cation with the package, specifying a Statistic name,
     StatisticID, units, and description. StatisticID MGC.  The TimeStamp parameter shall be sent with a string
     of up to 64 characters, containing no spaces, and consisting of
     alphas and digits,
registration command and possibly including its response.

The Media Gateway Controller may return an MGCIdToTry parameter that
describes the special character
     underscore ("_"). Media Gateway Controller that should preferably be con-
tacted 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 StatisticID is used Gateway specified in an MGCIdToTry, if provided, shall
be contacted before any further alternate MGCs.  On a Statistics Descrip-
     tor.  The Statistic name is descriptive only.

12.2.  Example Package

Section 1. DTMF Package

          PackageID: dtmf

          Description: This package is used HandOff message
from MGC to detect and generate tones
          on MG, the analog trunk or line connection on a media gateway.

Section 2. Properties

          2.1 Media Gateway Country Code

               PropertyID: mgcountry

               Possible values: 3 character string

               Description: Country code MGCIdToTry is the new MGC that will take over from ITU??????

Section 3. Events

          3.1 ToneDetected

               EventID: tonedt

               Parameters:

                    3.1.2 Stream ID

                         ParameterID: streamid

                         Direction: IN

                         Possible Values: Integer
the current MGC.

Summarizing use of properties in the ServiceChange Descriptor:

*    ServiceChangeMethod mandatory in all cases.

*    ServiceChangeReason mandatory in all cases.

*    ServiceChangeDelay mandatory if ServiceChangeMethod is "Graceful"
     or "Restart", otherwise not allowed.

*    ServiceChangeAddress mandatory when the range of 0-256 terminationID is ROOT, oth-
     erwise not allowed.

Internet draft              MEGACO Protocol           September 21, 1999

                         Description: id of audio stream to detect tones
                         on.

                    3.1.3 Detected Tone List

                         ParameterID: listoftones

                         Direction: IN/OUT

                         Possible Values: a string (max 64 characters)
                         consisting of             January 27, 2000

*    Profile required if terminationID is ROOT, optional otherwise.

*    Version as specified in section 11.3.

*    MGCIdToTry optional if the characters '0', '1', '2',
                         '3', '4', '5', '6', '7', '8', '9', '*', '#',
                         'A', 'B', 'C', 'D', 'X', '/'

                         Description: one or more dtmf tones (to be)
                         detected, separated by '/'

                         Example: "0/1/2/3/4/5/6/7/8/9/*/#".

                    3.1.4 Event Type

                         ParameterID: eventtype

                         Direction: OUT

                         Possible Values:

                              "MULTI": multiple digits have been accumu-
                              lated message comes from MGC and sent.

                              "START": one tone start detected

                              "LONG":  one tone has been detected for
                              more than 2 seconds

                              "END':  one tone end detected.

                         Description: What kind of detection has
                         occurred

                    3.2.2 Duration

                         ParameterID: duration

                         Direction: OUT

Internet draft              MEGACO Protocol           September 21, 1999

                         Possible Values: Integer (32 bit)

                         Description:  When eventtype terminationID
     is ROOT, not allowed otherwise.

*    TimeStamp mandatory when terminationID is END, ROOT, optional otherwise.

The return from ServiceChange has the length
                         of same parameters as the tone detected

               Description: Detects a DTMF tone.  Reports stream input
except that ServiceChangeMethod and
               which tone was detected.

          3.2       SilenceDetected

               EventID: silencedt

               Parameters:

                    3.2.1 Stream ID

                         ParameterID: streamid

                         Direction: IN

                         Possible Values: Integer ServiceChangeReason are optional.
If provided they shall be the same as those specified in the range command.

The following ServiceChangeReasons are defined.  This list may be
extended by an IANA registration as outlined in section 13.3

     900 Service Restored
     901 MG Cold Boot
     902 MG Warm Boot
     903 MGC Directed Change
     904 Termination malfunctioning
     905 Termination taken out of 0-256

                         Description: id service
     906 Loss of audio stream to detect tones
                         on.

                    3.2.2 Duration

                         ParameterID: duration

                         Direction: IN/OUT

                         Possible Values: Integer (32 bit)

                         Description:  How many ms to wait before
                         trigger

                         Description: This event is triggered after a
                         period lower layer connectivity (e.g. downstream
         sync)
     907 Transmission Failure
     908 MG Impending Failure
     909 MGC Impending Failure
     910 Media Capability Failure
     911 Modem Capability Failure
     912 Mux Capability Failure
     913 Signal Capability Failure
     914 Event Capability Failure
     915 State Loss

7.2.9.  Manipulating and Auditing Context Attributes

The commands of silence has occurred.

Section 4. Signals

          4.1 Play Tones

               SignalID: playtone

               Parameters:

                    4.1.1 Stream ID

Internet draft              MEGACO Protocol           September 21, 1999

                         ParameterID: streamid

                         Direction: IN

                         Possible Values: Integer the protocol as discussed in the range of 0-256

                         Description: id of audio stream 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 play tones
                         on.

                    4.1.2 Tone List

                         ParameterID: listoftones

                         Direction: IN/OUT

                         Possible Values: a string (max 64 characters)
                         consisting of the Characters '0', '1', '2',
                         '3', '4', '5', '6', '7', '8', '9', '*', '#',
                         'A', 'B', 'C', 'D', 'X', '/'

                         Description:
one or more dtmf tones context.  In addition to be
                         played, separated by '/'

                              Example: "0/1/2/3/4/5/6/7/8/9/*/#".

                    4.1.3 Signal Type

                         ParameterID: signaltype

                         Possible values:

                              "BR" brief duration (provisioned)

                              "ON" Play until instructed commands, it may contain context manipula-
tion and auditing instructions.

An action request sent to stop

                              "TO" Play until timed out

                    4.1.4 Duration

                         ParameterID: duration

                         Direction: IN/OUT

                         Possible Values: Integer (32 bit)

                         Description:  If signalType is TO, How many ms a MG may include a request to audit attributes
of a context.  An action may also include a request to change the attri-
butes of a context.

Internet draft              MEGACO Protocol           September 21, 1999

                         to play each tone

12.3.  Package Registration

A package can be registered with IANA for interoperability reasons.  See
section 13 for IANA considerations.

13.  IANA CONSIDERATIONS

13.1.  Packages             January 27, 2000

The following considerations SHALL context properties that may be met included in an action reply are used
to return information to register a package with
IANA:

1.   A unique string name and serial number is registered for each pack-
     age.

2.   A public document MGC.  This can be information requested by an
audit of context attributes or details of the effect of manipulation of
a standard forum document, context.

If a MG receives an action which can be refer-
     enced as contains both a request to audit con-
text attributes and a request to manipulate those attributes, the document that describes
response SHALL include the package following values of the
     guideline above, must attributes after processing the
manipulation request.

7.2.10.  Generic Command Syntax

The protocol can be specified. encoded in a binary format or in a text format.
MGCs should support both encoding formats.  MGs may support both for-
mats.

The document SHALL specify protocol syntax for the
     version binary format of the Package that it describes.

3.   A contact name, email protocol is defined in
Annex A.  Annex C specifies the encoding of the Local and postal addresses Remote
descriptors for that contact shall
     be specified.  The contact information shall be updated by use with the
     defining organization binary format.

A complete ABNF of the text encoding of the protocol per RFC2234 is
given in Annex B.  SDP, as necessary.

4.   The document should be available on a public web server modified herein is used as the encoding of
the Local and should
     have a stable url. The site should provide a mechanism to provide
     comments Remote Descriptors for use with the text encoding.

7.3.  Command Error Codes

Errors consist of an IANA registered error code and appropriate responses should be returned.

The following package names an explanatory
string.  Sending the explanatory string is optional.  Implementations
are reserved

*    dtmf

*    generic

*    keypad

*

Packages registered by other than recognized standards bodies shall have
a minimum package name length encouraged to append diagnostic information to the end of 8 characters

All other package names are first come-first served if all other condi-
tions are met

Internet draft              MEGACO Protocol           September 21, 1999

13.2.  Error Codes

The following considerations SHALL be met the
string.

When a MG reports an error to register a MGC, it does so in an error code with
IANA:

1.   A descriptor.
An error number and a one line (80 character maximum) string is
     registered for each error.

2.   A complete description descriptor consists of an error code and optionally the conditions under which the associ-
ated explanatory string.

The identified error is
     detected shall be included codes are:

     400 - Bad Request
     401 - Protocol Error
     402 - Unauthorized
     403 - Syntax Error in a publicly available document. Transaction
     404 - Syntax Error in TransactionReply
     405 - Syntax Error in TransactionPending
     406 - Version Not Supported
     410 - Incorrect identifier
     411 - The
     description shall be sufficiently clear transaction refers to differentiate the error
     from all other existing error codes.

3.   The document should be an unknown ContextId
     412 - No ContextIDs available on
     421 - Unknown action or illegal combination of actions

Internet draft              MEGACO Protocol             January 27, 2000

     422 - Syntax Error in Action
     430 - Unknown TerminationID
     431 - No TerminationID matched a public web server and should
     have wildcard
     432 - Out of TerminationIDs or No TerminationID available
     433 - TerminationID is already in a stable url.

4.   Error numbers registered by recognized standards bodies shall have
     3 Context
     440 - Unsupported or 4 character error numbers

5. unknown Package
     441 - Missing RemoteDescriptor
     442 - Syntax Error numbers registered by all other organizations in Command
     443 - Unsupported or individuals
     shall have 4 character error numbers

6.   An error number shall not be redefined, nor modified except by the
     organization Unknown Command
     444 - Unsupported or individual that originally defined it, Unknown Descriptor
     445 - Unsupported or Unknown Property
     446 - Unsupported or their
     successors Unknown Parameter
     447 - Descriptor not legal in this command
     448 - Descriptor appears twice in a command
     450 - No such property in this package
     451 - No such event in this package
     452 - No such signal in this package
     453 - No such statistic in this package
     454 - No such parameter value in this package
     455 - Parameter illegal in this Descriptor
     456 - Parameter or assigns.

14.  CONTACT INFORMATION

     IETF Editor
          Brian Rosen
          FORE Systems
          1000 FORE Drive
          Warrendale, PA  15086
          U.S.A.
          Phone: +1 724-742-6826
          Email: brosen@fore.com
     ITU Editor
          John Segers
          Lucent Technologies
          Room HE 306
          Dept. Forward Looking Work
          P.O. Box 18, 1270 AA  Huizen
          Netherlands
          Phone: +31 35 687 4724
          Email: jsegers@lucent.com

     Additional IETF Authors
          Fernando Cuervo

Internet draft              MEGACO Protocol           September 21, 1999

          Nortel Networks
          P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7
          Canada
          Email: cuervo@nortelnetworks.com

          Bryan Hill
          Gotham Networks
          15 Discovery Way
          Acton, MA 01720
          USA
          Phone: +1 978-263-6890
          Email: bhill@gothamnetworks.com

          Christian Huitema
          Telcordia Technologies
          MCC 1J236B
          445 South Street
          Morristown, NJ 07960
          U.S.A.
          Phone: +1 973-829-4266
          EMail: huitema@research.telcordia.com

          Nancy Greene
          Nortel Networks
          P.O. Box 3511 Stn C
          Ottawa, ON, K1Y 4H7
          Canada
          Phone: +1 514-271-7221
          Email: ngreene@nortelnetworks.com

          Abdallah Rayhan
          Nortel Networks
          P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7
          Canada
          Email: arayhan@nortelnetworks.com

15.  ANNEX A Property appears twice in this Descriptor
     461 - TransactionIDs in Reply do not match Request
     462 - Commands in Transaction Reply do not match commands in request
     463 - TerminationID of Transaction Reply does not match  request
     464 - Missing reply in Transaction Reply
     465 - TransactionID in Transaction Pending does not match any open request
     466 - ASN.1 DESCRIPTION OF THE PROTOCOL (NORMATIVE)

15.1.  Specification language

The baseline text Illegal Duplicate Transaction Request
     467 - Illegal Duplicate Transaction Reply
     471 - Implied Add for this section will be taken Multiplex failure

     500 - Internal Gateway Error
     501 - Not Implemented
     502 - Not ready.
     503 - Service Unavailable
     504 - Command Received from APC-1608.

15.2.  Syntax specification

This section will contain the protocol syntax specification using the
language described in unauthorized entity
     505 - Command Received before Restart Response
     510 - Insufficient resources
     512 - Media Gateway unequipped to detect requested Event
     513 - Media Gateway unequipped to generate requested Signals
     514 - Media Gateway cannot send the previous section. specified announcement
     515 - Unsupported Media Type
     517 - Unsupported or invalid mode
     518 - Event buffer full
     519 - Out of space to store digit map
     520 - Media Gateway does not have a digit map
     521 - Termination is "ServiceChangeing"
     526 - Insufficient bandwidth
     529 - Internal hardware failure

Internet draft              MEGACO Protocol           September 21, 1999

16.  ANNEX B             January 27, 2000

     530 - TEXT ENCODING OF THE PROTOCOL (NORMATIVE)

16.1.  Translation Mechanism

A future edition of this document will describe how Temporary Network failure
     531 - Permanent Network failure
     581 - Does Not Exist

8.  TRANSACTIONS

Commands between the syntax Media Gateway Controller and the Media Gateway are
grouped into Transactions, each of Annex
A which is translated into ABNF.  This version contains hand-coded ABNF

16.2.  ABNF specification identified by a Transac-
tionID.  Transactions consist of one or more Actions.  An Action con-
sists of a series of Commands that are limited to operating within a
single Context.   Consequently each Action typically specifies a Contex-
tID.  However, there are two circumstances where a specific ContextID is
not provided with an Action.  One is the case of modification of a Ter-
mination outside of a Context.  The protocol syntax other is presented in ABNF according where the controller
requests the gateway to RFC2234.

megacoMessage = LWSP [authenticationHeader SEP ] message

authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
                       SequenceNum COLON AuthData

SecurityParmIndex = 8(HEXDIG)
SequenceNum = 8(HEXDIG)
AuthData = 16(HEXDIG)

message = MegacopToken SLASH Version SEP mId SEP ( errorDescriptor create a new Context.  Following is a graphic
representation of the Transaction, Action and Command relationships.

  +----------------------------------------------------------+
  |
        1*(transactionRequest Transaction x                                            | transactionReply
  |
transactionPending))

transactionPending = PendingToken EQUAL TransactionID LBRKT
                     [TimeNotation] RBRKT

transactionRequest = TransToken EQUAL TransactionID LBRKT
                     actionRequest *(COMMA actionRequest) RBRKT

actionRequest = CtxToken EQUAL ContextID LBRKT
               ((contextProperties COMMA commandList)  +----------------------------------------------------+  |
                contextProperties
  | commandList ) RBRKT

contextProperties = contextProperty *(COMMA contextProperty)
; at-most-once
contextProperty = topologyDescriptor ;  | bridgeDescriptor
; bridgeDescriptor is still to be defined.

commandList = commandRequest *(COMMA commandRequest)

commandRequest = (ammRequest Action 1                                           | subtractRequest  | auditRequest
  |
                  notifyRequest  | serviceChangeRequest)

transactionReply = ReplyToken EQUAL TransactionID LBRKT
                   ( errorDescriptor +---------+  +---------+  +---------+  +---------+ | ( actionReply
                   *(COMMA actionReply ))) RBRKT

Internet draft              MEGACO Protocol           September 21, 1999

actionReply = CtxToken EQUAL ContextID LBRKT ( errorDescriptor  |
              ( commandReply *(COMMA commandReply)) ) RBRKT

commandReply = (serviceChangeReply
  | auditReply  | ammsReply |
notifyReply )

;Add Move and Modify have the same request parameters
ammRequest = (AddToken Command |  | Command |  | Command |  | Command | |  |
  |  | |    1    |  |    2    |  |    3    |  |    4    | |  |
  |  | +---------+  +---------+  +---------+  +---------+ |  |
  |  +----------------------------------------------------+  |
  |                                                          |
  |  +----------------------------------------------------+  |
  |  | Action 2                                           |  |
  |  | +---------+                                        |  |
  |  | | Command |                                        |  |
  |  | |    1    |                                        |  |
  |  | +---------+                                        |  |
  |  +----------------------------------------------------+  |
  |                                                          |
  |  +----------------------------------------------------+  |
  |  | Action 3                                           |  |
  |  | +---------+  +---------+  +---------+              | MoveToken  | ModifyToken ) EQUAL TerminationID
             [LBRKT ammParameter *(COMMA ammParameter) RBRKT]

;at-most-once
ammParameter= (mediaDescriptor
  | modemDescriptor  | muxDescriptor |
               eventsDescriptor Command | signalsDescriptor  |
               digitMapDescriptor Command | auditDescriptor)

ammsReply = ( AddToken  | MoveToken Command | ModifyToken              | SubtractToken )
        ( commandError  | ( [EQUAL TerminationID] [terminationAudit] ))

commandError = EQUAL TerminationID LBRKT errorDescriptor RBRKT

subtractRequest = subtractToken EQUAL TerminationID [ LBRKT
                  auditDescriptor RBRKT]

auditRequest = (AuditValueToken
  | AuditCapToken ) EQUAL TerminationID
               [ LBRKT auditDescriptor RBRKT ]

auditReply = ( AuditValueToken  | AuditCapToken) ( contextAudit |
               commandError    1    |
             [EQUAL TerminationID] terminationAudit )

terminationAudit = LBRKT auditReturnParameter
                   *(COMMA auditReturnParameter) RBRKT

contextAudit = EQUAL CtxToken terminationIDList

;at-most-once
auditReturnParameter = (mediaDescriptor  | modemDescriptor    2    |
                        muxDescriptor  | eventsDescriptor    3    |
                        signalsDescriptor              | digitMapDescriptor  |
                        observedEventsDescriptor
  |
                        statisticsDescriptor  | packagesDescriptor )

auditDescriptor = AuditToken LBRKT auditItem  *(COMMA auditItem) RBRKT

notifyRequest = NotifyToken EQUAL TerminationID
               LBRKT observedEventsDescriptor RBRKT

notifyReply = NotifyToken ( commandError +---------+  +---------+  +---------+              | [EQUAL TerminationID] )  |
  |  +----------------------------------------------------+  |
  +----------------------------------------------------------+
          Figure 5 Transactions, Actions and Commands

Transactions are presented as TransactionRequests.  Corresponding

Internet draft              MEGACO Protocol           September 21, 1999

serviceChangeRequest = serviceChangeToken EQUAL             January 27, 2000

responses to a TransactionRequest are received in a single reply, possi-
bly preceded by a number of TransactionPending messages (see section
8.2.3).

Transactions guarantee ordered Command processing.  That is, Commands
within a Transaction are executed sequentially. Ordering of Transactions
is NOT guaranteed - transactions may be executed in any order, or simul-
taneously.

At the first failing Command in a Transaction, processing of the remain-
ing Commands in that Transaction stops.  If a command contains a wild-
carded TerminationID, the command is attempted with each of the actual
TerminationIDs matching the wildcard.  A response within the Transac-
tionReply is included for each matching TerminationID, even if one or
more instances generated an error.  If any TerminationID
                       LBRKT serviceChangeDescriptor RBRKT

serviceChangeReply = serviceChangeToken (commandError |
         ([EQUAL TerminationID] [LBRKT serviceChangeDescriptor RBRKT]
))

errorDescriptor = ErrorToken EQUAL ErrorCode LBRKT quotedString RBRKT

ErrorCode = 1*3(DIGIT) ; could matching a
wildcard results in an error when executed, any commands following the
wildcarded command are not attempted.  Commands may be extended

TransactionID = UINT32

mId = ( domainAddress | domainName ) [":" portNumber] | deviceName

domainName = "<" (ALPHA | DIGIT) *63(ALPHA | DIGIT | "-" | ".") ">"
deviceName = pathNAME

ContextID = (UINT32 | "-" | "$")

domainAddress = "[" (IPv4address | IPv6address) "]"
;RFC2373 contains 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 return values 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. 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-
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

8.1.1.  Transaction Identifiers

Transactions are identified by a TransactionID, which is assigned by
sender and is unique within the scope of the sender.

8.1.2.  Context Identifiers

Contexts are identified by a ContextID, which is assigned by the definition of IP6Addresses.
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex
V4hex = 1*3(DIGIT) ; "0".."225"
IPv6prefix = hexpart SLASH 1*2DIGIT
hexpart = hexseq "::" [ hexseq ] | "::" [ hexseq ] | hexseq
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG

portNumber = UINT16

terminationIDList = LBRKT TerminationID *(COMMA TerminationID) RBRKT

; Total length Media
Gateway and is unique within the scope of pathNAME must 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

Internet draft              MEGACO Protocol             January 27, 2000

Gateway Controller when referring to a Termination that is currently not exceed 64 chars.
; "*" should
associated with a Context, namely the null ContextID.

The CHOOSE wildcard is used to request that the Media Gateway create a
new Context.  The MGC shall not appear more than twice use partially specified ContextIDs con-
taining the CHOOSE wildcard.  The MGC may use the ALL wildcard to
address all Contexts on the MG.

8.2.  Transaction Application Programming Interface

Following is an Application Programming Interface (API) describing the
Transactions of the protocol.  This API is shown to illustrate the Tran-
sactions and their parameters and is not intended to specify implementa-
tion (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 pathNAME.
pathNAME = NAME *(["/"] ["*"] (ALPHA | DIGIT)) ["*"]

TerminationID = "$" | "*" | "ROOT" | pathNAME

mediaDescriptor = mediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT

; at-most-once later subsections.

8.2.1.  TransactionRequest

The TransactionRequest is invoked by the sender.  There is one Transac-
tion per item
; request invocation.  A request contains one or more Actions,
each of which specifies its target Context and either streamParm one or streamDescriptor but not both
mediaParm = (streamParm | streamDescriptor |
terminationStateDescriptor)

; at-most-once

Internet draft              MEGACO Protocol           September 21, 1999

streamParm = ( localDescriptor | remoteDescriptor |
               localControlDescriptor )

streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm
                   *(COMMA streamParm) RBRKT

localControlDescriptor = LocalControlToken LBRKT localParm
                         *(COMMA localParm) RBRKT

; at-most-once more Commands per item
localParm = ( streamMode | propertyParm )

streamMode = ModeToken EQUAL streamModes

streamModes = (SendonlyToken | RecvonlyToken | SendrecvToken |
                   InactiveToken | LoopbackToken | DeleteToken )

propertyParm = pkgdName propertyValue
propertyValue = (EQUAL alternativeValue| INEQUAL VALUE)
alternativeValue = ( VALUE | LSBRKT VALUE *(COMMA VALUE) RSBRKT  |
                LSBRKT VALUE DOT DOT VALUE RSBRKT )

INEQUAL = LWSP (">" | "<" | "#" ) LWSP
LSBRKT = LWSP "[" LWSP
RSBRKT = LWSP "]" LWSP

localDescriptor = LocalToken EQUAL (tvList | octetStringParm)

OctetStringParm = (SdpToken | extensionParameter)LBRKT OctetString
RBRKT

tvList = TagValueToken EQUAL LBRKT NAME propertyValue
         *(NAME propertyValue) RBRKT

remoteDescriptor = RemoteToken EQUAL  (tvList | octetStringParm)

terminationStateDescriptor = TerminationStateToken LBRKT
             terminationStateParm *(COMMA terminationStateParm) RBRKT

; at-most-once
Context.

TransactionRequest(TransactionId {
       ContextID {Command ... Command},
                        . . .
       ContextID  {Command ... Command } })

The TransactionID parameter must specify a value for later correlation
with the TransactionReply or TransactionPending response from the
receiver.

The ContextID parameter must specify a value to pertain to all Commands
that follow up to either the next specification of a ContextID parameter
or the end of the TransactionRequest, whichever comes first.

The Command parameter represents one of the Commands mentioned in the
"Command Details" subsection titled "Application Programming Interface".

8.2.2.  TransactionReply

The TransactionReply is invoked by the receiver.  There is one reply
invocation per item
terminationStateParm =(terminationBuffered | propertyParm |
serviceStates)

serviceStates = ServiceStatesToken EQUAL ( TestToken |
                OutOfSvcToken | InSvcToken )

terminationBuffered = BufferedEventHandlingToken LBRKT
                      bufferedEventHandling [COMMA transaction. A reply contains one or more Actions, each
of which must specify its target Context and one or more Responses per
Context.

Internet draft              MEGACO Protocol           September 21, 1999

bufferedEventHandling] RBRKT

bufferedEventHandling = ( loopControl  | processControl)

loopControl = (StepToken | LoopToken )
processControl = ( ProcessToken | DiscardToken )

muxDescriptor = MuxToken EQUAL MuxType  terminationIDList

MuxType = ( H221Token | H223Token | H226Token |
            H225-0Token | extensionParameter)

StreamID = UINT16
pkgdName = [ (PackageName | "*")  SLASH ] (ItemID | "*" )
PackageName = NAME
ItemId = NAME

eventsDescriptor = EventsDescriptorToken EQUAL RequestID LBRKT
                   requestedEvent *(COMMA requestedEvent) RBRKT

requestedEvent = pkgdName [ LBRKT eventParameter
                *(COMMA eventParameter) RBRKT ]

; at-most-one eventAction
eventParameter = ( eventAction | eventOther )

eventAction = ActionToken LBRKT requestedActions RBRKT

eventOther = eventParameterName EQUAL VALUE

eventParameterName = NAME
requestedActions = requestedAction LWSP [COLON LWSP
                   embeddedSignalEvents ]
                   [COLON LWSP InterceptToken ]

requestedAction = ( accumulateDescriptor | NotifyActionToken |
                  AccumulateToken | extensionParameter )

accumulateDescriptor = DigitMapToken ((EQUAL digitMapName ) |
           (LBRKT digitMapValue RBRKT ))

embeddedSignalEvents = firstembedding [COMMA firstEmbedding]
; at-most-once
firstEmbedding = ( secondEvent | signalsDescriptor )

secondEvent = EventsDescriptorToken EQUAL RequestID LBRKT
             secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT             January 27, 2000

TransactionReply(TransactionID {
      ContextID { Response ... Response },
      . . .
      ContextID { Response ... Response } })

The TransactionID parameter must be the same as that of the correspond-
ing TransactionRequest.

The ContextID parameter must specify a value to pertain to all Responses
for the action.  The ContextID may be specific or null.

Each of the Response parameters represents a return value as mentioned
in section 7.2, or an error descriptor if the command execution encoun-
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
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.

If the receiver encounters an error in processing a ContextID, the
requested Action response will consist of the context ID and a single
error descriptor, 422 Syntax Error in Action.

If the receiver encounters an error such that it cannot determine a
legal Action, it will return a TransactionReply consisting of the Tran-
sactionID 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).

If the end of a transaction can not be reliably determined and one or
more Actions can be parsed, it will process them and then return 403
Syntax Error in Transaction as the last action reply for the 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-
tax Error in Command as the action reply.

If the end of a command cannot be reliably determined it will return 442
Syntax Error in Transaction as the reply to the last action it can
parse.

Internet draft              MEGACO Protocol           September 21, 1999

secondRequestedEvent = pkgdName [ LBRKT secondEventParameter
                     *(COMMA secondEventParameter) RBRKT ]

; at-most-one secondEventAction
secondEventParameter = ( secondEventAction | eventOther )

secondEventAction = ActionToken LBRKT secondAction RBRKT

secondAction = requestedAction LWSP [COLON LWSP signalsDescriptor ]
              [COLON LWSP InterceptToken ]

signalsDescriptor = SignalsDescriptorToken LBRKT signalRequest
                 *(COMMA signalRequest) RBRKT

signalRequest = signalName [ LBRKT sigParameter
                *(COMMA sigParameter) RBRKT ]

signalName = pkgdName
sigParameter = sigParameterName EQUAL VALUE
sigParameterName = NAME

observedEventsDescriptor = ObservedEventsToken EQUAL RequestID
                   LBRKT observedEvent *(COMMA observedEvent) RBRKT

;time per event, because it might be buffered
observedEvent = [ TimeNotation LWSP COLON] LWSP signalRequest

RequestID = UINT32

modemDescriptor = ModemToken (( EQUAL modemType) |
                 (LSBRKT modemType *(COMMA modemType) RSBRKT))
                 [ LBRKT NAME propertyValue
                  *(COMMA NAME propertyValue) RBRKT ]

; at-most-once
modemType =  (V18Token | V34Token | V90Token | V91Token |
              SynchISDNToken  |extensionParameter)

digitMapDescriptor = DigitMapToken EQUAL digitMapName
                    LBRKT digitMapValue RBRKT
digitMapName = NAME
digitMapValue=["L" COLON Timer COMMA] ["M" COLON Timer COMMA] digitMap
Timer = 1*2DIGIT
digitMap = (digitString | LWSP "(" LWSP digitStringList LWSP ")" LWSP)
digitStringList = digitString *( LWSP "|" LWSP digitString             January 27, 2000

8.2.3.  TransactionPending

The receiver invokes the TransactionPending.  A TransactionPending indi-
cates that the Transaction is actively being processed, but has not been
completed.  It is used to prevent the sender from assuming the Transac-
tionRequest was lost where the Transaction will take some time to com-
plete.

TransactionPending(TransactionID { } )
digitString = 1*(digitStringElement)
digitStringElement = digitPosition [DOT]
digitPosition = digitMapLetter | digitMapRange

The TransactionID parameter must must be the same as that of the
corresponding TransactionRequest.  A property of root (normalMGExecu-
tionTime) is settable by the MGC to indicate the interval within which
the MGC expects a response to any transaction from the MG. Another pro-
perty (normalMGCExecutionTime) is settable by the MGC to indicate the
interval within which the MG should expects a response to any transac-
tion 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.

8.3.  Messages

Multiple Transactions can be concatenated into a Message.  Messages have
a header, which includes the identity of the sender. The Message Iden-
tifier (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.

Every Message contains a Version Number identifying the version of the
protocol the message conforms to.  Versions are defined as in RFC2145,
and consist of one or two digits.

The transactions in a message are treated independently.  There is no
order implied, there is no application or protocol acknowledgement of a
message.

9.  TRANSPORT

The transport mechanism for the protocol should allow the reliable tran-
sport 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

Internet draft              MEGACO Protocol           September 21, 1999

digitMapRange = ("x" | LWSP "[" LWSP digitLetter LWSP "]" LWSP)
digitLetter = *((DIGIT "-" DIGIT ) | digitMapLetter)
digitMapLetter=DIGIT | "#" | "*" | "A" | "B" | "C" | "D" | MFSig | "T"

MFSig = "K0" | "K1" | "K2" | "S0" | "S1" | "S2" | "S3"

;at-most-once
auditItem = ( MuxToken | ModemToken | MediaToken |
                      EventsDescriptorToken | SignalsDescriptorToken |
                    DigitMapToken | StatsToken | ObservedEventsToken |
                    PackagesToken )

serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
                          *(COMMA serviceChangeParm) RBRKT

;at-most-once.  Version             January 27, 2000

UDP/ALF, an MG shall implement TCP or UDP/ALF or both.

The MG is REQUIRED on first provisioned with a name or address (such as DNS name or IP
address) of a primary and zero or more secondary MGCs (see section
7.2.8) that is the address the MG uses to send messages to the MGC.
The MGC receives the ServiceChange message from the MG and can determine
the MGs address. Responses to commands are sent back to the source
address of the commands.  The initial ServiceChange message should be
sent to the ServiceChangeAddress (in an IP network, port ???? if using
TCP and port ???? if using UDP).  The ServiceChange
;request&response
serviceChangeParm = (serviceChangeMethod | serviceChangeReason |
                   serviceChangeDelay | serviceChangePort |
                   serviceChangeProfile | extension |
                   serviceChangeMgcId )
serviceChangeMethod = MethodToken EQUAL (FailoverToken |
                ForcedToken | GracefulToken | RestartToken |
                DisconnectedToken | HandOffToken | extensionParameter)

;need some reasons!!!, command contains a
ServiceChangeAddress parameter.  The MG specifies the address (e.g.,
TCP/UDP port number) it wishes the MGC to use for communication.  The
MGC replies with the ServiceChangeAddress set to the address  it wishes
the MG to use for further communications.

9.1.  Ordering of Commands

This document does not mandate that the underlying transport protocol
guarantees the sequencing of transactions sent to an entity.  This pro-
perty tends to maximize the timeliness of actions, but it has a few
drawbacks.  For example:

*    Notify commands may be delayed and arrive at the MGC after the
     transmission of a new command changing the EventsDescriptor

*    If a new command is transmitted before a previous one is ack-
     nowledged, there is no guarantee that prior command will be exe-
     cuted before the new one.

Media Gateway Controllers that want to guarantee consistent operation of
the Media Gateway may use the following rules:

1.   When a Media Gateway handles several Terminations, commands per-
     taining to the different Terminations may be sent in parallel, for
     example following a model where each Termination (or group of Ter-
     minations) is controlled by its own process or its own thread.

2.   In a given Context, there should normally be at most one outstand-
     ing command (Add or Modify or Move).  However, a Subtract command
     may be issued at any time.  In consequence, a Media Gateway may
     sometimes receive a Modify command that applies to a previously
     subtracted Termination.  Such commands should be ignored, and an
     error code should it be returned.

3.   On a string?
serviceChangeReason = ReasonToken  EQUAL VALUE
serviceChangeDelay = DelayToken   EQUAL UINT32
serviceChangePort = PortToken    EQUAL portNumber
serviceChangeMgcId = MgcIdToken   EQUAL mId
serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
extension = extensionParameter EQUAL VALUE

packagesDescriptor = PackagesToken LBRKT packagesItem
                    *(COMMA packagesItem) RBRKT

Version = 1*2(DIGIT) DOT 1*2(DIGIT)
packagesItem = NAME

TimeNotation = Date "T" Time; per ISO 8601:1988
; Date = yyyymmdd
Date = 8(DIGIT)
; Time = hhmmssss
Time = 8(DIGIT)
statisticsDescriptor = StatsToken LBRKT statisticsParameter
                    *(COMMA statisticsParameter ) RBRKT

;at-most-once per item given Termination, there should normally be at most one out-
     standing Notify command at any time.  The RequestId parameter
     should be used to correlate Notify commands with the triggering
     notification request.

Internet draft              MEGACO Protocol           September 21, 1999

statisticsParameter = ( pkgdName EQUAL VALUE ) |
                      ( extension)

; I don't know yet about this.
topologyDescriptor = TopologyToken LBRKT terminationA COMMA
                     terminationB COMMA topologyDirection RBRKT
terminationA = TerminationID
terminationB = TerminationID
topologyDirection = BothwayToken | IsolateToken | OnewayToken

extensionParameter = "X"  ("-" | "+") 1*6(ALPHA | DIGIT)

; OctetString             January 27, 2000

4.   In some cases, an implicitly or explicitly wildcarded Subtract com-
     mand that applies to a group of Terminations may step in front of a
     pending Add command.  The Media Gateway Controller should individu-
     ally delete all connections whose completion was pending at the
     time of the global Subtract command.  Also, new Add commands for
     Terminations named by the wild-carding (or implied in a Multiplex
     descriptor) may not be sent until the wild-carded Subtract command
     is used acknowledged.

5.   AuditValue and AuditCapability are not subject to describe SDP any sequencing.

6.   ServiceChange shall always be the first command sent by a MG as
     defined in RFC2327.
; Caution by the restart procedure. Any other command or response
     must be delivered after this ServiceChange command. These rules do
     not affect the command responder, which should always respond to
     commands.

9.2.  Protection against Restart Avalanche

In the event that a large number of Media Gateways are powered on simul-
taneously and they were to all initiate a ServiceChange transaction, the
Media Gateway Controller would very likely be taken if CRLF in RFC2327 swamped, leading to mes-
sage losses and network congestion during the critical period of service
restoration. In order to prevent such avalanches, the following behavior
is used.
; To suggested:

1.   When a Media Gateway is powered on, it should initiate a restart
     timer to a random value, uniformly distributed between 0 and a max-
     imum waiting delay (MWD). Care should be safe, taken to avoid synchroni-
     city of the random number generation between multiple Media Gate-
     ways that would use EOL in the same algorithm.

2.   The Media Gateway should then wait for either the end of this timer
     or the detection of a local user activity, such as for example an
     off-hook transition on a residential Media Gateway.

3.   When the timer elapses, or when an activity is detected, the Media
     Gateway should initiate the restart procedure.

The restart procedure simply requires the MG to guarantee that the first
message that the Media Gateway Controller sees from this ABNF.
; Whenever "}" appears in SDP, it MG is escaped by "
OctetString = *(nonEscapeChar)
nonEscapeChar = ( "" | %x01-7C | %x7E-FF )
quotedString = DQUOTE 1*64(SafeChar) DQUOTE

UINT16 = 1*5(DIGIT)  ; %x0-FFFF
UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF
UINT64 = 1*20(DIGIT) ; %x0-FFFFFFFFFFFFFFFF

NAME = ALPHA *63(ALPHA | DIGIT | "_" )
VALUE = quotedString | 1*64(SafeChar)
SafeChar = DIGIT | ALPHA | "+" | "-" | "&" |
         "!" | "_" | "/" | "'" | "?" | "@" |
         "^" | "`" | "~" | "*" | "$" | "
         "(" | ")" | "%" | "|" | "."

EQUAL                = LWSP %x3D LWSP ; "="
COLON                = %x3A           ; ":"
LBRKT                = LWSP %x7B LWSP ; "{"
RBRKT                = LWSP %x7D LWSP ; "}"
COMMA                = LWSP %x2C LWSP ; ","
DOT                  = %x2E           ; "."
SLASH                = %x2F           ; "/"
ALPHA                = %x41-5A | %x61-7A ; A-Z | a-z
DIGIT                = %x30-39         ; 0-9
DQUOTE               = %x22            ; " (Double Quote)
HEXDIG               = ( DIGIT | "A" | "B" | "C" | "D" | "E" | "F" )
SP                   = %x20        ; space
HTAB                 = %x09        ; horizontal tab
CR                   = %x0D        ; Carriage return
LF                   = %x0A        ; linefeed
LWSP                 = *( WSP | COMMENT | EOL )
EOL                  = (CR [LF] | LF ) a Servi-
ceChange message informing the Media Gateway Controller about the res-
tart

The value of MWD is a configuration parameter that depends on the type
of the Media Gateway. The following reasoning may be used to determine
the value of this delay on residential gateways.

Internet draft              MEGACO Protocol           September 21, 1999

WSP                  = SP | HTAB ; white space
SEP                  = ( WSP | EOL | COMMENT) LWSP
COMMENT              = ";" *(SafeChar| RestChar | WSP) EOL
Restchar             = ";" | "[" | "]" | "{" | "}" | ":" | "," | "#" |
                       "<" | ">" | "=" | %x22

ActionToken                = ("Action"                | "AN")
AccumulateToken            = ("Accumulate"            | "AM")
AddToken                   = ("Add"                   | "A")
AuditToken                 = ("Audit"                 | "AT")
AuditCapToken              = ("AuditCapability"       | "AC")
AuditValueToken            = ("AuditValue"            | "AV")
AuthToken                  = ("Authentication"        | "AU")
AvgLatencyToken            = ("AverageLatency"        | "AL")
BothwayToken               = ("Bothway"               | "BW")
BufferedEventHandlingToken = ("BufferedEventHandling" | "BE")
CtxToken                   = ("Context"               | "C")
DigitMapToken              = ("DigitMap"              | "DM")
DiscardToken               = ("Discard"               | "DS")
DisconnectedToken          = ("Disconnected"          | "DC")
DelayToken                 = ("Delay"                 | "DL")
DeleteToken                = ("Delete"                | "DE")
ErrorToken                 = ("Error"                 | "ER")
EventsDescriptorToken      = ("Events"                | "E")
FailoverToken              = ("Failover"              | "FL")
ForcedToken                = ("Forced"                | "FO")
GracefulToken              = ("Graceful"              | "GR")
H221Token                  = ("H221" )
H223Token                  = ("H223" )
H226Token                  = ("H226" )
H225-0Token                = ("H225-0")
HandoffToken               = ("HandOff"               | "HO")
InactiveToken              = ("Inactive"              | "IN")
InterceptToken             = ("Intercept"             | "IC")
IsolateToken               = ("Isolate"               | "IS")
InSvcToken                 = ("InService"             | "IV")
JitterToken                = ("Jitter"                | "JI")
LocalToken                 = ("Local"                 | "L")
LocalControlToken          = ("LocalControl"          | "O")
LoopbackToken              = ("Loopback"              | "LB")
LoopToken                  = ("Loop"                  | "LP")
MediaToken                 = ("Media"                 | "M")
MegacopToken               = ("MEGACO"                | "!")
MethodToken                = ("Method"                | "MT")
MgcIdToken                 = ("MgcIdToTry"            | "MG")
ModeToken                  = ("Mode"                  | "MO")
ModifyToken                = ("Modify"                | "MF")             January 27, 2000

Media Gateway Controllers are typically dimensioned to handle the peak
hour traffic load, during which, in average, 10% of the lines will be
busy, placing calls whose average duration is typically 3 minutes.  The
processing of a call typically involves 5 to 6 Media Gateway Controller
transactions between each Media Gateway and the Media Gateway Con-
troller.  This simple calculation shows that the Media Gateway Con-
troller is expected to handle 5 to 6 transactions for each Termination,
every 30 minutes on average, or, to put it otherwise, about one transac-
tion per Termination every 5 to 6 minutes on average.  This suggests
that a reasonable value of MWD for a residential gateway would be 10 to
12 minutes.  In the absence of explicit configuration, residential gate-
ways should adopt a value of 600 seconds for MWD.

The same reasoning suggests that the value of MWD should be much shorter
for trunking gateways or for business gateways, because they handle a
large number of Terminations, and also because the usage rate of these
Terminations is much higher than 10% during the peak busy hour, a typi-
cal value being 60%.  These Terminations, during the peak hour, are this
expected to contribute about one transaction per minute to the Media
Gateway Controller load. A reasonable algorithm is to make the value of
MWD per "trunk" Termination six times shorter than the MWD per residen-
tial gateway, and also inversely proportional to the number of Termina-
tions that are being restarted. For example MWD should be set to 2.5
seconds for a gateway that handles a T1 line, or to 60 milliseconds for
a gateway that handles a T3 line.

10.  SECURITY CONSIDERATIONS

This section covers security when using the protocol in an IP environ-
ment.

10.1.  Protection of Protocol Connections

A security mechanism is clearly needed to prevent unauthorized entities
from using the protocol defined in this document for setting up unau-
thorized calls or interfering with authorized calls. The security
mechanism for the protocol when transported over IP networks is IPsec
[RFC2401 to RFC2411].

The AH header [RFC2402] affords data origin authentication, connection-
less integrity and optional anti-replay protection of messages passed
between the MG and the MGC. The ESP header [RFC2406] provides confiden-
tiality of messages, if desired. For instance, the ESP encryption ser-
vice should be requested if the session descriptions are used to carry
session keys, as defined in SDP.

Implementations of the protocol defined in this document employing the
ESP header SHALL comply with section 5 of [RFC2406], which defines a

Internet draft              MEGACO Protocol             January 27, 2000

minimum set of algorithms for integrity checking and encryption. Simi-
larly, implementations employing the AH header SHALL comply with section
5 of [RFC2402], which defines a minimum set of algorithms for integrity
checking using manual keys.

Implementations SHOULD use IKE [RFC2409] to permit more robust keying
options. Implementations employing IKE SHOULD support authentication
with RSA signatures and RSA public key encryption.

10.2.  Interim AH scheme

Implementation of IPsec requires that the AH or ESP header be inserted
immediately after the IP header. This cannot be easily done at the
application level.  Therefore, this presents a deployment problem for
the protocol defined in this document where the underlying network
implementation does not support IPsec.

As an interim solution, an optional AH header is defined within the
MEGACO protocol header. The header fields are exactly those of the SPI,
SEQUENCE NUMBER and DATA fields as defined in [RFC2402]. The semantics
of the header fields are the same as the "transport mode" of [RFC2402],
except for the calculation of the Integrity Check value (ICV). In IPsec,
the ICV is calculated over the entire IP packet including the IP header.
This prevents spoofing of the IP addresses.  To retain the same func-
tionality, the ICV calculation should be performed across the entire
transaction prepended by a synthesized IP header consisting of a 32 bit
source IP address, a 32 bit destination address and an 16 bit UDP
encoded as 10 hex digits. When the interim AH mechanism is employed when
TCP is the transport Layer, the UDP Port above becomes the TCP port, and
all other operations are the same.

Implementations of the MEGACO protocol SHALL implement IPsec where the
underlying operating system and the transport network supports IPsec.
Implementations of the protocol using IPv4 SHALL implement the interim
AH scheme. However, this interim scheme SHALL NOT be used when the
underlying network layer supports IPsec. IPv6 implementations are
assumed to support IPsec and SHALL NOT use the interim AH scheme.

All implementations of the interim AH mechanism SHALL comply with sec-
tion 5 of [RFC2402] which defines a minimum set of algorithms for
integrity checking using manual keys.

The interim AH interim scheme does not provide protection against eaves-
dropping; thus forbidding third parties from monitoring the connections
set up by a given termination. Also, it does not provide protection
against replay attacks.  These procedures do not necessarily protect
against denial of service attacks by misbehaving MGs or misbehaving
MGCs. However, they will provide an identification of these misbehaving

Internet draft              MEGACO Protocol           September 21, 1999

ModemToken                 = ("Modem"                 | "MD")
MoveToken                  = ("Move"                  | "MV")
MuxToken                   = ("Mux"                   | "MX")
NotifyActionToken          = ("NotifyAction"          | "NA")
NotifyToken                = ("Notify"                | "N")
ObservedEventsToken        = ("ObservedEvents"        | "OE")
OctetsRecvdToken           = ("OctetsReceived"        | "OR")
OnewayToken                = ("Oneway"                | "OW")
OctetsSentToken            = ("OctetsSent"            | "OT")
OutOfSvcToken              = ("OutOfService"          | "OS")
PackagesToken              = ("Packages"              | "PG")
PendingToken               = ("Pending"               | "PN")
PktsLostToken              = ("PacketsLost"           | "PL")
PktsRecvdToken             = ("PacketsRecived"        | "PR")
PktsSentToken              = ("PacketsSent"           | "PS")
PortToken                  = ("Port"                  | "PT")
ProcessToken               = ("Process"               | "PC")
ProfileToken               = ("Profile"               | "PF")
ReasonToken                = ("Reason"                | "RE")
RecvonlyToken              = ("ReceiveOnly"           | "RC")
ReplyToken                 = ("Reply"                 | "P")
RestartToken               = ("Restart"               | "RS")
RemoteToken                = ("Remote"                | "R")
SdpToken                   = ("SDP"                   | "D")
SignalsDescriptorToken     = ("Signals"               | "SG")
SendonlyToken              = ("SendOnly"              | "SO")
SendrecvToken              = ("SendReceive"           | "SR")
ServicesToken              = ("Services"              | "SV")
ServiceStatesToken         = ("ServiceStates"         | "SI")
ServiceChangeToken         = ("ServiceChange"         | "SC")
StatsToken                 = ("Statistics"            | "SA")
StepToken                  = ("Step"                  | "SP")
StreamToken                = ("Stream"                | "ST")
SubtractToken              = ("Subtract"              | "S")
SynchISDNToken             = ("SynchISDN"             | "SN")
TagValueToken              = ("TagValue"              | "TV")
TerminationStateToken      = ("TerminationState"      | "TS")
TestToken                  = ("Test"                  | "TE")
TopologyToken              = ("Topology"              | "TP")
TransToken                 = ("Transaction"           | "T")
V18Token                   = ("V18")
V34Token                   = ("V34")
V90Token                   = ("V90")
V91Token                   = ("V91")
VersionToken               = ("Version"               | "V")             January 27, 2000

entities, which should then be deprived of their authorization through
maintenance procedures.

10.3.  Protection of Media Connections

The protocol allows the MGC to provide MGs with "session keys" that can
be used to encrypt the audio messages, protecting against eavesdropping.

A specific problem of packet networks is "uncontrolled barge-in". This
attack can be performed by directing media packets to the IP address and
UDP port used by a connection. If no protection is implemented, the
packets must be decompressed and the signals must be played on the "line
side".

A basic protection against this attack is to only accept packets from
known sources, checking for example that the IP source address and UDP
source port match the values announced in the Remote Descriptor.  This
has two inconveniences: it slows down connection establishment and it
can be fooled by source spoofing:

*    To enable the address-based protection, the MGC must obtain the
     remote session description of the egress MG and pass it to the
     ingress MG.  This requires at least one network roundtrip, and
     leaves us with a dilemma: either allow the call to proceed without
     waiting for the round trip to complete, and risk for example,
     "clipping" a remote announcement, or wait for the full roundtrip
     and settle for slower call-set-up procedures.

*    Source spoofing is only effective if the attacker can obtain valid
     pairs of source destination addresses and ports, for example by
     listening to a fraction of the traffic. To fight source spoofing,
     one could try to control all access points to the network.  But
     this is in practice very hard to achieve.

An alternative to checking the source address is to encrypt and authen-
ticate the packets, using a secret key that is conveyed during the call
set-up procedure. This will not slow down the call set- up, and provides
strong protection against address spoofing.

11.  MG-MGC CONTROL INTERFACE

The control association between MG and MGC is initiated at MG cold
start, and announced by a ServiceChange message, but can be changed by
subsequent events, such as failures or manual service events.  While the
protocol does not have an explicit mechanism to support multiple MGCs
controlling a physical MG, it has been designed to support the multiple
logical MG (within a single physical MG) that can be associated with
different MGCs.

Internet draft              MEGACO Protocol           September 21, 1999

17.  ANNEX C - BINARY ENCODING OF THE PROTOCOL

17.1.  Translation             January 27, 2000

11.1.  Multiple Virtual MGs

A physical Media Gateway may be partitioned into one or more Virtual
MGs.  A virtual MG consists of a set of statically partitioned physical
Terminations and/or sets of ephemeral Terminations.  A physical Termina-
tion is controlled by one MGC.  The model does not require that other
resources be statically allocated, just Terminations.  The mechanism

This section will specify for
allocating Terminations to virtual MGs is a management method outside
the scope of the protocol.  Each of the virtual MGs appears to the MGC
as a complete MG client.

A physical MG may have only one network interface, which must be shared
across virtual MGs. In such a case, the packet/cell side Termination is
shared.  It should be noted however, that in use, such interfaces
require an ephemeral instance of the Termination to be created per flow,
and thus sharing the Termination is straightforward.  This mechanism for obtaining
does lead to a binary encoding
from complication, namely that the syntax specification given in Annex A.  It MG must always know which
of its controlling MGCs should be notified if an event occurs on the
interface.

In normal operation, the Virtual MG will also contain a
compiler be instructed by the MGC to generate binary encoded protocol messages according
create network flows (if it is the originating side), or to this
mechanism.

Internet draft              MEGACO Protocol           September 21, 1999

18.  ANNEX D - TAGS FOR MEDIA STREAM PROPERTIES

As expect flow
requests (if it is the terminating side), and no confusion will arise.
However, if an alternative unexpected event occurs, the Virtual MG must know what to SDP, Remote and Local Descriptors may be specified
as
do with respect to the physical resources it is controlling.

If recovering from the event requires manipulation of a list physical
interface's state, only one MGC should do so.  These issues are resolved
by allowing any of tag=value pairs.  The >, <, alternative options as speci-
fied in section ???? may the MGCs to create EventsDescriptors to be used. notified
of such events, but only one MGC can have read/write access to the phy-
sical interface properties; all other MGCs have read-only access.  The possible tag
management mechanism is used to designate which MGC has read/write capa-
bility, and is designated the Master MGC.

Each virtual MG has its own Root Termination.  In most cases the values are:

18.1.  General Media Attributes

Note that these attributes
for the properties of the Root Termination are not necessarily applicable independently settable by
each MGC.  Where there can only be one value, the parameter is read-only
to all codecs
or required for fully describe but the Master MGC.

ServiceChange may only be applied to a particular codec's mode Termination or set of operation.

 ______________________________________________________________________
|Full Tag         |Short Tag|  Type            |  Values               |
|_________________|_________|__________________|_______________________|
|MediaType        |  MED    |  Enumeration     |  Audio, Video, Data,  |                  |_________________|_________|__________________|_______________________|
|TransmissionMode |  TRM    |  Set             |  (Send, Receive)      |
|_________________|_________|__________________|_______________________|
|NumberOfChannels |  NCH    |  Unsigned Integer|  0-255                                    |_________________|_________|__________________|_______________________|
|Sampling rate    |  SMR    |  Unsigned Integer|  0-2^32                                   |_________________|_________|__________________|_______________________|
|Bit rate mode    |  BRM    |  Enumeration     | e.g. for GSM:{"full", |
|                 |         |                  | "enhanced_full",      |
|                 |         |                  | "half"} DEFAULT "full"|
|_________________|_________|__________________|_______________________|
|Codec            |  COD    |  Eumeration      | "PCM","G711u","G711A",|
|                 |         |                  | "G722,"GSM","G7231,   |
|                 |         |                  | "G729","G729A,"G729B",|
|                 |         |                  | "G729AB","G723C", ... |
|                 |         |                  | Note: The values      |
|                 |         |                  | should match the IANA-|
|                 |         |                  | assigned values Termina-
tions partitioned to    |
|                 |         |                  | describe mapping in   |
|                 |         |                  | SDP specifications    |
|                 |         |                  | (rtpmap).             |
|_________________|_________|__________________|_______________________|
|Samples per      |  SPP    | Unsigned Integer |  0-65535              |
|   packet        |         |                  |                       |
|_________________|_________|__________________|_______________________|
|Silence          |  SIL    | BOOLEAN          |  True/False           |
|   suppression   |         |                  |                       |
|_________________|_________|__________________|_______________________|
|Encryption type  |  ENT    | Enumeration      |  Off, ....            |
|_________________|_________|__________________|_______________________|
|Encryption key   |  ENC    | Unsigned Integer |  0-2^1024             |  |_________________|_________|__________________|_______________________|
|Echo canceller   |  ECN    | Enumeration      | Off, G.165, G168, ... |
|_________________|_________|__________________|_______________________|
|Gain             |  GAI    | Unsigned Integer |  0-65535              |
|_________________|_________|__________________|_______________________|
|Jitterbuffer     |  JTB    | Unsigned Integer |  0-65535              |
|_________________|_________|__________________|_______________________|

18.2.  Multiplex properties

The multiplexer would describe how media and transport would the Virtual MG or created (in the case of ephemeral
Terminations) by that Virtual MG. ServiceChange may only be linked.

                 _____________________________________
                | Full Tag|  Short Tag|  Type|  Values|
                |_________|___________|______|________|
                | H.221   |           |      |        |
                |_________|___________|______|________|
                | H.223   |           |      |        |
                |_________|___________|______|________|
                | V.76    |           |      |        |
                |_________|___________|______|________|
                | H.2250  |           |      |        |
                |_________|___________|______|________|
                | Null    |           |      |        |
                |_________|___________|______|________| applied to
the Root by the Master MGC.

11.2.  Cold Start

A MG is pre-provisioned by a management mechanism outside the scope of
this protocol with a Primary and (optionally) an ordered list of

Internet draft              MEGACO Protocol           September 21, 1999

18.3.  Properties for BearerDescriptor

Generic properties:

 ________________________________________________________________________
|Full Tag            |  Short Tag|  Type       |  Values                 |
|____________________|___________|_____________|_________________________|
|Media transport type|  MTT      |  Enumeration|  DS0, ATMaal5, ATMaal2, |
|                    |           |             |      FR, RTP ...        |
|____________________|___________|_____________|_________________________|

18.4.  For DS0

              ____________________________________________
             | Full Tag|  Short Tag|  Type    |  Values  |
             |_________|___________|__________|__________|
             | OPC     |  OPC      |  Integer |  0-2^14-1|
             |_________|___________|__________|__________|
             | DPC     |  DPC      |  Integer |  0-2^14-1|
             |_________|___________|__________|__________|
             | CIC     |  CIC      |  Integer |  0-2^12-1|
             |_________|___________|__________|__________|

18.5.  For ATM VC

     ______________________________________________________________
    | Full Tag|  Short Tag |  Type     |  Values                  |
    |_________|____________|___________|__________________________|
    | Address |  ATMaddress|  String   |  NSAP/AESA               |
    |_________|____________|___________|__________________________|
    | VCC     |  VCC       |  2xInteger|  VCI/VPI                 |
    |_________|____________|___________|__________________________|
    | QoS mode|            |           |  As defined             January 27, 2000

Secondary MGCs.  Upon a cold start of the MG, it will issue a Servi-
ceChange command with a "Restart" method, on the Root Termination to its
primary MGC.  If the MGC accepts the MG, it will send a Transaction
Accept, with the MGCIdToTry set to itself.  If the MG receives an MGCId-
ToTry not equal to the MGC it contacted, it sends a ServiceChange to the
MGC specified in H.245 (or |
    |         |            |           |       RSVP)              |
    |_________|____________|___________|__________________________|

18.6.  Frame Relay

     ______________________________________________________________
    | Full Tag               |  Short Tag|  Type   |  Values      |
    |________________________|___________|_________|______________|
    | Data link connection id|  DLCI     |  Integer|  (0-65536)???|
    |________________________|___________|_________|______________|
    | sub-Channel ID         |  CID      |  Integer|   (0-255)?   |
    |________________________|___________|_________|______________|

18.7.  RTP Stream

An RTP stream requires two addressing parts for the MGCIdToTry.  It continues this process until it
gets a controlling MGC to accept its registration, or it fails to get a
reply. Upon failure to obtain a reply, either from the Primary MGC, or a
designated successor, the MG tries its pre-provisioned Secondary MGCs,
in order.  If the MG is unable to establish a control relationship with
any MGC, it shall wait a random amount of time as described in section
9.2 and then start contacting its primary, and if necessary, its secon-
dary MGCs again.

It is possible that the local reply to a ServiceChange with Restart will be
lost, and
remote side. Both a command will have the form of:

Internet draft              MEGACO Protocol           September 21, 1999

____________________________________________________________________________
|Full Tag            |  Short Tag|  Type     |  Values                     |
|____________________|___________|___________|_____________________________|
|IP address          |  IPAD     |           |  Ipv4Address or Ipv6 address|
|____________________|___________|___________|_____________________________|
|RTP port            |  RPTP     |  Integer  |  0-65535                    |
|____________________|___________|___________|_____________________________|
|DiffServe Codepoint |  DSCP     |   Integer |  0-255 Packet marking value |
|____________________|___________|___________|_____________________________|

19.  TRANSPORT USING UDP AND APPLICATION LAYER FRAMING

MECACO/Recommendation H.248 messages may be transmitted over UDP.  When
no port is specified for received by the other side (see section 7.2.8), the com-
mands should be sent MG prior to the default MEGACO port, ????.

19.1.  Providing At-Most-Once functionality

Messages, being carried over UDP, may be subject to losses. In receipt of
the
absence ServiceChange response.  The MG shall issue error 505 - Command
Received before Restart Response.

11.3.  Negotiation of a timely response, commands are repeated. Most commands are
not idempotent. Protocol Version

The state first ServiceChange command from an MG shall contain the version
number of the protocol supported by the MG would become unpredictable if, for
example, Add commands were executed several times.  The transmission
procedures in the ServiceChangeVersion
parameter. Upon receiving such a message, if the MGC supports only a
lower version, then the MGC shall thus provide an "At-Most-Once" functionality.

MECACO/Recommendation H.248 entities are expected send a ServiceChangeReply with the
lower version and thereafter all the messages between MG and MGC shall
conform to the lower version of the protocol. If the MG is unable to
comply, it shall reject the association, with Error 406 Version Not Sup-
ported.

If the MGC supports a higher version than the MG but is able to keep in memory support
the lower version proposed by the MG, it shall send a
list of ServiceChangeReply
with the responses that they sent to recent transactions lower version and a list
of thereafter all the transactions that are currently outstanding. The transaction
identifiers of incoming messages are compared between MG and
MGC shall conform to the transaction iden-
tifiers lower version of the recent responses. protocol. If a match is found, the entity does
not execute the transaction, but simply repeats the response. The
remaining messages will be compared MGC is
unable to comply, it shall reject the list association, with Error 406 Ver-
sion Not Supported.

Protocol version negotiation may also occur at "handoff" and "failover"
ServiceChanges.

11.4.  Failure of current transactions. an MG

If a match MG fails, but is found, indicating capable of sending a duplicate transaction, the entity does
not execute message to the transaction, which is simply ignored.

The procedure uses MGC, it sends
a long timer value, noted LONG-TIMER in the follow-
ing.  The timer should be set larger than ServiceChange with an appropriate method (graceful or forced) and
specifies the maximum duration of Root TerminationID.  When it returns to service, it sends
a
transaction, which should take into account ServiceChange with a "Restart" method.

Allowing the maximum number MGC to send duplicate messages to both MGs accommodates

Internet draft              MEGACO Protocol             January 27, 2000

pairs of
repetitions, the maximum value MGs that are capable of redundant failover of one of the repetition timer and MGs.
Only the maximum
propagation delay of a packet in Working MG shall accept or reject transactions.  Upon failover,
the network.  A suggested value is 30
seconds. Primary MG sends a ServiceChange command with a "Failover" method
and a "MG Impending Failure" reason.  The copy of MGC then uses the primary MG
as the responses may be destroyed either LONG-TIMER seconds
after active MG.  When the response error condition is issued, or when repaired, the Working MG (or the MGC) receives
can send a
confirmation that the response has been received, through the "Response
Acknowledgement parameter". For transactions that are acknowledged
through this parameter, "ServiceChange" with a "Restart" method.

11.5.  Failure of an MGC

If the MG shall keep detects a copy failure of the transaction-id
for LONG-TIMER seconds after the response is issued, in order its controlling MGC, it attempts to detect
and ignore duplicate copies of con-
tact the transaction response next MGC on its pre-provisioned list.  It starts its attempts
at the beginning (Primary MGC), unless that could be
produced by was the network.

Internet draft              MEGACO Protocol           September 21, 1999

19.2.  Transaction identifiers MGC that failed, in
which case it starts at its first Secondary MGC.  It sends a Servi-
ceChange message with a "Failover" method and three-way handshake

Transaction identifiers are 32 bit integer numbers.  An Media Gateway
Controller may decide to use a specific number space for each of the MGs
that they manage, " MGC Impending Failure"
reason.

In partial failure, or manual maintenance reasons, an MGC may wish to use the same number space for all
direct its controlled MGs that
belong to some arbitrary group.  MGCs may decide use a different MGC.  To do so, it sends a
ServiceChange method to share the load of
managing MG with a large "HandOff" method, and its desig-
nated replacement in MGCIdToTry. The MG between several independent processes.  These
processes will share the same transaction number space.  There are mul-
tiple possible implementations of this sharing, such as having should send a ServiceChange mes-
sage with a cen-
tralized allocation of transaction identifiers, or pre-allocating non-
overlapping ranges of identifiers "Failover" method and a "MGC directed change" reason to different processes.  The implemen-
tations shall guarantee that unique transaction identifiers are allo-
cated the
designated MGC.  If it fails to all transactions that originate from get a logical reply, or fails to see an Audit
command subsequently, it should behave as if its MGC failed, and start
contacting secondary MGCs. MGs can
simply detect duplicate transactions by looking at  If the transaction iden-
tifier only.

The Response Acknowledgement parameter can be found in MG is unable to establish a control
relationship with any message. It
carries MGC, it shall wait a set of "confirmed transaction-id ranges." Entities may choose
to delete the copies random amount of the responses to transactions whose id is
included in "confirmed transaction-id ranges" received time as
described in section 9.2 and then start contacting its primary, and if
necessary, its secondary MGCs again.

No recommendation is made on how the transac-
tion response messages. They should silently discard further commands
when MGCs involved in the transaction-id falls within these ranges.

The "confirmed transaction-id ranges" values shall not Handoff main-
tain state information; this is considered to be used if more
than LONG-TIMER seconds have elapsed since the out of scope of this
recommendation. The MGC and MG issued its last
response to that MGC, or may take the following steps when Handoff
occurs.  When the MGC initiates a MG resumes operation.  In this situa-
tion, transactions HandOff, the handover should be accepted and processed, without any test tran-
sparent to Operations on the transaction-id.

Messages that carry the "Response Acknowledgement" parameter may Media Gateway.  Transactions can be
transmitted exe-
cuted in any order.  The entity shall retain the union of the
"confirmed transaction-id ranges" received order, and could be in recent messages.

19.3.  Computing retransmission timers

It progress when the ServiceChange is
executed. Accordingly, commands in progress continue, transaction
replies are sent to the responsibility of new MGC (after a new control association is
established), and the requesting entity to provide suitable
time outs for all MG should expect outstanding transactions, and to retry transactions
when time outs have been exceeded. Furthermore, when repeated transac-
tions fail to transaction replies
from the new MGC.  No new messages shall be acknowledged, it is sent to the responsibility of new MGC until
the request-
ing entity control association is established.  Repeated transaction requests
shall be directed to seek redundant services and/or clear existing or pending
connections.

The specification purposely avoids specifying any value for the
retransmission timers. These values are typically network dependent. new MGC.  The
retransmission timers should normally estimate MG shall maintain state on all
terminations and contexts.

It is possible that the timer value MGC could be implemented in such a way that a
failed MGC is replaced by
measuring the time spent between the sending of a command and working MGC where the return identity of a response. One possibility the new
MGC is to use the algorithm implemented in
TCP-IP, which uses two variables:

Internet draft              MEGACO Protocol           September 21, 1999 same as the average acknowledgement delay, AAD, estimated through an exponen-
tially smoothed average of failed one.  In such a case, MGCIdToTry would be
specified with the observed delays,

* previous value and the average deviation, ADEV, estimated through an exponentially
     smoothed average MG shall behave as if the
value was changed, and send a ServiceChange message, as above.

Internet draft              MEGACO Protocol             January 27, 2000

Pairs of the absolute value MGCs that are capable of redundant failover can notify the difference between con-
trolled MGs of the observed delay and failover by the current average. above mechanism.

12.  PACKAGE DEFINITION

The retransmission
     timer, in TCP, primary mechanism for extension is set to the sum of the average delay plus N times
     the average deviation. In MEGACO/Recommendation H.248, the maximum
     value by means of the timer should however Packages.  Packages
define additional Properties, Events, Signals and Statistics that may
occur on Terminations.

Packages defined by IETF will appear in separate RFCs.

Packages relevant to H.323 systems are listed in an Annex to Recommenda-
tion H.323.

Packages defined by ITU-T will be bounded, described in order Annexes to guarantee
     that no repeated packet would H.248.

1)   A public document or a standard forum document, which can be received by refer-
     enced as the gateways after
     LONG-TIMER seconds.  A suggested maximum value is 4 seconds.

After any retransmission, document that describes the entity should do package following the following:

*    It
     guideline above, should double be specified.

2)   The document shall specify the estimated value version of the average delay, AAD

*    It Package that it
     describes.

3)   The document should compute be available on a random value, uniformly distributed between 0.5
     AAD public web server and AAD

*    It should set the retransmission timer
     have a stable URL. The site should provide a mechanism to provide
     comments and appropriate responses should be returned.

12.1.  Guidelines for defining packages

Packages define Properties, Events, Signals, and Statistics.

Names of all such defined constructs shall consist of the sum PackageID
(which uniquely identifies the package) and the ID of the item (which
uniquely identifies the item in that random
     value and N times package).  In the text encoding the average deviation.

This procedure has
two effects. Because it includes an exponentially
increasing component, it will automatically slow down shall be separated by a forward slash ("/") character. Example:
togen/playtone is the stream of mes-
sages text encoding to refer to the play tone signal in case of congestion. Because it includes a random component, it
the tone generation package.

A Package will break contain the potential synchronization between notifications triggered
by following sections:

12.1.1.  Package Overall description of the same external event.

19.4.  Provisional responses Executing some transactions package, specifying:

     Package Name: only descriptive,

     PackageID:  Is an identifier, its text encoding may require not be a
long time. Long execution times may interact with the timer based
retransmission procedure. This may result either key-
     word in an inordinate number the base protocol      Description:

     Version: A new version of retransmissions, a package can only add additional

Internet draft              MEGACO Protocol             January 27, 2000

     Properties, Events, Signals, Statistics and new possible values for
     an existing parameter described in the original package. No dele-
     tions or modifications shall be allowed. A version is an integer in timer values that become too long
     the range from 1 to 99.

     Extends (Optional): A package may extend an existing package. The
     version of the original package must be effi-
cient. Entities that can predict that a transaction will require specified. When a long
execution time may send package
     extends another package it shall only add additional Properties,
     Events, Signals, Statistics and new possible values for an existing
     parameter described in the original package. An extended package
     shall not redefine or overload a provisional response, "Transaction Pending".
They should send this response name defined in the original pack-
     age.  Hence, if they receive a repetition package B version 1 extends package A version 1,
     version 2 of a tran-
saction that is still being executed.

Entities that receive a Transaction Pending shall switch B will not be able to extend the A version 2 if A ver-
     sion 2 defines a longer
repetition timer for that transaction.  The root termination has name already in B version 1.

12.1.2.  Properties

Properties defined by the package, specifying:

      Property Name: only descriptive.
      PropertyID:  Is an identifier
      Description:
      Type: One of:
              String: UTF-8 string
              Integer: 4 byte signed integer
              Double: 8 byte signed integer
              Character: Unicode UTF-8 encoding of a pro-
perty (ProvisionalResponseTimerValue) which can single letter.
                Could be set to the requested
maximum number more than one octet.
              Enumeration: One of milliseconds between receipt a list of possible unique values
                  (See 12.3)
              Sub-list: A list of several values from a command list
              Boolean
      Possible Values:
      Defined in: Which descriptor the property is defined in.
            LocalControl is for stream dependent properties.
            TerminationState is for stream independent properties.
      Characteristics: Read / Write or both, and
transmission of (optionally), global:
            Indicates whether a property is read-only, or read-write,
            and if it is global.  If Global is omitted, the TransactionPending response.

The protocol property
            is organized as not global.  If a set of transactions, each property is declared as global,
            the value of which the property is
composed request shared by all terminations
            realizing the package.

12.1.3.  Events

Events defined by the package, specifying:

Internet draft              MEGACO Protocol             January 27, 2000

      Event name: only descriptive.
      EventID:  Is an identifier
      Description:
      EventsDescriptor Parameters:
            Parameters used by the MGC to configure the event,
            and a response, commonly referred found in the EventsDescriptor.  See section 12.2
      ObservedEventsDescriptor Parameters:
            Parameters returned to as the MGC in Notify requests
            and in replies to command requests from the MGC that
            audit ObservedEventsDescriptor, and found in the
            ObservedEventsDescriptor.  See section 12.2

12.1.4.  Signals

Signals defined by the package, specifying:
      Signal Name: only descriptive.
      SignalID:  Is an acknowledge-
ment.  The protocol messages, being carried over UDP, identifier. SignalID is used in a
            SignalsDescriptor
        Description
        SignalType: One of:
                        OO (On/Off)
                        TO (TimeOut)
                        BR (Brief)

Note: SignalType may be subject to
losses. In defined such that it is dependent on the absence value
of one or more parameters. Signals that would be played with SignalType
BR should have a timely response, transactions are repeated.
Entities are expected default duration. The package has to keep define the default
duration and signalType.

        Duration: in hundredths of seconds
      Additional Parameters: See section 12.2

12.1.5.  Statistics

Statistics defined by the package, specifying:
      Statistic name: only descriptive.
      StatisticID:  Is an identifier
            StatisticID is used in memory a list StatisticsDescriptor
      Description
      Units: unit of measure, e.g. milliseconds, packets

12.1.6.  Procedures

Additional guidance on the use of the responses that package.

Internet draft              MEGACO Protocol           September 21, 1999

they sent             January 27, 2000

12.2.  Guidelines to recent transactions, i.e. defining  Properties, Statistics and Parameters to
Events and Signals.

Parameter Name: only descriptive
      ParameterID: Is an identifier
      Type: One of:
              String: UTF-8 octet string
              Integer: 4 octet signed integer
              Double: 8 octet signed integer
              Character: Unicode UTF-8 encoding of a list single letter.
                  Could be more than one octet.
              Enumeration: One of all the responses they
sent over the last LONG-TIMER seconds, and a list of the transactions
that are currently being executed.

The transaction identifiers of incoming transactions are compared to the
transaction identifiers possible unique
                  values (See 12.3)
              Sub-list: A list of the recent responses. If several values from a match list
              Boolean
      Possible values:
      Description:

12.3.  Lists

Possible values for parameters include enumerations.  Enumerations may
be defined in a list.  It is found, recommended that the entity does not execute list be IANA
registered so that packages that extend the transaction, but simply repeats list can be defined without
concern for conflicting names.

12.4.  Identifiers

Identifiers in text encoding shall be strings of up to 64 characters,
containing no spaces, starting with an alphanumeric character and con-
sisting of alphanumeric characters and / or digits, and possibly includ-
ing the
response. special character underscore ("_").  Identifiers in binary
encoding are 2 octets long.  Both text and binary values shall be speci-
fied for each identifier, including identifiers used as values in
enumerated types.

12.5.  Package Registration

A package can be registered with IANA for interoperability reasons.  See
section 13 for IANA considerations.

13.  IANA CONSIDERATIONS

13.1.  Packages

The remaining transactionIds will following considerations SHALL be compared met to the list of
current transactions. If a match is found, the entity does not execute
the transaction, which is simply ignored - register a response will be provided
when the execution of the transaction package with
IANA:

Internet draft              MEGACO Protocol             January 27, 2000

1.   A unique string name, unique serial number and version number is complete.
     registered for each package.  The repetition mechanism string name is used to guard against three types of possi-
ble errors:

*    transmission errors, when with text
     encoding.  The serial number shall be used with binary encoding.
     Serial Numbers 60000-64565 are reserved for example a packet private use. Serial
     number 0 is lost due to noise
     on a line or congestion in a queue,

*    component failure, when reserved.

2.   A contact name, email and postal addresses for example an interface that contact shall
     be specified.  The contact information shall be updated by the
     defining organization as necessary.

3.   A reference to a entity
     becomes unavailable,

*    Entity failure, when for example an entire entity become unavail-
     able,

The entities document that describes the package, which should
     be able to derive from public: The document shall specify the past history an estimate version of the packet loss rate due to transmission errors.  In a properly con-
figured system, this loss rate Package
     that it describes.  If the document is public, it should be kept very low, typically less
than 1%.  If located
     on a public web server and should have a Media Gateway Controller or stable URL. The site
     should provide a Media Gateway has mechanism to repeat
a message more provide comments and appropriate
     responses should be returned.

4.   Packages registered by other than recognized standards bodies shall
     have a few times, it is very legitimate minimum package name length of 8 characters

5.   All other package names are first come-first served if all other
     conditions are met

13.2.  Error Codes

The following considerations SHALL be met to assume that
something else than a transmission register an error is occurring.  For example,
given code with
IANA:

1.   An error number and a loss rate one line (80 character maximum) string is
     registered for each error.

2.   A complete description of 1%, the probability that 5 consecutive transmission
attempts fail conditions under which the error is 1
     detected shall be included in 100 billion, an event that should occur less than
once every 10 days for a Media Gateway Controller that processes 1,000
transactions per second. (Indeed, publicly available document.  The
     description shall be sufficiently clear to differentiate the error
     from all other existing error codes.

3.   The document should be available on a public web server and should
     have a stable URL.

4.   Error numbers registered by recognized standards bodies shall have
     3 or 4 character error numbers.

5.   Error numbers registered by all other organizations or individuals
     shall have 4 character error numbers.

6.   An error number of repetition shall not be redefined, nor modified except by the
     organization or individual that is con-
sidered excessive should originally defined it, or their
     successors or assigns.

Internet draft              MEGACO Protocol             January 27, 2000

13.3.  ServiceChange Reasons

The following considerations SHALL be a function met to register service change
reason with IANA:

1.   A one phrase, 80-character maximum, unique reason code is
     registered for each reason.

2.   A complete description of the prevailing packet loss
rate.) We should note that the "suspicion threshold", conditions under which we will call
"Max1", is normally lower than the "disconnection threshold", which
should reason is
     used is detected shall be set to included in a larger value.

{Editor's note, publicly available docu-
     ment.  The description shall be sufficiently clear to differentiate
     the following is reason from all intertwined with MGCP failover
mechanism, it must other existing reasons.

3.   The document should be edited to deal with whatever we decide to use in
MEGACO/H.248}

Internet draft              MEGACO Protocol           September 21, 1999

            Transaction issued: N=0
                     |
            transmission: N++
                    |  +------------ retransmission: N++ -----------+
                    |  |                                            |
                    |  |       transmission                         |
                    |  |  +---to new address -+<--------------------|--+
                    |  |  |        N=0        |                     |  |
                    V  V  V                   |                     |  |
              +-----------+                   |                     |  |
              | awaiting  |--- new entity --> +  +------------+     |  |
              |  response |--- timer elapsed --->| N > Max1 ? |-(no)+  |
              +-----------+ <----------+         +------------+     ^  |
                    |   |              |               |            |  |
                    |   +- wrong key? -+             (yes)          |  |
                    |                                  |            |  |
            response received                    (if N=Max1,        |  |
                    |                             or N=Max2         |  |
                    |                             check DNS)        |  |
                    v                                  |            |  |
                  (end)                       +---------------+     |  |
                                              |more addresses?|(yes)|--+
                                              +---------------+     |
                                                       |            |
                                                     (no)           |
                                                       |            |
                                                 +------------+     |
                                                 | N > Max2 ? |(no)-+
                                                 +------------+
                                                       |
                                                     (yes)
                                                       |
                                                       v
                                                (disconnected) available on a public web server and should
     have a stable URL.

14.  CONTACT INFORMATION

IETF Editor
      Brian Rosen
      Marconi
      1000 FORE Drive
      Warrendale, PA  15086
      U.S.A.
      Phone: +1 724-742-6826
      Email: brosen@fore.com

ITU Editor
      John Segers
      Lucent Technologies
      Room HE 306
      Dept. Forward Looking Work
      P.O. Box 18, 1270 AA  Huizen
      Netherlands
      Phone: +31 35 687 4724
      Email: jsegers@lucent.com

Additional IETF Authors
      Fernando Cuervo
      Nortel Networks
      P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7
      Canada
      Email: cuervo@nortelnetworks.com

      Bryan Hill
      Gotham Networks
      15 Discovery Way
      Acton, MA 01720

Internet draft              MEGACO Protocol             January 27, 2000

      USA
      Phone: +1 978-263-6890
      Email: bhill@gothamnetworks.com

      Christian Huitema
      Telcordia Technologies
      MCC 1J236B
      445 South Street
      Morristown, NJ 07960
      U.S.A.
      Phone: +1 973-829-4266
      EMail: huitema@research.telcordia.com

      Nancy Greene
      Nortel Networks
      P.O. Box 3511 Stn C
      Ottawa, ON, K1Y 4H7
      Canada
      Phone: +1 514-271-7221
      Email: ngreene@nortelnetworks.com

      Abdallah Rayhan
      Nortel Networks
      P.O. Box 3511 Stn C
      Ottawa, ON, K1Y 4H7
      Canada
      Phone: +1 613-763-9611
      Email: arayhan@nortelnetworks.com

ANNEX A classic retransmission algorithm would simply count BINARY ENCODING OF THE PROTOCOL (NORMATIVE)

This Annex specifies the number syntax of suc-
cessive repetitions, and conclude that the association is broken after
re-transmitting messages using the packet an excessive number notation defined
in ASN.1 [ITU-T Recommendation X.680 (1997): Information Technology -
Abstract Syntax Notation One (ASN.1) - Specification of times (typically
between 7 and 11 times.) In order to account basic nota-
tion.]. Messages shall be encoded for transmission by applying the possibility basic
encoding rules specified in [ITU-T Recommendation X.690(1994) Informa-
tion Technology - ASN.1  Encoding Rules: Specification  of an
undetected or in-progress "failover", we modify the classic algorithm so
that if  Basic
Encoding Rules (BER)].

A.1.  Coding of wildcards

The use of wildcards ALL and CHOOSE is allowed in the Media Gateway receives a valid ServiceChange message
announcing protocol.  This
allows a failover, it will start transmitting outstanding commands
to that new MGC.  Responses to commands are still transmitted MGC to partially specify Termination IDs and let the
source address of the command.

In order to automatically adapt to network load, MEGACO/Recommendation

Internet draft              MEGACO Protocol           September 21, 1999

H.248 specifies exponentially increasing timers.  If MG choose
from the initial timer
is set values that conform to 200 milliseconds, the loss of partial specification.  Termination
IDs may encode a fifth retransmission will be
detected after about 6 seconds. hierarchy of names.  This hierarchy is probably an acceptable waiting
delay to detect provisioned. For

Internet draft              MEGACO Protocol             January 27, 2000

instance, a failover. TerminationID may consist of a trunk group, a trunk within
the group and a circuit.  Wildcarding must be possible at all levels.
The repetitions should continue after that
delay not only in order following paragraphs explain how this is achieved.

The ASN.1 description uses octet strings of up to perhaps overcome a transient connectivity
problem, but also 8 octets in order to allow some more time length for the execution
Termination IDs.  This means that Termination IDs consist of at most 64
bits.  A fully specified Termination ID may be preceded by a failover - waiting a total delay sequence of 30 seconds
wildcarding fields.  A wildcarding field is probably acceptable.

It octet in length.  Bit 7 (the
most significant bit) of this octet specifies what type of wildcarding
is however important that invoked:  if the maximum delay bit value equals 1, then the ALL wildcard is used;
if the bit value if 0, then the CHOOSE wildcard is used.  Bit 6 of retransmissions be
bounded.  Prior the
wildcarding field specifies whether the wildcarding pertains to any retransmission, it is checked that one
level in the time
elapsed since hierarchical naming scheme (bit value 0) or to the sending level of
the initial datagram is no greater than T-
MAX. If more than T-MAX time has elapsed, hierarchy specified in the MG concludes that wildcarding field plus all lower levels
(bit value 1).  Bits 0 through 5 of the MGC
has failed, wildcarding field specify the
bit position in the Termination ID at which the starts.

We illustrate this scheme with some examples.  Assume that Termination
IDs are three octets long and it begins its recovery process. that each octet represents a level in a
hierarchical naming scheme.  A valid Termination ID is

        00000001 00011110 01010101.

Addressing ALL names with prefix 00000001 00011110 is done as follows:

        wildcarding field: 10000111
        Termination ID: 00000001 00011110 xxxxxxxx.

The value T-MAX values of the bits labeled "x" is
related irrelevant and shall be ignored by
the receiver.

Indicating to the LONG-TIMER value: receiver that is must choose a name with 00011110 as
the LONG-TIMER value second octet is obtained done as follows:

        wildcarding fields: 00010111 followed by
adding to T-MAX 00000111
        Termination ID: xxxxxxxx 00011110 xxxxxxxx.

The first wildcard field indicates a CHOOSE wildcard for the maximum propagation delay level in
the network.

19.5.  Ordering of commands naming hierarchy starting at bit 23, the highest level in our
assumed naming scheme.  The MEGACO/Recommendation H.248 does not mandate that second wildcard field indicates a CHOOSE
wildcard for the underlying
transport protocol guarantees level in the sequencing naming hierarchy starting at bit 7, the
lowest level in our assumed naming scheme.

Finally, a CHOOSE-wildcarded name with the highest level of transactions sent to an
entity.  This property tends the name
equal to maximize 00000001 is specified as follows:

Internet draft              MEGACO Protocol             January 27, 2000

        wildcard field: 01001111
        Termination ID: 0000001 xxxxxxxx xxxxxxxx .

Bit value 1 at bit position 6 of the timeliness first octet of actions, but
it has a few drawbacks.  For example:

*    Notify commands the wildcard field
indicates that the wildcarding pertains to the specified level in the
naming hierarchy and all lower levels.

Context IDs may also be delayed wildcarded.  In the case of Context IDs, how-
ever, specifying partial names is not allowed.  Context ID 0x0  SHALL be
used to indicate the NULL Context, Context ID 0xFFFFFFFE SHALL be used
to indicate a CHOOSE wildcard, and arrive at Context ID 0xFFFFFFFF SHALL be used
to indicate an ALL wildcard.

TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the MGC after ROOT Ter-
mination.

A.2.  ASN.1 syntax specification

This section contains the
     transmission ASN.1 specification of a new command changing the EventsDescriptor

*    If a new command is transmitted before H.248 protocol syn-
tax.

NOTE - In case a previous one is ack-
     nowledged, there transport mechanism is no guarantee used that prior command will be exe-
     cuted before employs application
level framing, the new one.

Media Gateway Controllers that want to guarantee consistent operation definition of Transaction below changes.  Refer to
the Media Gateway may use annex defining the following rules:

1.   When a Media Gateway handles several Terminations, commands per-
     taining to transport mechanism for the different Terminations may be sent definition that
applies in parallel, for
     example following that case.

NOTE - The ASN.1 specification below contains a model where each Termination (or group clause defining Termina-
tionIDList as a sequence of Ter-
     minations) TerminationIDs.  The length of this sequence
SHALL be one.  The SEQUENCE OF construct is controlled present only to allow future
extensions.

MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=
BEGIN

MegacoMessage ::= SEQUENCE
{
        authHeader      AuthenticationHeader OPTIONAL,
        mess                    Message
}

AuthenticationHeader ::= SEQUENCE
{
        secParmIndex    SecurityParmIndex,
        seqNum            SequenceNum,
        ad              AuthData

Internet draft              MEGACO Protocol             January 27, 2000

}

SecurityParmIndex ::= OCTET STRING(SIZE(4))

SequenceNum       ::= OCTET STRING(SIZE(4))

AuthData          ::= OCTET STRING (SIZE (16..32))

Message ::= SEQUENCE
{
        version         INTEGER(0..99),
        mId             MId,    -- Name/address of message originator
        messageBody             CHOICE
        {
                messageError    ErrorDescriptor,
                transactions    SEQUENCE OF Transaction
        },
        ...
}

MId ::= CHOICE
{
        ip4Address                              IP4Address,
        ip6Address                              IP6Address,
        domainName                      DomainName,
        deviceName                      PathName,
mtpAddress                              OCTET STRING(SIZE(5)),
 -- Addressing structure of mtpAddress:
 --        15                0
 --        |  PC        | NI |
 --           14 bits    2 bits
      ...
}

DomainName ::= SEQUENCE
{
name            IA5String,
-- The name starts with an alphanumeric digit followed by its own process or its own thread.

2.   In a given Context, there should normally be only one outstanding
-- sequence of alphanumeric digits, hyphens and dots.  No two
-- dots shall occur consecutively.
portNumber      INTEGER(0..65535) OPTIONAL
}

IP4Address ::= SEQUENCE
{
        address OCTET STRING (SIZE(4)),
        portNumber      INTEGER(0..65535) OPTIONAL
}

Internet draft              MEGACO Protocol             January 27, 2000

IP6Address ::= SEQUENCE
{
address OCTET STRING (SIZE(16)),
        portNumber      INTEGER(0..65535) OPTIONAL
}

PathName ::= IA5String(SIZE (1..64))
-- See section A.3

Transaction ::= CHOICE
{
        transactionRequest      TransactionRequest,
        transactionPending      TransactionPending,
        transactionReply        TransactionReply,
        ...
}

TransactionId ::= INTEGER(0..4294967295)  -- 32 bit unsigned integer

TransactionRequest ::= SEQUENCE
{
        transactionId           TransactionId,
        actions                 SEQUENCE OF ActionRequest,
        ...
}

TransactionPending ::= SEQUENCE
{
        transactionId           TransactionId,
        ...
}

TransactionReply ::= SEQUENCE
{
        transactionId           TransactionId,
        transactionResult       CHOICE
        {
             transactionError   ErrorDescriptor,
             actionReplies      SEQUENCE OF ActionReply
        },
        ...
}

ErrorDescriptor ::= SEQUENCE
{
        errorCode       ErrorCode,
        errorText       ErrorText OPTIONAL

Internet draft              MEGACO Protocol             January 27, 2000

}

ErrorCode ::= INTEGER(0..65535)
-- See section 13 for IANA considerations w.r.t. error codes

ErrorText ::= IA5String

ContextID ::= INTEGER(0..4294967295)

-- Context NULL Value: 0
-- Context CHOOSE Value: 429467294 (0xFFFFFFFE)
-- Context ALL Value: 4294967295 (0xFFFFFFFF)

ActionRequest ::= SEQUENCE
{
        contextId                       ContextID,
        contextRequest          ContextRequest OPTIONAL,
        contextAttrAuditReq     ContextAttrAuditRequest OPTIONAL,
        commandRequests         SEQUENCE OF CommandRequest
}

ActionReply ::= SEQUENCE
{
        contextId               ContextID,
        errorDescriptor ErrorDescriptor OPTIONAL,
        contextReply    ContextRequest OPTIONAL,
        commandReply    SEQUENCE OF CommandReply
}

ContextRequest ::= SEQUENCE
{
        priority        INTEGER(0..15) OPTIONAL,
        emergency       BOOLEAN OPTIONAL,
        topologyReq     SEQUENCE OF TopologyRequest OPTIONAL,
        ...
}

ContextAttrAuditRequest ::= SEQUENCE
{
topology        NULL OPTIONAL,
        emergency       NULL OPTIONAL,
        priority        NULL OPTIONAL,
        ...
}

CommandRequest ::= SEQUENCE
{

Internet draft              MEGACO Protocol             January 27, 2000

        command (Add or         Command,
        optional                NULL OPTIONAL,
        wildcardReturn  NULL OPTIONAL,
        ...
}

Command ::= CHOICE
{
        addReq                  AmmRequest,
        moveReq                 AmmRequest,
        modReq                  AmmRequest,
        -- Add, Move, Modify or Move).  However, a requests have the same parameters
        subtractReq             SubtractRequest,
        auditCapRequest         AuditRequest,
        auditValueRequest       AuditRequest,
        notifyReq               NotifyRequest,
        serviceChangeReq        ServiceChangeRequest,
        ...
}

CommandReply ::= CHOICE
{
        addReply                AmmsReply,
        moveReply               AmmsReply,
        modReply                AmmsReply,
        subtractReply           AmmsReply,
        -- Add, Move, Modify, Subtract command may
     be issued at any time.  In consequence, a Media Gateway may some-
     times receive a Modify command that applies to a previously sub-
     tracted Termination.  Such commands should be ignored, replies have the same parameters
        auditCapReply           AuditReply,
        auditValueReply         AuditReply,
        notifyReply             NotifyReply,
        serviceChangeReply      ServiceChangeReply,
        ...
}

TopologyRequest ::= SEQUENCE
{
        terminationFrom         TerminationID,
        terminationTo           TerminationID,
        topologyDirection       ENUMERATED
        {
                bothway(0),
                isolate(1),
                oneway(2)
        }
}

AmmRequest ::= SEQUENCE
{

Internet draft              MEGACO Protocol             January 27, 2000

        terminationID           TerminationIDList,
        mediaDescriptor         MediaDescriptor OPTIONAL,
        modemDescriptor         ModemDescriptor OPTIONAL,
        muxDescriptor           MuxDescriptor OPTIONAL,
        eventsDescriptor        EventsDescriptor OPTIONAL,
        eventBufferDescriptor   EventBufferDescriptor OPTIONAL,
        signalsDescriptor       SignalsDescriptor OPTIONAL,
        digitMapDescriptor      DigitMapDescriptor OPTIONAL,
        auditDescriptor         AuditDescriptor OPTIONAL,
        ...
}

AmmsReply ::= SEQUENCE
{
        terminationID   TerminationIDList,
        terminationAudit                TerminationAudit OPTIONAL
}

SubtractRequest ::= SEQUENCE
{
        terminationID                   TerminationIDList,
        auditDescriptor                 AuditDescriptor OPTIONAL
}

AuditRequest ::= SEQUENCE
{
        terminationID           TerminationID,
        auditDescriptor         AuditDescriptor OPTIONAL
}

AuditReply ::= SEQUENCE
{
        terminationID           TerminationID,
        auditResult                     AuditResult
}

AuditResult ::= CHOICE
{
        contextAuditResult      TerminationIDList,
        terminationAuditResult  TerminationAudit
}

AuditDescriptor ::= SEQUENCE
{
auditToken      BIT STRING
{

Internet draft              MEGACO Protocol             January 27, 2000

                                muxToken(0), modemToken(1), mediaToken(2),
eventsToken(3), signalsToken(4),
digitMapToken(5), statsToken(6),
observedEventsToken(7),
packagesToken(8), eventBufferToken(9)
} OPTIONAL,
        ...
}

TerminationAudit ::= SEQUENCE OF AuditReturnParameter

AuditReturnParameter ::= CHOICE
{
        errorDescriptor                 ErrorDescriptor,
mediaDescriptor                         MediaDescriptor,
        modemDescriptor                         ModemDescriptor,
        muxDescriptor                   MuxDescriptor,
        eventsDescriptor                EventsDescriptor,
        eventBufferDescriptor           EventBufferDescriptor,
        signalsDescriptor               SignalsDescriptor,
        digitMapDescriptor              DigitMapDescriptor,
        observedEventsDescriptor        ObservedEventsDescriptor,
        statisticsDescriptor            StatisticsDescriptor,
        packagesDescriptor              PackagesDescriptor,
        ...
}

NotifyRequest ::= SEQUENCE
{
        terminationID                   TerminationIDList,
        observedEventsDescriptor        ObservedEventsDescriptor,
        errorDescriptor                 ErrorDescriptor OPTIONAL
}

NotifyReply ::= SEQUENCE
{
        terminationID                           TerminationIDList OPTIONAL,
        errorDescriptor                         ErrorDescriptor OPTIONAL
}

ObservedEventsDescriptor ::= SEQUENCE
{
        requestId                               RequestID,
        observedEventLst                        SEQUENCE OF ObservedEvent
}

ObservedEvent ::= SEQUENCE
{

Internet draft              MEGACO Protocol             January 27, 2000

        eventName                               EventName,
        streamID                                StreamID OPTIONAL,
        eventParList                    SEQUENCE OF EventParameter,
        timeNotation                    TimeNotation OPTIONAL
}

EventName ::= PkgdName

EventParameter ::= SEQUENCE
{
        eventParameterName      Name,
        value                           Value
}

ServiceChangeRequest ::= SEQUENCE
{
        terminationID                   TerminationIDList,
        serviceChangeParms              ServiceChangeParm
}

ServiceChangeReply ::= SEQUENCE
{
        terminationID                   TerminationIDList,
        serviceChangeResult             ServiceChangeResult
}

-- For ServiceChangeResult, no parameters are mandatory.  Hence the
-- distinction between ServiceChangeParm and an error
     code should be returned.

3.   On a given Termination, there should normally be only one outstand-
     ing Notify command at any time.  The RequestId parameter should be
     used to correlate Notify commands with ServiceChangeResParm.

ServiceChangeResult ::= CHOICE
{
        errorDescriptor                 ErrorDescriptor,
        serviceChangeResParms           ServiceChangeResParm
}

WildcardField ::= OCTET STRING(SIZE(1))

TerminationID ::= SEQUENCE
{
        wildcard        SEQUENCE OF WildcardField,
        id              OCTET STRING(SIZE(1..8))
}
-- See Section A.1 for explanation of wildcarding mechanism.
-- Termination ID 0xFFFFFFFFFFFFFFFF indicates the triggering notification ROOT Termination.

TerminationIDList ::= SEQUENCE OF TerminationID

MediaDescriptor ::= SEQUENCE

Internet draft              MEGACO Protocol           September 21, 1999

     request.

4.             January 27, 2000

{

        termStateDescr  TerminationStateDescriptor OPTIONAL,
        streams         CHOICE
                                {
                                        oneStream       StreamParms,
                                        multiStream     SEQUENCE OF StreamDescriptor
                                },
        ...
}

StreamDescriptor ::= SEQUENCE
{
        streamID                        StreamID,
        streamParms                             StreamParms
}

StreamParms ::= SEQUENCE
{
        localControlDescriptor          LocalControlDescriptor OPTIONAL,
        localDescriptor                 LocalRemoteDescriptor OPTIONAL,
        remoteDescriptor                LocalRemoteDescriptor OPTIONAL,
        ...
}

LocalControlDescriptor ::= SEQUENCE
{
        streamMode      StreamMode OPTIONAL,
        reserve         BOOLEAN,
        propertyParms   SEQUENCE OF PropertyParm,
        ...
}

StreamMode ::= ENUMERATED
{
        sendOnly(0),
        recvOnly(1),
        sendRecv(2),
        inactive(3),
        loopBack(4),
        delete(5),
        ...
}

-- In some cases, an implicitly or explicitly wildcarded Subtract com-
     mand that applies to a group of Terminations may step in front of PropertyParm, value is a
     pending Add command.  The Media Gateway Controller should individu-
     ally delete all connections whose completion was pending at SEQUENCE OF octet string.  When sent
-- by an MGC the
     time interpretation is as follows:
-- empty sequence means CHOOSE
-- one element sequence specifies value

Internet draft              MEGACO Protocol             January 27, 2000

-- longer sequence means "choose one of the global Subtract command.  Also, new Add commands for
     Terminations named by the wild- carding values"
-- The relation field may not only be sent until selected if the
     wild-carded Subtract command is acknowledged.

5.   AuditValue and AuditCapability is not subject to any sequencing.

6.   ServiceChange shall always be value sequence
-- has length 1.  It indicates that the first command sent by a MG as
     defined by has to choose a value
-- for the restart procedure. Any other command or response
     must be delivered after this ServiceChange command.

These rules do not affect property. E.g., x > 3 (using the Media Gateway, which should always respond greaterThan
-- value for relation) instructs the MG to commands.

19.6.  Fighting choose any value larger
-- than 3 for property x.
-- The range field may only be selected if the restart avalanche

Let's suppose that a large number of Media Gateways are powered on
simultaneously.  If they were value sequence
-- has length 2.  It indicates that the MG has to all initiate choose a ServiceChange transac-
tion, value
-- in the Media Gateway Controller would very likely be swamped, leading
to message losses range between the first octet in the value sequence and network congestion during
-- the critical period trailing octet in the value sequence, including the
-- boundary values.
-- When sent by the MG, only responses to an AuditCapability request
-- may contain multiple values, a range, or a relation field.

PropertyParm ::= SEQUENCE
{
        name            PkgdName,
        value   SEQUENCE OF OCTET STRING,
        extraInfo       CHOICE
        {
                relation        Relation,
                range           BOOLEAN
        } OPTIONAL

}

Name ::= OCTET STRING(SIZE(2))

PkgdName ::= OCTET STRING(SIZE(4))
-- represents Package Name (2 octets) plus Property Name (2 octets)
-- To wildcard a package use 0xFFFF for first two octets, choose
-- is not allowed. To reference native property tag specified in
-- Annex C, use 0x0000 as first two octets.

Relation ::= ENUMERATED
{
        greaterThan(0),
        smallerThan(1),
        unequalTo(2),
        ...
}

LocalRemoteDescriptor ::= SEQUENCE
{
        propGrps        SEQUENCE OF PropertyGroup,
        ...
}

Internet draft              MEGACO Protocol             January 27, 2000

PropertyGroup ::= SEQUENCE OF PropertyParm

TerminationStateDescriptor ::= SEQUENCE
{
        propertyParms       SEQUENCE OF PropertyParm,
        eventBufferFlag   BOOLEAN,
        serviceState        ServiceState OPTIONAL,
        ...
}

ServiceState ::= ENUMERATED
{
        test(0),
        outOfSvc(1),
        inSvc(2),
      ...
}

MuxDescriptor   ::= SEQUENCE
{
        muxType                 MuxType,
        termList        SEQUENCE OF TerminationID,
        ...
}

MuxType ::= ENUMERATED
{
        h221(0),
        h223(1),
        h226(2),
        v76(3),
        ...
}

StreamID ::= INTEGER(0..65535)  -- 16 bit unsigned integer

EventsDescriptor ::= SEQUENCE
{
        requestID               RequestID,
        eventList               SEQUENCE OF RequestedEvent
}

RequestedEvent ::= SEQUENCE
{
        pkgdName        PkgdName,
        streamID                StreamID OPTIONAL,
        eventAction     RequestedActions OPTIONAL,
        evParList       SEQUENCE OF EventParameter

Internet draft              MEGACO Protocol             January 27, 2000

}

RequestedActions ::= SEQUENCE
{
        keepActive                      BOOLEAN,
        eventDM                 EventDM OPTIONAL,
        secondEvent             SecondEventsDescriptor OPTIONAL,
        signalsDescriptor       SignalsDescriptor OPTIONAL,
        ...
}

EventDM ::= CHOICE
{       digitMapName    DigitMapName,
        digitMapValue   DigitMapValue
}

SecondEventsDescriptor ::= SEQUENCE
{
        requestID                       RequestID,
        eventList                       SEQUENCE OF SecondRequestedEvent
}

SecondRequestedEvent ::= SEQUENCE
{
        pkgdName                PkgdName,
        streamID                        StreamID OPTIONAL,
        eventAction             SecondRequestedActions OPTIONAL,
        evParList               SEQUENCE OF EventParameter
}

SecondRequestedActions ::= SEQUENCE
{
        keepActive                      BOOLEAN,
        eventDM                 EventDM OPTIONAL,
        signalsDescriptor       SignalsDescriptor OPTIONAL,
        ...
}

EventBufferDescriptor ::= SEQUENCE OF ObservedEvent

SignalsDescriptor ::= SEQUENCE OF SignalRequest

SignalRequest ::=CHOICE
{
        signal          Signal,
        seqSigList              SeqSigList
}

Internet draft              MEGACO Protocol             January 27, 2000

SeqSigList ::= SEQUENCE
{
        id              INTEGER(0..65535),
        signalList      SEQUENCE OF Signal
}

Signal ::= SEQUENCE
{
        signalName              SignalName,
        streamID                StreamID OPTIONAL,
        sigType         SignalType OPTIONAL,
        duration                INTEGER (0..65535) OPTIONAL,
        notifyCompletion        RequestID OPTIONAL,
        sigParList              SEQUENCE OF SigParameter
}

SignalType ::= ENUMERATED
{
        brief(0),
        onOff(1),
        timeOut(2),
        ...
}

SignalName ::= PkgdName

SigParameter ::= SEQUENCE
{
        sigParameterName                Name,
        value                           Value
}

RequestID ::= INTEGER(0..4294967295)   -- 32 bit unsigned integer

ModemDescriptor ::= SEQUENCE
{
mtl     SEQUENCE OF ModemType,
        mpl     SEQUENCE OF PropertyParm

}

ModemType ::= ENUMERATED
{
        v18(0),
        v22(1),
        v22bis(2),
        v32(3),
        v32bis(4),

Internet draft              MEGACO Protocol             January 27, 2000

        v34(5),
        v90(6),
        v91(7),
        synchISDN(8),
        ...
}

DigitMapDescriptor ::= SEQUENCE
{
        digitMapName    DigitMapName,
        digitMapValue   DigitMapValue
}

DigitMapName ::= Name

DigitMapValue ::= SEQUENCE
{
        startTimer              INTEGER(0..99) OPTIONAL,
        shortTimer              INTEGER(0..99) OPTIONAL,
        longTimer               INTEGER(0..99) OPTIONAL,
        digitMapBody    IA5String
        -- See Section A.3 for explanation of
service restoration. In order to prevent such avalanches, the following
behavior is suggested:

1.   When a Media Gateway is powered on, it should initiate a restart
     timer to a random value, uniformly distributed between 0 digit map syntax
}

ServiceChangeParm ::= SEQUENCE
{
        serviceChangeMethod     ServiceChangeMethod,
        serviceChangeAddress    ServiceChangeAddress OPTIONAL,
        serviceChangeVersion    INTEGER(0..99) OPTIONAL,
        serviceChangeProfile    ServiceChangeProfile OPTIONAL,
        serviceChangeReason     Value,
        serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
                                    -- 32 bit unsigned integer
        serviceChangeMgcId      MId OPTIONAL,
        timeStamp                       TimeNotation OPTIONAL,
}

ServiceChangeAddress ::= CHOICE
{
        portNumber                      INTEGER(0..65535), -- TCP/UDP port number
        ip4Address                      IP4Address,
        ip6Address                      IP6Address,
        domainName              DomainName,
        deviceName              PathName,
mtpAddress                      OCTET STRING(SIZE(5)),
        ...
}

Internet draft              MEGACO Protocol             January 27, 2000

ServiceChangeResParm ::= SEQUENCE
{
        serviceChangeMgcId      MId OPTIONAL,
        serviceChangeAddress    ServiceChangeAddress OPTIONAL,
        serviceChangeVersion    INTEGER(0..99) OPTIONAL,
serviceChangeProfile    ServiceChangeProfile OPTIONAL
}

ServiceChangeMethod ::= ENUMERATED
{
        failover(0),
        forced(1),
        graceful(2),
        restart(3),
        disconnected(4),
        handOff(5),
        ...
}

ServiceChangeProfile ::= SEQUENCE
{
        profileName     Name,
        version         INTEGER(0..99)
}

PackagesDescriptor ::= SEQUENCE OF PackagesItem

PackagesItem ::= SEQUENCE
{
packageName             Name,
packageVersion  INTEGER(0..99)
}

StatisticsDescriptor ::= SEQUENCE OF StatisticsParameter

StatisticsParameter ::= SEQUENCE
{
        statName                PkgdName,
        statValue               Value
}

TimeNotation ::= SEQUENCE
{
        date            IA5String(SIZE(8)),  -- yyyymmdd format
        time            IA5String(SIZE(8))  -- hhmmssss format
}

Value ::= OCTET STRING

Internet draft              MEGACO Protocol             January 27, 2000

END

A.3.  Digit maps and path names

>From a max-
     imum waiting delay (MWD). Care should be taken to avoid synchroni-
     city of the random number generation between multiple Media Gate-
     ways that would use the same algorithm.

2. syntactic viewpoint, digit maps are strings with syntactic res-
trictions imposed upon them. The Media Gateway should then wait for either the end of this timer
     or the detection syntax of a local user activity, such as for example an
     off-hook transition on a residential Media Gateway.

3.   When the timer elapses, or when an activity valid digit maps is detected, the Media
     Gateway should initiate the restart procedure. specified
in ABNF [RFC 2119].  The restart procedure simply requires the MG to guarantee that the first
message that the Media Gateway Controller sees from this MG is a Servi-
ceChange message informing the Media Gateway Controller about the res-
tart syntax for digit maps presented in this section
is for illustrative purposes only. The value definition of MWD is a configuration parameter that depends on digitMap in Annex B
takes precedence in the type case of differences between the Media Gateway. two.

digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP
            ")" LWSP)
digitStringList = digitString *( LWSP "/" LWSP digitString )
digitString = 1*(digitStringElement)
digitStringElement = digitPosition [DOT]
digitPosition = digitMapLetter / digitMapRange
digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
digitLetter = *((DIGIT "-" DIGIT) / ditigMapLetter)
digitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" /
                                        ; DTMF digits
                  "S"/ "L" /    ; timers (short, long)
                  MFSig
MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3"
LWSP = *(WSP / COMMENT / EOL)
WSP = SP / HTAB
COMMENT = ";" *(SafeChar / RestChar / WSP) EOL
EOL = (CR [LF]) / LF
SP = %x20
HTAB = %x09
CR = &x0D
LF = %x0A
SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / "!" / "_" / "/" /
"'" / "?" / "@" / "^" / "`" / "~" / "*" / "$" / "
"(" / ")" / "%" / "."
RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
                "<" / ">" / "=" / %x22
DIGIT = %x30-39                 ; digits 0 through 9
ALPHA = %x41-5A / %x61-7A       ; A-Z, a-z

A path name is also a string with syntactic restrictions imposed upon
it.  The following reasoning may be used to determine ABNF production defining it is copied from Annex B.

PathName = NAME *(["/"] ["*"] ["@"] (ALPHA / DIGIT)) ["*"]
NAME = ALPHA *63(ALPHA / DIGIT / "_" )

Internet draft              MEGACO Protocol           September 21, 1999

the value of this delay on residential gateways.

Media Gateway Controllers are typically dimensioned to handle the peak
hour traffic load, during which, in average, 10% of the lines will be
busy, placing calls whose average duration is typically 3 minutes.  The
processing of a call typically involves 5 to 6 Media Gateway Controller
transactions between each Media Gateway and the Media Gateway Con-
troller.  This simple calculation shows that the Media Gateway Con-
troller is expected to handle 5 to 6 transactions for each Termination,
every 30 minutes on average, or, to put it otherwise, about one transac-
tion per Termination every 5 to 6 minutes on average.  This suggests
that a reasonable value             January 27, 2000

ANNEX B TEXT ENCODING OF THE PROTOCOL (NORMATIVE)

B.1.  Coding of MWD for a residential gateway would be 10 to
12 minutes. wildcards

In the absence of explicit configuration, residential gate-
ways should adopt a value of 600 seconds for MWD.

The same reasoning suggests that the value of MWD should be much shorter
for trunking gateways or for business gateways, because they handle a
large number text encoding of Terminations, and also because the usage rate protocol, while TerminationIDs are arbitrary,
by judicious choice of these
Terminations is much higher than 10% during the peak busy hour, a typi-
cal value being 60%.  These Terminations, during names, the peak hour, are this
expected to contribute about one transaction per minute to wildcard character, "*" may be made
more useful.  When the Media
Gateway Controller load. A reasonable algorithm wildcard character is to make encountered, it will
"match" all TerminationIDs having the value same previous and following char-
acters (if appropriate).  For example, if there were TerminationIDs of
MWD per "trunk" Termination six times shorter than the MWD per residen-
tial gateway,
R13/3/1, R13/3/2 and also inversely proportional to R13/3/3, the number TerminationID R13/3/* would match all
of Termina-
tions that them.  There are being restarted. for example MWD should some circumstances where ALL Terminations must be set to 2.5
seconds for a gateway that handles a T1 line, or
referred to.  The TerminationID "*" suffices, and is referred to 60 milliseconds for
a gateway that handles a T3 line.

20.  TRANSPORT USING TCP

MECACO/Recommendation H.248 messages as ALL.
The CHOOSE TerminationID "$" may be transmitted over TCP.  When
no port is specified by the other side (see section 7.2.8), the commands
should be sent used to signal to the default MG that it has
to create an ephemeral Termination or select an idle physical Termina-
tion.

B.2.  ABNF specification

The protocol syntax is presented in ABNF according to RFC2234.  The pro-
tocol is not case sensitive.  Identifiers are not case sensitive.

megacoMessage        = LWSP [authenticationHeader SEP ] message

authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON
                       SequenceNum COLON AuthData

SecurityParmIndex    = "0x" 8(HEXDIG)
SequenceNum          = "0x" 8(HEXDIG)
AuthData             = "0x" 32*64(HEXDIG)

message            = MegacopToken SLASH Version SEP mId SEP
messageBody

messageBody          = ( errorDescriptor / transactionList )

transactionList      = 1*( transactionRequest / transactionReply /
                       transactionPending)

transactionPending   = PendingToken EQUAL TransactionID LBRKT RBRKT

transactionRequest   = TransToken EQUAL TransactionID LBRKT
                       actionRequest *(COMMA actionRequest) RBRKT

actionRequest        = CtxToken EQUAL ContextID LBRKT ((
                       contextRequest [COMMA  commandRequestList])
                       / commandRequestList) RBRKT

Internet draft              MEGACO port, ????. MECACO/Recommendation
H.248 messages are the unit of transfer, while TCP is a stream oriented
protocol.  TPKT, according to RFC1006 SHALL be used with
MECACO/Recommendation H.248.

In a transaction-oriented protocol like MEGACO/H.248, there are still
ways for transaction requests or responses to be lost.  As such, it is
recommended that entities using TCP transport implement application
level timers for each request Protocol             January 27, 2000

contextRequest     = ((contextAudit [COMMA contextProperties])
                           / contextProperties)

contextProperties    = contextProperty *(COMMA contextProperty)

; at-most-once
contextProperty      = (topologyDescriptor / priority /
EmergencyToken)

contextAudit       = ContextAuditToken LBRKT
                       contextAuditProperties *(COMMA
                       contextAuditProperties) RBRKT

; at-most-once
contextAuditProperties = ( TopologyToken / EmergencyToken /
                           PriorityToken )

commandRequestList=["O-"] commandRequest *(COMMA ["O-"]commandRequest)

commandRequest       = ( ammRequest / subtractRequest / auditRequest /
                        notifyRequest / serviceChangeRequest)

transactionReply     = ReplyToken EQUAL TransactionID LBRKT
                       ( errorDescriptor / actionReplyList ) RBRKT

actionReplyList      = actionReply *(COMMA actionReply )

actionReply          = CtxToken EQUAL ContextID LBRKT
                       ( errorDescriptor / commandReply ) RBRKT

commandReply       = (( contextProperties [COMMA commandReplyList] ) /
                        commandReplyList )

commandReplyList     = commandReplys *(COMMA commandReplys )

commandReplys        = (serviceChangeReply / auditReply / ammsReply /
                        notifyReply )

;Add Move and each response, similar to those speci-
fied for application level framing over UDP.

20.1.  Providing Modify have the At-Most-Once functionality

Messages, being carried over TCP, are not subject to transport losses,
but loss of a transaction same request or its reply may none-the-less be parameters
ammRequest           = (AddToken / MoveToken / ModifyToken ) EQUAL
                       TerminationID [LBRKT ammParameter *(COMMA
                       ammParameter) RBRKT]

;at-most-once
ammParameter         = (mediaDescriptor / modemDescriptor /
                        muxDescriptor / eventsDescriptor /
                        signalsDescriptor / digitMapDescriptor /

Internet draft              MEGACO Protocol             January 27, 2000

                        eventBufferDescriptor / auditDescriptor)

ammsReply            = (AddToken / MoveToken / ModifyToken /
                        SubtractToken ) EQUAL TerminationID [ LBRKT
                        terminationAudit RBRKT ]

subtractRequest      =  ["W-"] SubtractToken EQUAL TerminationID
                        [ LBRKT auditDescriptor RBRKT]

auditRequest         = ["W-"] (AuditValueToken / AuditCapToken ) EQUAL
                        TerminationID [ LBRKT auditDescriptor RBRKT ]

auditReply           = (AuditValueToken / AuditCapToken )
                       ( contextTerminationAudit  / auditOther)

auditOther           = EQUAL TerminationID LBRKT
                       terminationAudit RBRKT

terminationAudit  = auditReturnParameter *(COMMA auditReturnParameter)

contextTerminationAudit = EQUAL CtxToken ( terminationIDList /
                       LBRKT errorDescriptor RBRKT )
;at-most-once except errorDescriptor
auditReturnParameter = (mediaDescriptor / modemDescriptor /
                        muxDescriptor / eventsDescriptor /
                        signalsDescriptor / digitMapDescriptor /
                    observedEventsDescriptor / eventBufferDescriptor /
                        statisticsDescriptor / packagesDescriptor /
                         errorDescriptor )

auditDescriptor      = AuditToken LBRKT [ auditItem
                       *(COMMA auditItem) ] RBRKT

notifyRequest        = NotifyToken EQUAL TerminationID
                       LBRKT ( observedEventsDescriptor /
                             errorDescriptor ) RBRKT

notifyReply          = NotifyToken EQUAL TerminationID
                       [ LBRKT errorDescriptor RBRKT ]

serviceChangeRequest = ServiceChangeToken EQUAL TerminationID
                       LBRKT serviceChangeDescriptor RBRKT

serviceChangeReply   = ServiceChangeToken EQUAL TerminationID
                       [LBRKT (errorDescriptor /
                       serviceChangeReplyDescriptor) RBRKT]

errorDescriptor   = ErrorToken EQUAL ErrorCode

Internet draft              MEGACO Protocol           September 21, 1999

noted in real implementations. In the absence of a timely response, com-
mands are repeated. Most commands are not idempotent.  The state of the
MG would become unpredictable if, for example, Add commands were exe-
cuted several times.

To guard against such losses,             January 27, 2000

                    LBRKT [quotedString] RBRKT

ErrorCode            = 1*3(DIGIT) ; could be extended

TransactionID        = UINT32

mId                  = (( domainAddress / domainName )
                       [":" portNumber]) / mtpAddress / deviceName

; ABNF allows two or more consecutive "." although it is recommended that entities follow the
procedures meaningless
; in Section E.1

20.2.  Transaction identifiers and three way handshake

For the same reasons, it is possible that transaction replies may be
lost even with a reliable delivery protocol such as TCP.  It is recom-
mended that entities follow the procedures in Section E.2

20.3.  Computing retransmission timers

With reliable delivery, domain name.
domainName           = "<" (ALPHA / DIGIT) *63(ALPHA / DIGIT / "-" /
                       ".") ">"
deviceName           = pathNAME

ContextID            = (UINT32 / "*" / "-" / "$")

domainAddress        = "[" (IPv4address / IPv6address) "]"
;RFC2373 contains the incidence of loss definition of a transaction request
or reply IP6Addresses.
IPv6address          = hexpart [ ":" IPv4address ]
IPv4address          = V4hex DOT V4hex DOT V4hex DOT V4hex
V4hex                = 1*3(DIGIT) ; "0".."225"
; this production, while occurring in RFC2373, is expected to be very low.  Therefore, only simple timer
mechanisms are required. Exponential back-off algorithms should not be
necessary, although they could be employed where, as in an MGC, the code
to do so referenced
; IPv6prefix           = hexpart SLASH 1*2DIGIT
hexpart             = hexseq "::" [ hexseq ] / "::" [ hexseq ] /
hexseq
hexseq               = hex4 *( ":" hex4)
hex4                 = 1*4HEXDIG

portNumber           = UINT16

; An mtp address is already required, since MGCs must implement ALF/UDP as well
as TCP.

20.4.  Provisional responses

As with UDP, executing some transactions may require a long time. Enti-
ties that can predict that a transaction will require a five octets long execution
time may send a provisional response, "Transaction Pending".  They
should send this response if they receive a repetition
mtpAddress           = MTPToken LBRKT octetString RBRKT

terminationIDList    = LBRKT TerminationID *(COMMA TerminationID)
RBRKT

; Total length of a transaction
that is still being executed.

Entities that receive a Transaction Pending shall switch to a longer
repetition timer for that transaction.

Entities shall retain Transactions pathNAME must not exceed 64 chars.
pathNAME          = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" )
                    ["@" pathDomainName ]

; ABNF allows two or more consecutive "." although it is meaningless
; in a path domain name.
pathDomainName       = (ALPHA / DIGIT / "*" )
                       *63(ALPHA / DIGIT / "-" / "*" / ".")

TerminationID        = "ROOT" / pathNAME / "$" / "*"

Internet draft              MEGACO Protocol             January 27, 2000

mediaDescriptor  = MediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT

; at-most-once per item
; and replies until they are confirmed.
The basic procedure either streamParm or streamDescriptor but not both
mediaParm            = (streamParm / streamDescriptor /
                        terminationStateDescriptor)

; at-most-once
streamParm           = ( localDescriptor / remoteDescriptor /
                        localControlDescriptor )

streamDescriptor     = StreamToken EQUAL StreamID LBRKT streamParm
                       *(COMMA streamParm) RBRKT

localControlDescriptor = LocalControlToken LBRKT localParm
                         *(COMMA localParm) RBRKT

; at-most-once per item
localParm            = ( streamMode / propertyParm / reservedMode)

reservedMode       = ReservedToken EQUAL ( "ON" / "OFF" )

streamMode           = ModeToken EQUAL streamModes

streamModes         = (SendonlyToken / RecvonlyToken / SendrecvToken /
                       InactiveToken / LoopbackToken / DeleteToken )

propertyParm         = pkgdName parmValue
parmValue            = (EQUAL alternativeValue/ INEQUAL VALUE)
alternativeValue     = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT  /
                       LSBRKT VALUE DOT DOT VALUE RSBRKT )

INEQUAL              = LWSP (">" / "<" / "#" ) LWSP
LSBRKT               = LWSP "[" LWSP
RSBRKT               = LWSP "]" LWSP

localDescriptor      = LocalToken LBRKT octetString RBRKT

remoteDescriptor     = RemoteToken LBRKT octetString RBRKT

eventBufferDescriptor= EventBufferToken LBRKT observedEvent
                       *( COMMA observedEvent ) RBRKT

eventBufferFlag      = BufferToken EQUAL ("ON" / "OFF" )

terminationStateDescriptor = TerminationStateToken LBRKT
            terminationStateParm *( COMMA terminationStateParm ) RBRKT

Internet draft              MEGACO Protocol             January 27, 2000

; at-most-once per item
terminationStateParm=(propertyParm / serviceStates / eventBufferFlag )

serviceStates        = ServiceStatesToken EQUAL ( TestToken /
                       OutOfSvcToken / InSvcToken )

muxDescriptor        = MuxToken EQUAL MuxType  terminationIDList

MuxType              = ( H221Token / H223Token / H226Token / V75Token
                        extensionParameter )

StreamID             = UINT16
pkgdName             =  (PackageName / "*")  SLASH  (ItemID / "*" )
PackageName          = NAME
ItemID               = NAME

eventsDescriptor     = EventsToken EQUAL RequestID LBRKT
                       requestedEvent *( COMMA requestedEvent ) RBRKT

requestedEvent       = pkgdName [ LBRKT eventParameter
                       *( COMMA eventParameter ) RBRKT ]

; at-most-once each of section E.4 should be followed, but simple timer
values should be sufficient.

20.5.  Ordering embedOrKeepActive , eventDM or eventStream
eventParameter       = ( embedOrKeepActive / eventDM / eventStream
                        / eventOther )
embedOrKeepActive    = eventEmbedded / KeepActiveToken

eventEmbedded = EmbedToken LBRKT embedFirst [COMMA embedFirst ] RBRKT
; at-most-once of commands

TCP provided ordered delivery each
embedFirst     = ( signalsDescriptor / secondEventEmbeddedDescriptor )

secondEventEmbeddedDescriptor= EventsToken EQUAL RequestID LBRKT
              secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT

secondRequestedEvent = pkgdName [ LBRKT secondEventParameter
                       *( COMMA secondEventParameter ) RBRKT ]

; at-most-once each of transactions.  No special procedures
are required.  It should be noted that ALF/UDP allows sending entity to
modify its behavior under congestion, embedOrKeepActive , eventDM or eventStream
secondEventParameter = ( SecondEmbedOrKeepActive / eventDM /
                         eventStream / eventOther )

secondEmbedOrKeepActive = secondEventEmbedded / KeepActiveToken

secondEventEmbedded  = EmbedToken LBRKT signalsDescriptor RBRKT

eventStream          = StreamToken EQUAL StreamID

eventOther           = eventParameterName parmValue

Internet draft              MEGACO Protocol             January 27, 2000

eventParameterName   = NAME

eventDM              = DigitMapToken ((EQUAL digitMapName ) /
                       (LBRKT digitMapValue RBRKT ))

signalsDescriptor    = SignalsToken LBRKT [ signalParm
                       *(COMMA signalParm)] RBRKT

signalParm           = signalList / signalRequest

signalRequest        = signalName [ LBRKT sigParameter
                       *(COMMA sigParameter) RBRKT ]

signalList           = SignalListToken EQUAL signalListId LBRKT
                       signalListParm *(COMMA signalListParm) RBRKT

signalListId         = UINT16

;exactly once signalType, at most once duration and in particular, could reorder
transactions when congestion is encountered.  TCP could not achieve the
same results. every signal
;parameter
signalListParm       = signalRequest

signalName           = pkgdName
;at-most-once sigStream, at-most-once sigSignalType,
;at-most-once sigDuration, every signalParameterName at most once
sigParameter       = sigStream / sigSignalType / sigDuration /
sigOther
                           / notifyCompletion
sigStream            = StreamToken EQUAL StreamID
sigOther             = sigParameterName parmValue
sigParameterName     = NAME
sigSignalType        = SignalTypeToken EQUAL signalType
signalType           = (OnOffToken / TimeOutToken / BriefToken)
sigDuration          = DurationToken EQUAL UINT16
notifyCompletion     = NotifyCompletionToken EQUAL RequestID

observedEventsDescriptor = ObservedEventsToken EQUAL RequestID
                   LBRKT observedEvent *(COMMA observedEvent) RBRKT

;time per event, because it might be buffered
observedEvent        = [ TimeStamp LWSP COLON] LWSP
                       pkgdName [ LBRKT observedEventParameter
                       *(COMMA observedEventParameter) RBRKT ]

;at-most-once eventStream, every eventParameterName at most once
observedEventParameter = eventStream / eventOther

RequestID            = UINT32

Internet draft              MEGACO Protocol             January 27, 2000

modemDescriptor      = ModemToken (( EQUAL modemType) /
                       (LSBRKT modemType *(COMMA modemType) RSBRKT))
                       [ LBRKT NAME parmValue
                      *(COMMA NAME parmValue) RBRKT ]

; at-most-once
modemType            = (V32bisToken / V22bisToken / V18Token /
                        V22Token / V32Token / V34Token / V90Token /
                       V91Token / SynchISDNToken / extensionParameter)

digitMapDescriptor   = DigitMapToken EQUAL digitMapName
                       ( LBRKT digitMapValue RBRKT )
digitMapName         = NAME
digitMapValue        = ["T" COLON Timer COMMA] ["S" COLON Timer COMMA]
                       ["L" COLON Timer COMMA] digitMap
Timer                = 1*2DIGIT
digitMap = (digitString / LWSP "(" LWSP digitStringList LWSP ")" LWSP)
digitStringList      = digitString *( LWSP "|" LWSP digitString )
digitString          = 1*(digitStringElement)
digitStringElement   = digitPosition [DOT]
digitPosition        = digitMapLetter / digitMapRange
digitMapRange        = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
digitLetter          = *((DIGIT "-" DIGIT ) / digitMapLetter)
digitMapLetter       = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" /
                       MFSig / "S" / "L"

MFSig                = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3"

;at-most-once
auditItem            = ( MuxToken / ModemToken / MediaToken /
                        SignalsToken / EventBufferToken /
                        DigitMapToken / StatsToken / EventsToken /
                        ObservedEventsToken / PackagesToken )

serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
                         *(COMMA serviceChangeParm) RBRKT

serviceChangeParm    = (serviceChangeMethod / serviceChangeReason /
                       serviceChangeDelay / serviceChangeAddress /
                       serviceChangeProfile / extension / TimeStamp /
                       serviceChangeMgcId / serviceChangeVersion )

serviceChangeReplyDescriptor = ServicesToken LBRKT
                      servChgReplyParm *(COMMA servChgReplyParm) RBRKT

;at-most-once. Version is REQUIRED on first ServiceChange response
servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
                       serviceChangeProfile / serviceChangeVersion )

Internet draft              MEGACO Protocol           September 21, 1999

20.6.  Fighting the restart avalanche

The procedures of section E.6 shall be followed when using TCP as the
transport mechanism.

21.  ANNEX G EXAMPLE CALL FLOWS

{Editor's Notes: - Review these use cases for consistency with the
changes to the main text

*    SDP  in the Local and Remote descriptors needs to be verified

*    Package names, and property, event and signal names within packages
     are of course just examples - when a Megaco packages I-D comes out
     with proposed packages, these would be used }

The examples in this section use SDP for encoding of the Local and
Remote stream descriptors. SDP             January 27, 2000

serviceChangeMethod  = MethodToken EQUAL (FailoverToken /
                       ForcedToken / GracefulToken / RestartToken /
                       DisconnectedToken / HandOffToken /
                       extensionParameter)

serviceChangeReason  = ReasonToken  EQUAL VALUE
serviceChangeDelay   = DelayToken   EQUAL UINT32
serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
serviceChangeMgcId   = MgcIdToken   EQUAL mId
serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
serviceChangeVersion = VersionToken EQUAL Version
extension            = extensionParameter parmValue

packagesDescriptor   = PackagesToken LBRKT packagesItem
                       *(COMMA packagesItem) RBRKT

Version              = 1*2(DIGIT)
packagesItem         = NAME "-" UINT16

TimeStamp            = Date "T" Time ; per ISO 8601:1988
; Date = yyyymmdd
Date                 = 8(DIGIT)
; Time = hhmmssss
Time                 = 8(DIGIT)
statisticsDescriptor = StatsToken LBRKT statisticsParameter
                      *(COMMA statisticsParameter ) RBRKT

;at-most-once per item
statisticsParameter  = pkgdName EQUAL VALUE

topologyDescriptor   = TopologyToken LBRKT terminationA COMMA
                       terminationB COMMA topologyDirection RBRKT
terminationA         = TerminationID
terminationB         = TerminationID
topologyDirection    = BothwayToken / IsolateToken / OnewayToken

priority             = PriorityToken EQUAL UINT16

extensionParameter   = "X"  ("-" / "+") 1*6(ALPHA / DIGIT)

; octetString is used to describe SDP defined in RFC 2327. Audio profiles
used are those defined in RFC 1890, and others registered with IANA. For
example, G.711 A-law is called PCMA RFC2327.
; Caution should be taken if CRLF in the SDP, and is assigned profile
0. G.723 is profile 4, and H263 RFC2327 is profile 34. See also
http://www.isi.edu/in-notes/iana/assignments/rtp-parameters

21.1.  Residential Gateway to Residential Gateway Call

This example scenario illustrates the used.
; To be safe, use of the elements of the proto-
col to set up a Residential Gateway to Residential Gateway call over an
IP-based network.  For simplicity, this example will assume that both
Residential Gateways involved in the call are controlled by the same
Media Gateway Controller.

21.1.1.  Programming Residential GW Analog Line Terminations for Idle
Behavior

The following illustrates the API invocations from the Media Gateway
Controller and Media Gateways to get the Terminations EOL in this scenario
programmed for idle behavior.  Both the originating and terminating
Media Gateways have idle Analog Line Terminations programmed to look for
call initiation events (i.e.-offhook) by using the Modify Command with
the appropriate parameters.  The null Context is used to indicate that
the Terminations are not yet involved ABNF.
; Whenever "}" appears in a Context.

1.   An MG registers with an MGC using the ServiceChange command:

     MEGACO/1.0 [124.124.124.222]:55555
     Transaction SDP, it is escaped by "
octetString          = *(nonEscapeChar)
nonEscapeChar        = ( "" / %x01-7C / %x7E-FF )
quotedString         = DQUOTE 1*64(SafeChar / RestChar/ WSP) DQUOTE

Internet draft              MEGACO Protocol             January 27, 2000

UINT16               = 1*5(DIGIT)  ; %x0-FFFF
UINT32               = 1*10(DIGIT) ; %x0-FFFFFFFF

NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )
VALUE                = quotedString / 1*64(SafeChar)
SafeChar             = DIGIT / ALPHA / "+" / "-" / "&" /
                       "!" / "_" / "/" / "'" / "?" / "@" /
                       "^" / "`" / "~" / "*" / "$" / "
                       "(" / ")" / "%" / "|" / "."

EQUAL                = 9998 {
         Context LWSP %x3D LWSP ; "="
COLON                = %x3A           ; ":"
LBRKT                = LWSP %x7B LWSP ; "{"
RBRKT                = LWSP %x7D LWSP ; "}"
COMMA                = LWSP %x2C LWSP ; ","
DOT                  = %x2E           ; "."
SLASH                = %x2F           ; "/"
ALPHA                = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT                = %x30-39         ; 0-9
DQUOTE               = %x22            ; " (Double Quote)
HEXDIG               = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )
SP                   = %x20        ; space
HTAB                 = %x09        ; horizontal tab
CR                   = %x0D        ; Carriage return
LF                   = %x0A        ; linefeed
LWSP                 = *( WSP / COMMENT / EOL )
EOL                  = (CR [LF] / LF )
WSP                  = SP / HTAB ; white space
SEP                  = ( WSP / EOL / COMMENT) LWSP
COMMENT              = ";" *(SafeChar/ RestChar / WSP / %x22) EOL
RestChar             = ";" / "[" / "]" / "{" / "}" / ":" / "," / "#" /
                       "<" / ">" / "="

AddToken                   = ("Add"                   / "A")
AuditToken                 = ("Audit"                 / "AT")
AuditCapToken              = ("AuditCapability"       / "AC")
AuditValueToken            = ("AuditValue"            / "AV")
AuthToken                  = ("Authentication"        / "AU")
BothwayToken               = ("Bothway"               / "BW")
BriefToken                 = ("Brief"                 / "BR")
BufferToken                = ("Buffer"                / "BF")
CtxToken                   = ("Context"               / "C")
ContextAuditToken          = ("ContextAudit"          / "CA")
DigitMapToken              = ("DigitMap"              / "DM")
DiscardToken               = - {
             ServiceChange ("Discard"               / "DS")
DisconnectedToken          = ROOT {Services { ("Disconnected"          / "DC")
DelayToken                 = ("Delay"                 / "DL")

Internet draft              MEGACO Protocol           September 21, 1999

                 Method=Restart, Version=1.0, Port=55555, Profile=ResGW}
             }
         }
     }

2.   The MGC sends a reply:

     MEGACO/1.0 [124.124.124.121]:55566
     Reply             January 27, 2000

DeleteToken                = 9998 {
        Context ("Delete"                / "DE")
DurationToken              = - {ServiceChange ("Duration"              / "DR")
EmbedToken                 = ROOT }
     }

3.   The MGC programs a Termination in the NULL context. The termina-
     tionId is A4444, the streamId is 1111, the requestId in the Events
     descriptor is 2222. The Megaco mId is the identifier of the sender
     of this message, in this case, it is the IP address and port
     [124.124.124.121]:55566. Process is the default, so it is not
     necessary to have it in BufferedEventHandling.

     MEGACO/1.0 [124.124.124.121]:55566
     Transaction ("Embed"                 / "EB")
EmergencyToken             = 9999 {
         Context ("Emergency"             / "EM")
ErrorToken                 = - {
             Modify ("Error"                 / "ER")
EventBufferToken           = A4444 {
                 Media {
                     TerminationState {
                         BufferedEventHandling{Step,Process}
                      },
                      Stream ("EventBuffer"           / "EB")
EventsToken                = 1111 {
                          LocalControl {
                              Mode ("Events"                / "E")
FailoverToken              = SendReceive,
                              Package1/GainControl=2,  ; in dB,
                              Package1/Encryption=xxx,
                              Package1/EchoCancellation=G165,
                              Package1/VoiceActDet=yes
                          },
                          Local ("Failover"              / "FL")
ForcedToken                = SDP {c=LOCAL
                                       m=audio 0 LOCAL 0
                                       a=sendrecv
                                       a=ptime:10
                          } ; SDP profile 0 is G.711mu-law sampled
                              at 8kHz
                     }
                 },
                 Events ("Forced"                / "FO")
GracefulToken              = ("Graceful"              / "GR")
H221Token                  = ("H221" )
H223Token                  = ("H223" )
H226Token                  = ("H226" )
HandOffToken               = ("HandOff"               / "HO")
InactiveToken              = ("Inactive"              / "IN")
IsolateToken               = ("Isolate"               / "IS")
InSvcToken                 = ("InService"             / "IV")
KeepActiveToken            = ("KeepActive"            / "KA")
LocalToken                 = ("Local"                 / "L")
LocalControlToken          = ("LocalControl"          / "O")
LoopbackToken              = ("Loopback"              / "LB")
MediaToken                 = ("Media"                 / "M")
MegacopToken               = ("MEGACO"                / "!")
MethodToken                = ("Method"                / "MT")
MgcIdToken                 = ("MgcIdToTry"            / "MG")
ModeToken                  = ("Mode"                  / "MO")
ModifyToken                = ("Modify"                / "MF")
ModemToken                 = ("Modem"                 / "MD")
MoveToken                  = ("Move"                  / "MV")
MTPToken                   = 2222 {Package1/offhook}
             }
         }

Internet draft              MEGACO Protocol           September 21, 1999

     }

The dialplan script could have been loaded into the MG previously.  Its
function would be to wait for the OffHook, turn on dialtone and start
collecting DTMF digits. However in this example, we use the digit map,
which is put into place after the offhook is detected (step 5 below).

Note that the embedded EventsDescriptor could have been used to combine
steps 1 & 2 with steps 6 & 7, eliminating steps 4 & 5.

4.    The MG1 accepts the Modify with this reply:

     MEGACO/1.0 [124.124.124.222]:55555
     Reply ("MTP")
MuxToken                   = 9999 {
        Context ("Mux"                   / "MX")
NotifyToken                = - {Modify}
     }

5.   A similar exchange happens between MG2 and the MGC, resulting in an
     idle Termination called A5555.

21.1.2.  Collecting Originator Digits and Initiating Termination

The following builds upon the previously shown conditions.  It illus-
trates the API invocations from the Media Gateway Controller and ori-
ginating Media Gateway (MG1) to get the originating Termination (TID1)
through the stages of digit collection required to initiate a connection
to the terminating Media Gateway (MG2).

The following builds upon the previously shown conditions.  It illus-
trates the API invocations from the Media Gateway Controller and ori-
ginating Media Gateway (MG1) to get the originating Termination (TID1)
through the stages of digit collection required to initiate a connection
to the terminating Media Gateway (MG2).

6.   MG1 detects an offhook event from User 1 and reports it to the
     Media Gateway Controller via the Notify Command.

     MEGACO/1.0 [124.124.124.222]:55555
     Transaction ("Notify"                / "N")
NotifyCompletionToken      = 10000 {
        Context ("NotifyCompletion"      / "NC")
ObservedEventsToken        = - {
            Notify ("ObservedEvents"        / "OE")
OnewayToken                = ("Oneway"                / "OW")
OnOffToken                 = A4444 {ObservedEvents =2222 {
              19990729T22000000:Package1/offhook}}
        }
     }

     IP 7.  And the Notify is acknowledged

Internet draft              MEGACO Protocol           September 21, 1999

     MEGACO/1.0 [124.124.124.121]:55566
     Reply ("OnOff"                 / "OO")
OutOfSvcToken              = 10000 {
         Context ("OutOfService"          / "OS")
PackagesToken              = - {Notify}
     }

8.   The MGC Modifies the termination to look for digits now.

     MEGACO/1.0 [124.124.124.121]:55566
     Transaction ("Packages"              / "PG")
PendingToken               = 10001 {
         Context ("Pending"               / "PN")
PriorityToken              = - {
             Modify ("Priority"              / "PR")
ProfileToken               = A4444 {
                 Events ("Profile"               / "PF")
ReasonToken                = 2223 {
                     Package1/onhook {
                         Action { DigitMap=Dialplan0 }
                     }
                 },
                 DigitMap= Dialplan0{
     (0T|00T|[17]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)}
             }
         }
     }

9.   And the Modify is acknowledged

     MEGACO/1.0 [124.124.124.222]:55555
     Reply ("Reason"                / "RE")
RecvonlyToken              = 10001 {
         Context ("ReceiveOnly"           / "RC")
ReplyToken                 = - {Modify}
     }

10.  Next, digits are accumulated by MG1 as they are dialed by User 1.
     When an appropriate match is made of collected digits against the
     currently programmed Dialplan for A4444, another Notify is sent to
     the Media Gateway Controller.

     MEGACO/1.0 [124.124.124.222]:55555
     Transaction ("Reply"                 / "P")
RestartToken               = 10002 {
        Context ("Restart"               / "RS")
RemoteToken                = - {
            Notify ("Remote"                / "R")
ReservedToken              = A4444 {ObservedEvents =2223 {
              19990729T22010001:Package1/digits{digits=16135551212}}}
        }
     }

11.  And the Notify is acknowledged ("Reserved"                         / "RV")
SendonlyToken              = ("SendOnly"              / "SO")

Internet draft              MEGACO Protocol           September 21, 1999

     MEGACO/1.0 [124.124.124.121]:55566
     Reply             January 27, 2000

SendrecvToken              = 10002 {
         Context ("SendReceive"           / "SR")
ServicesToken              = - {Notify}
     }

12.  The controller then analyzes the digits and determines that a con-
     nection needs to be made from MG1 to MG2. Both the TDM termination
     A4444, and an RTP termination are added to a new context in MG1.
     Mode is ReceiveOnly since Remote descriptor values are not yet
     specified. Preferred codecs are in the MGC's preferred order of
     choice.

     MEGACO/1.0 [124.124.124.121]:55566
     Transaction ("Services"              / "SV")
ServiceStatesToken         = ("ServiceStates"         / "SI")
ServiceChangeToken         = 10003 {
         Context ("ServiceChange"         / "SC")
ServiceChangeAddressToken  = $ {
            Add ("ServiceChangeAddress"  / "AD")
SignalListToken            = A4444,
            Add ("SignalList"            / "SL")
SignalsToken               = $ {
                Media {
                  Stream ("Signals"               / "SG")
SignalTypeToken            = 1111 {
                       LocalControl {
                           Mode ("SignalType"            / "SY")
StatsToken                 = ReceiveOnly,
                           Package1/MaxJitterBuffer=40, ; in ms
                           Package1/PreferredPacketization=20, ; in ms
                           Package1/PreferredCodecs=[G723, PCMU],
                           Package1/Gain=0 ; in dB
                       },
                       Local ("Statistics"            / "SA")
StreamToken                = SDP {c=IN IP4 ANY
                                    m=audio ANY RTP/AVP ANY
                                    a=sendrecv
                       },
                       Remote ("Stream"                / "ST")
SubtractToken              = SDP {c=IN IP4 ANY
                                     m=audio ANY RTP/AVP ANY
                                     a=sendrecv
                       }
                   }
                },
                Events ("Subtract"              / "S")
SynchISDNToken             = 2224 {Package1/onhook}
            }
         }
     }

NOTE: The MGC states its preferred parameter values in the LocalControl. ("SynchISDN"             / "SN")
TerminationStateToken      = ("TerminationState"      / "TS")
TestToken                  = ("Test"                  / "TE")
TimeOutToken               = ("TimeOut"               / "TO")
TopologyToken              = ("Topology"              / "TP")
TransToken                 = ("Transaction"           / "T")
V18Token                   = ("V18")
V22Token                   = ("V22")
V22bisToken                = ("V22b")
V32Token                   = ("V32")
V32bisToken                = ("V32b")
V34Token                   = ("V34")
V76Token                   = ("V76")
V90Token                   = ("V90")
V91Token                   = ("V91")

ANNEX C TAGS FOR MEDIA STREAM PROPERTIES (NORMATIVE)

Parameters for Local descriptors and Remote could descriptors are specified as
tag-value pairs if binary encoding is used for the protocol.  This annex
contains the property names (PropertyID), the tags (Property Tag), type
of the property (Type) and the values (Value).Values presented in the
Value field when the field contains references shall be left empty regarded as
"information". The reference contains the normative values.  If a value
field does not contain a reference then the values in that field can be
considered as "normative".

Tags are given as hexadecimal numbers in this annex. When setting the Request from
value of a property, a MGC may underspecify the value according to MG. In
any case, one
of the MG fills mechanisms specified in section 7.1.1.

For type "enumeration" the value is represented by the value in brack-
ets, e.g., Send(0), Receive(1).

Internet draft              MEGACO Protocol             January 27, 2000

C.1.  General Media Attributes

________________________________________________________________________
|PropertyID   | Tag |  Type     |  Value                               |
|Media        |1001 |Enumeration|Audio(0), Video(1) ,Data(2),          |
|TransMode    |1002 |Enumeration|Send(0), Receive(1), Send&Receive(2)  |
|NumChan      |1003 |UINT       | 0-255                                |
|SamplingRate |1004 |UINT       | 0-2^32                               |
|Bitrate      |1005 |Integer    |(0..4294967295) Note-units of 100 bit |
|Acodec       |1006 |           |. Audio Codec Type                    |
|Samplepp     |1007 |UINT       |Maximum samples per packet:0-65535    |
|Silencesupp  |1008 |BOOLEAN    |Silence Suppression                   |
|Encrypttype  |1009 |Octet str  |Ref.: rec. H.245                      |
|Encryptkey   |100A |Octet str  |SIZE(0..65535) Encryption key         |
|Echocanc     |100B |Enumeration|Echo Canceller:Off(0),G.165(1),G168(2)|
|Gain         |100C |UINT       |Gain in the Local db: 0-65535                   |
|Jitterbuff   |100D |UINT       |Jitter buffer size in the Reply.

13.  MG1 acknowledges the new Termination and fills ms: 0-65535     |
|PropDelay    |100E |UINT       |  Propagation Delay: 0..65535         |
|RTPpayload   |100F |integer    |Payload type in the Local IP RTP Profile           |
|_____________|_____|___________|______________________________________|

C.2.  Mux Properties

_________________________________________________________________________
|PropertyID|  Tag       |  Type        |  Value                         |
|H.221     |  2001      |  Octet string|   H222LogicalChannelParameters |
|H223      |  2002      |  Octet string|   H223LogicalChannelParameters |
|V76       |  2003      |  Octet String|   V76LogicalChannelParameters  |
|H2250     |  2004      |  Octet String|   H2250LogicalChannelParameters|
|__________|____________|______________|________________________________|

C.3.  General bearer properties

 _____________________________________________________________________
| PropertyID|  Tag       |  Type       |  Value                      |
| Mediatx   |  3001      |  Enumeration|  Media Transport Type       |
| BIR       |  3002      |  4 OCTET    |  Value depends on transport |
| NSAP      |  3003      |  20 OCTET   |  Ref: ITU X.213 Annex A     |
|___________|____________|_____________|_____________________________|

C.4.  General ATM properties

Internet draft              MEGACO Protocol             January 27, 2000

   _________________________________________________________________
  | PropertyID|  Tag |  Type       |  Value                        |
  | AESA      |  4001|  20 OCTETS  |  ATM End System Address       |
  | VPVC      |  4002|  2x16b int  |  VPC-VCI                      |
  | SC        |  4003|  4 bits     |  Service Category             |
  | BCOB      |  4004|  5b integer |  Broadband Bearer Class       |
  | BBTC      |  4005|  octet      |  Broadband Transfer Capability|
  | ATC       |  4006|  Enumeration|  I.371 ATM Traffic Cap.       |
  | STC       |  4007|  2 bits     |  Susceptibility to clipping   |
  | UPCC      |  4008|  2 bits     |  User Plane Connection config |
  | PCR0      |  4009|  24b integer|  Peak Cell Rate CLP=0         |
  | SCR0      |  400A|  24b integer|  Sustainable Cell Rate CLP=0  |
  | MBS0      |  400B|  24b integer|  Maximum Burst Size CLP=0     |
  | PCR1      |  400C|  24b integer|  Peak Cell Rate CLP=0+1       |
  | SCR2      |  400D|  24b integer|  Sustain. Cell Rate CLP=0+1   |
  | MBS3      |  400E|  24b integer|  Maximum Burst Size CLP=0+1   |
  | BEI       |  400F|  Boolean    |  Best Effort Indicator        |
  | TI        |  4010|  Boolean    |  Tagging                      |
  | FD        |  4011|  Boolean    |  Frame Discard                |
  | FCDV      |  4012|  24b integer|  Forward P-P CDV              |
  | BCDV      |  4013|  24b integer|  Backward P-P CDV             |
  | FCLR0     |  4014|  8b integer |  Fwd Cell Loss Ratio CLP=0    |
  | BCLR0     |  4015|  8b integer |  Bkwd P-P CLR CLP=0           |
  | FCLR1     |  4016|  8b integer |  Fwd Cell Loss Ratio CLP=0+1  |
  | BCLR1     |  4017|  8b integer |  Bkwd P-P CLR CLP=0+1         |
  | FCDV      |  4018|  24b integer|  Fwd Cell Delay Variation     |
  | BCDV      |  4019|  24b integer|  Bkwd Cell Delay Variation    |
  | FACDV     |  401A|  24b integer|  Fwd Acceptable P-P-P CDV     |
  | BACDV     |  401B|  24b integer|  Bkwd Acceptable P-P CDV      |
  | FCCDV     |  401C|  24b integer|  Fwd Cumulative P-P CDV       |
  | BCCDV     |  401D|  24b integer|  Bkwd Cumulative P-P CDV      |
  | FCLR      |  401E|  8b integer |  Acceptable Fwd CLR           |
  | BCLR      |  401F|  8b integer |  Acceptable Bkwd CLR          |
  | EETD      |  4020|  16b integer|  End-to-end transit delay     |
  | Mediatx   |  4021|             |  AAL Type                     |
  | QosClass  |  4022|  Integer    |  0-4 Qos Class                |
  | AALtype   |  4023|  1 OCTET    |  AAL Type Reference           |
  |___________|______|_____________|_______________________________|

C.5.  Frame Relay

 ______________________________________________________________________
  PropertyID   Tag    Type               Value
  DLCI         5001   Unsigned Integer   Data link connection id
  CID          5002   Unsigned Integer   sub-channel id.
  SID          5003   Unsigned Integer   silence insertion descriptor
  Payload      5004   Unsigned Integer   Primary Payload Type

Internet draft              MEGACO Protocol           September 21, 1999             January 27, 2000

|___________|______|__________________|_______________________________|

C.6.  IP

 _____________________________________________________________________
| PropertyID|  Tag       |  Type      |  Value                       |
| IPv4      |  6001      |  32 BITS   |  Ipv4Address or Ipv6 address and |
| IPv6      |  6002      |  128 BITS  |  IPv6 Address                |
| Port      |  6002      |  0-65535   |  Port                        |
| TCP       |  6003      |  Boolean   |                              |
| UDP port. It also makes a choice for the codec based on
     the MGC preferences in LocalControl.

     MEGACO/1.0 [124.124.124.222]:55555
     Reply = 10003 {
        Context = 2000 {
           Add,
           Add= A4445{
              Media {
                  Stream = 1111 {
                      Local = SDP {v=0
                                   c=IN IP4 45.123.1.1
                                   m=audio 5555 RTP/AVP 0 4
                                   a=ptime:20
                      } ; RTP profile for G.723 is       |  6004      |  Boolean   |                              |
|___________|____________|____________|______________________________|

C.7.  ATM AAL2

_______________________________________________________________________________
|PropertyID|  Tag    |  Type         |  Value                                 |
|AESA      |  7001   |  20 OCTETS    |  AAL2 service endpoint address         |
|BIR       |  See C.3|  4
                  }
              }
           }
        }
     }

14.  The MGC will now associate A5555 with a new Context on MG2, and
     establish an RTP Stream (i.e, A5556 will be assigned) receiveOnly OCTETS     |  Served user generated reference       |
|ALC       |  7002   |  12 OCTETS    |  AAL2 link                             |
|SSCS      |  7003   |  8..14 OCTETS |  Service specific convergence sublayer |
|SUT       |  7004   |  1..254 octets|  Served user transport param           |
|TCI       |  7005   |  BOOLEAN      |  Test connection through                       |
|Timer_CU  |  7006   |  32b integer  |  Timer-CU                              |
|MaxCPSSDU |  7007   |  8b integer   |  Max. Common Part Sublayer SDU         |
|SCLP      |  7008   |  Boolean      |  Set Cell Local PriorityLP bit         |
|EETR      |  7009   |  Boolean      |  End to the originating user, End Timing Required            |
|__________|_________|_______________|________________________________________|

C.8.  ATM AAL1

______________________________________________________________________________
|PropertyID|  Tag          |  Type         |  Value                           |
|BIR       |  See Table C.3|  4 OCTETS     |GIT (Generic Identifier Transport)|
|AAL1ST    |  8001         |  1 OCTET      | AAL1 Subtype                     |
|CBRR      |  8002         |  1 OCTET      | CBR Rate                         |
|SCRI      |  8003         |  1 OCTET      | Src. Clock Freq. Recovery Method |
|ECM       |  8004         |  1 OCTET      | Error Correction Method          |
|SDTB      |  8005         |  16b integer  | Structured Data Transfer Blksize |
|PFCI      |  8006         |  8b integer   | Partially filled cells identifier|
|EETR      |  See Table C.7|  See Table C.7|                                  |
|__________|_______________|_______________|__________________________________|

Internet draft              MEGACO Protocol             January 27, 2000

C.9.  Bearer Capabilities

________________________________________________________________________
|PropertyID   |  Tag |  Type       |  Value                            |
|TMR          |  9001|  1 OCTET    |  Transmission Medium Requirement  |
|TMRSR        |  9002|  1 OCTET    |  Trans. Medium Requirement Subrate|
|Contcheck    |  0003|  BOOLEAN    |  Continuity Check                 |
|ITC          |  9004|  5 BITS     |  Information Transfer Capability  |
|TransMode    |  9005|  2 BITS     |  Transfer Mode                    |
|TransRate    |  9006|  5 BITS     |  Transfer Rate                    |
|MULT         |  9007|  7 BITS     |  Rate Multiplier                  |
|USI          |  9008|  5 BITS     |  User 1. The signal
     Package1/Ring put on A5555 sends ring back to MG1. The signal
     Package1/RingTone on the new termination (A5556) makes MG2's phone
     ring.

     MEGACO/1.0 [124.124.124.121]:55566
     Transaction = 50003 {
         Context = $ {
            Add = A5555 {
               Signals { Package1/Ring {variant=NorthAmerica}}
            },
            Add  = $ {
               Media {
                 Stream = 1212 {
                      LocalControl { Information Layer 1 Protocol|
|Syncasync    |  9009|  BOOLEAN    |  Synchronous-Asynchronous         |
|Userrate     |  900B|  5 BITS     |  User Rate Reference              |
|INTRATE      |  900C|  2 BITS     |  Intermediate Rate                |
|Nictx        |  900D|  BOOLEAN    |  Tx Network Independent Clock     |
|Nicrx        |  900E|  BOOLEAN    |  Rx Network independent clock     |
|Flowconttx   |  900F|  BOOLEAN    |  Tx Flow Control                  |
|Flowcontrx   |  9010|  BOOLEAN    |  Rx Flow control                  |
|Rateadapthdr |  9011|  BOOLEAN    |  Rate adapt header-no header      |
|Multiframe   |  9012|  BOOLEAN    |  Multiple frame estab.            |
|OPMODE       |  9013|  BOOLEAN    |  Mode = SendReceive,
                         Package1/MaxJitterBuffer=40, ; in ms
                         Package1/PreferredPacketization=20, ; in ms
                         Package1/PreferredCodecs=G723,
                         Package1/Gain=0  ; in dB
                      },
                      Local=SDP{c=IN IP4 ANY
                                m=audio ANY RTP/AVP ANY
                                a=sendrecv of operation                |
|Llidnegot    |  9014|  BOOLEAN    |  Logical link identifier neg.     |
|Assign       |  9015|  BOOLEAN    |  Assignor-assignee                |
|Inbandneg    |  9016|  BOOLEAN    |  In-band or out-band negotiation  |
|Stopbits     |  9017|  2 BITS     |  Number of stop bits              |
|Databits     |  9018|  2 BIT      |  Number of data bits              |
|Parity       |  9019|  3 BIT      |  Parity information               |
|Duplexmode   |  901A|  BOOLEAN    |  Mode duplex                      |
|Modem        |  901B|  6 BIT      |  Modem Type                       |
|layer2prot   |  901C|  5 BIT      |  User info layer 2 protocol       |
|layer3prot   |  901D|  5 BIT      |  User info layer 3 protocol       |
|addlayer3prot|  901E|  OCTET      |  Addl User Info L3 protocol       |
|DialledN     |  901F|  10 OCTETS  |  Dialled Number                   |
|DiallingN    |  9020|  10 OCTETS  |  Dialling Number                  |
|ECHOCI       |  9021|  Enumeration|  Echo Control Information         |
|NCI          |  9022|  1 OCTET    |  Nature of Connection Indicators  |
|_____________|______|_____________|___________________________________|

C.10.  AAL5 Properties

 ______________________________________________________________________
| PropertyID|  Tag    |  Type       |  Value                           |
| FMSDU     |  A001   |  32b integer|  Forward Maximum CPCS-SDU Size   |
| BMSDU     |  A002   |  2b integer |  Backwards Maximum CPCS-SDU Size |
| SSCS      |  See C.7|  See C.7    |  See table C.7                   |
| SC        |  See C.4|  See C.4    |  See table C.4                   |

Internet draft              MEGACO Protocol           September 21, 1999

                      },
                      Remote=SDP{c=IN IP4 45.123.1.1
                                 m=audio 5555 RTP/AVP 0 4
                                 a=sendrecv
                      } ; RTP profile for G.723 is 4
                  }
               },
               Signals { Package1/RingTone {variant=NorthAmerica}}
            }
        }
     }

15.  This is acknowledged.

     MEGACO/1.0 [124.124.124.222]:55555
     Reply = 50003 {
        Context = 5000 {
           Add,
           Add = A5556{
              Media {
                 Stream = 1212 {
                     Local =             January 27, 2000

|___________|_________|_____________|_________________________________|

C.11.  SDP {c=IN IP4 111.1.1.1
                                  m=audio 1111 RTP/AVP 0 4}
                 } ; RTP profile for G723 is 4
              }
            }
        }
     }

16.  The above IPAddr Equivalents

     ______________________________________________________________
    | PropertyID|  Tag |  Type  |  Value                          |
    | SDP_V     |  B001|  STRING|  Protocol Version               |
    | SDP_O     |  B002|  STRING|  Owner-creator and UDPport need to session ID   |
    | SDP_S     |  B003|  STRING|  Sesson name                    |
    | SDP_I     |  B004|  STRING|  Session identifier             |
    | SDP_U     |  B005|  STRING|  URI of descriptor              |
    | SDC_E     |  B006|  STRING|  email address                  |
    | SDP_P     |  B007|  STRING|  phone number                   |
    | SDP_C     |  B008|  STRING|  Connection information         |
    | SDP_B     |  B009|  STRING|  Bandwidth Information          |
    | SDP_Z     |  B00A|  STRING|  time zone adjustment           |
    | SDP_K     |  B00B|  STRING|  Encryption Key                 |
    | SDP_A     |  B00C|  STRING|  Zero or more session attributes|
    | SDP_T     |  B00D|  STRING|  Active Session Time            |
    | SDP_R     |  B00E|  STRING|  Zero or more repeat times      |
    |___________|______|________|_________________________________|

C.12.  H.245

________________________________________________________________________
|OLC   |  C001|  octet string|  H.245 OpenLogicalChannel structure.    |
|OLCack|  C002|  octet string|   H.245 OpenLogicalChannelAck structure.|
|OLCcnf|  C003|  octet string|   OpenLogicalChannelConfirm structure.  |
|OLCrej|  C004|  octet string|   OpenLogicalChannelReject structure.   |
|CLC   |  C005|  octet string|   CloseLogicalChannel structure.        |
|CLCack|  C006|  octet string|   CloseLogicalChannelAck structure.     |
|______|______|______________|_________________________________________|

ANNEX D TRANSPORT OVER IP (NORMATIVE)

D.1.  Transport over IP/UDP using Application Level Framing

Protocol messages defined in this document may be transmitted over UDP.
When no port is specified for by the other side (see section 7.2.8), the
commands should be given to MG1 now.

     From MGC sent to MG1:
     MEGACO/1.0 [124.124.124.121]:55566
     Transaction = 10004 {
        Context = 2000 {
           Modify = A4445 {
              Media {
                 Stream = 1111 {
                     Remote = SDP {c=IN IP4 111.1.1.1
                                   m=audio 1111 RTP/AVP 0 4}
                 }
              }
           }
        }
     }
     From MG1 the default port.

D.1.1.  Providing At-Most-Once Functionality

Messages, being carried over UDP, may be subject to MGC: losses. In the

Internet draft              MEGACO Protocol           September 21, 1999

     MEGACO/1.0 [124.124.124.222]:55555
     Reply = 10004 {
        Context =             January 27, 2000 {Modify}
     }

17.

absence of a timely response, commands are repeated. Most commands are
not idempotent.  The two gateways state of the MG would become unpredictable if, for
example, Add commands were executed several times.  The transmission
procedures shall thus provide an "At- Most-Once" functionality.

Peer protocol entities are now connected expected to keep in memory a list of the
responses that they sent to recent transactions and a list of the tran-
sactions that are currently outstanding. The transaction identifiers of
incoming messages are compared to the transaction identifiers of the
recent responses from the same entity. If a match is found, the entity
does not execute the transaction, but simply repeats the response. The
remaining messages will be compared to the list of current transactions.
If a match is found, indicating a duplicate transaction, the entity does
not execute the transaction, which is simply ignored.

The procedure uses a long timer value, noted LONG-TIMER in the follow-
ing.  The timer should be set larger than the maximum duration of a
transaction, which should take into account the maximum number of
repetitions, the maximum value of the repetition timer and User  1 hears the RingBack. maximum
propagation delay of a packet in the network.  A suggested value is 30
seconds.

The MG2 now waits until User2 picks up copy of the receiver and then responses may be destroyed either LONG-TIMER seconds
after the
     two-way call response is established.

             From MG2 issued, or when the entity receives a confirmation
that the response has been received, through the "Response Acknowledge-
ment parameter". For transactions that are acknowledged through this
parameter, the entity shall keep a copy of the transaction-id for LONG-
TIMER seconds after the response is issued, in order to MGC:

             MEGACO/1.0 [124.124.124.222]:55555 detect and
ignore duplicate copies of the transaction request that could be pro-
duced by the network.

D.1.2.  Transaction = 50004 {
                Context = 5000 {
                    Notify = A5555 {ObservedEvents =1234 {
                      19990729T22020002:Package1/offhook}}
                }
             }

             From MGC identifiers and three-way handshake

Transaction identifiers are 32 bit integer numbers.  A Media Gateway
Controller may decide to MG2:

             MEGACO/1.0 [124.124.124.121]:55566
             Reply = 50004 {
                 Context = - {Notify}
             }

             From MGC use a specific number space for each of the MGs
that they manage, or to MG2:

             MEGACO/1.0 [124.124.124.121]:55566
             Transaction = 50005 {
                Context = 5000 {
                   Modify = A5555 {
                      Events = 1235 {Package1/onhook},
                      Signals {Package1/Clear}
                   },
                   Modify = A5556 {
                      Signals {Package1/Clear}
                   }
                }
             }

             From MG2 use the same number space for all MGs that
belong to some arbitrary group.  MGCs may decide to share the load of
managing a large MG between several independent processes.  These
processes will share the same transaction number space.  There are mul-
tiple possible implementations of this sharing, such as having a cen-
tralized allocation of transaction identifiers, or pre-allocating non-
overlapping ranges of identifiers to MGC:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50005 {
              Context = 5000 {Modify, Modify}
             } different processes.  The implemen-
tations shall guarantee that unique transaction identifiers are allo-
cated to all transactions that originate from a logical MGC (identical
mId). MGs can simply detect duplicate transactions by looking at the
transaction identifier and mId only.

The Response Acknowledgement parameter can be found in any message. It

Internet draft              MEGACO Protocol           September 21, 1999

18.  Change mode on MG1 to SendReceive

             MEGACO/1.0 [124.124.124.121]:55566
             Transaction = 10005 {
                Context = 2000 {
                   Modify = A4445 {
                      Media {
                         Stream = 1111 {
                            LocalControl {
                               Mode=SendReceive
                            }
                         }
                      }
                   }
                }
             }

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 10005 {
                Context =             January 27, 2000 {Modify= A4445
                }
             }

19   The MGC decides

carries a set of "confirmed transaction-id ranges". Entities may choose
to Audit delete the RTP termination copies of the responses to transactions whose id is
included in "confirmed transaction-id ranges" received in the transac-
tion response messages. They should silently discard further commands
when the transaction-id falls within these ranges.

The "confirmed transaction-id ranges" values shall not be used if more
than LONG-TIMER seconds have elapsed since the MG issued its last
response to that MGC, or when a MG resumes operation.  In this situa-
tion, transactions should be accepted and processed, without any test on MG2.

             MEGACO/1.0 [124.124.124.121]:55566
the transaction-id.

Messages that carry the "Response Acknowledgement" parameter may be
transmitted in any order.  The entity shall retain the "confirmed
transaction-id ranges" received in for LONG- TIMER seconds.

The ASN.1 of Annex A is modified as follows.  The definition of Transac-
tion of Annex A is replaced by

Transaction = 50006 ::= CHOICE
{
                Context = - {AuditValue = A5556{
                   Audit{Media, DigitMap, Events, Signals }}
                }
        transactionRequest      TransactionRequest,
        transactionPending      TransactionPending,
        transactionReply                TransactionReply,
        transactionResponseAck  TransactionResponseAck
}

20.

The MGC replies.

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50006 {
                Context = - {
                   AuditValue {
                       Media {
                          TerminationState definition of TransactionResponseAck reads

TransactionResponseAck ::= SEQUENCE
{
                              BufferedEventHandling{Process}
                          },
                          Stream
        firstAck        TransactionId,
        lastAck TransactionId OPTIONAL
}

If only the firstAck is present in a response acknowledgement, only one
transaction is acknowledged.  If both firstAck and lastAck are present,
then the range of transactions from firstAck to lastAck is acknowledged.

The ABNF of Annex B is modified so that:

transactionList      = 1212 {
                              LocalControl {
                                 Mode 1*(transactionRequest / transactionReply /
                       transactionPending / transactionResponseAck)

transactionResponseAck = SendReceive,
                                 Package1/MaxJitterBuffer=40, ; in ms ResponseAckToken LBRKT transactionAck

Internet draft              MEGACO Protocol           September 21, 1999

                                 Package1/PreferredPacketization=20, ; in ms
                                 Package1/PreferredCodecs=G723,
                                 Package1/Gain=0  ; in dB
                              },
                              Local             January 27, 2000

                                        *(COMMA transactionAck) RBRKT
transactionAck = SDP {c=IN IP4 111.1.1.1
                                           m=audio 1111 RTP/AVP 0 4

                              },
                              Remote=SDP{c=IN IP4 45.123.1.1
                                         m=audio 5555 RTP/AVP 0 4
                                         a=sendrecv
                              } ; RTP profile transactionID / (transactionID "-" transactionID)
ResponseAckToken = "TransactionResponseAck" | "K"

D.1.3.  Computing retransmission timers

It is the responsibility of the requesting entity to provide suitable
time outs for G.723 all outstanding transactions, and to retry transactions
when time outs have been exceeded. Furthermore, when repeated transac-
tions fail to be acknowledged, it is 4
                          }
                       },
                       Signals {Package1/Clear},
                       Packages {Package1, RTPPkg},
                       Statistics { RTPPkg/PacketsSent=1200,
                                    RTPPkg/OctetsSent=62300,
                                    RTPPkg/PacketsReceived=700,
                                    RTPPkg/OctetsReceived=45100,
                                    RTPPkg/PacketsLost=6,
                                    RTPPkg/Jitter=20,
                                    RTPPkg/AverageLatency=40 }
                }
               }
             }

21.  When the MGC receives responsibility of the request-
ing entity to seek redundant services and/or clear existing or pending
connections.

The specification purposely avoids specifying any value for the
retransmission timers. These values are typically network dependent. The
retransmission timers should normally estimate the timer value by
measuring the time spent between the sending of a command and the return
of a response. One possibility is to use the algorithm implemented in
TCP-IP, which uses two variables:

*    The average acknowledgement delay, AAD, estimated through an
     exponentially smoothed average of the observed delays.

*    The average deviation, ADEV, estimated through an onhook signal from one exponentially
     smoothed average of the MGs, it
     brings down absolute value of the call. In this example, difference between
     the user at MG2 hangs up
     first.

             From MG2 to MGC:

             MEGACO/1.0 [124.124.124.222]:55555
             Transaction = 50007 {
                Context = 5000 {
                    Notify = A5555 {ObservedEvents =1235 {
                       19990729T24020002:Package1/onhook}
                    }
                }
             }

             From MGC to MG2:

             MEGACO/1.0 [124.124.124.121]:55566
             Reply = 50007 {
                 Context = - {Notify}

Internet draft              MEGACO Protocol           September 21, 1999

             }

22. observed delay and the current average.

The MGC now sends both MGs a Subtract retransmission timer, in TCP, is set to take down the call. Only sum of the subtracts to MG2 are shown here.

             From MGC to MG2:

             MEGACO/1.0 [124.124.124.121]:55566
             Transaction = 50008 {
                Context = 5000 {
                   Subtract = A5555 ,
                   Subtract = A5556
                }
             }

             From MG2 to MGC:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50008 {
                Context = 5000 {
                  Subtract {
                       Statistics { ; what are average delay
plus N times the stats for a TDM connection?
                          TDMPkg/OctetsSent=45123
                          }
                    },
                    Subtract {
                       Statistics {
                          RTPPkg/PacketsSent=1245,
                          RTPPkg/OctetsSent=62345,
                          RTPPkg/PacketsReceived=780,
                          RTPPkg/OctetsReceived=45123,
                          RTPPkg/PacketsLost=10,
                          RTPPkg/Jitter=27,
                          RTPPkg/AverageLatency=48
                       }
                    }
                }
             }

23. average deviation. The MGC now sets up both MG1 and MG2 to maximum value of the timer
should however be ready bounded for the protocol defined in this document, in
order to detect guarantee that no repeated packet would be received by the
gateways after LONG-TIMER seconds.  A suggested maximum value is 4
seconds.  After any retransmission, the entity should do the following:

*    It should double the estimated value of the average delay, AAD

*    It should compute a random value, uniformly distributed between 0.5
     AAD and AAD

*    It should set the next
     off-hook event. See step 1. Note that this could be retransmission timer to the default
     state sum of a termination in the null context, that random
     value and if this were the
     case, no message need be sent from N times the MGC to average deviation.

This procedure has two effects. Because it includes an exponentially
increasing component, it will automatically slow down the MG. Once stream of mes-
sages in case of congestion. Because it includes a termi-
     nation returns to the null context, random component, it goes back to
will break the default
     termination values for that termination. potential synchronization between notifications triggered
by the same external event.

Internet draft              MEGACO Protocol           September 21, 1999

21.2.  Multimedia Gateway Examples

Multimedia sessions using this protocol will use multimedia Terminations
and Contexts for example for H.320 ISDN connections and for IP based
multimedia connections.  The MGC determines the need for multimedia Con-
texts from             January 27, 2000

D.1.4.  Provisional responses

Executing some transactions may require a long time. Long execution
times may interact with the SCN timer based retransmission procedure. This
may result either in an inordinate number of retransmissions, or IP Side call signaling.  Once multimedia is
detected the MGC will create the Context and appropriate Terminations.

In general, in
timer values that become too long to be efficient. Entities that can
predict that a Termination transaction will associate all media require a long execution time may send a
provisional response, "Transaction Pending". They should send this
response if they receive a repetition of an individual user
and handles network jitter Streams sourced/sinked by a Termination are
identified by transaction that is still
being executed.

Entities that receive a StreamId to instruct the MG how Transaction Pending shall switch to connect them.  Media
from terminations with identical streamIDs are connected. a different
repetition timer for repeating requests.  The MGC root termination has a
property (ProvisionalResponseTimerValue), which can
instruct the MG be set to synchronize streams by setting Context properties.
One of the properties
requested maximum number of milliseconds between receipt of a Context is the mixing properties. In the fig-
ure below these are represented by the black dots in command
and transmission of the context.

The concept TransactionPending response.  Upon receipt of connecting streams makes for a straight forward implemen-
tation of functionality such as speech-to-text transmediation.  If
final response, an MG
supports this type immediate confirmation shall be sent, and normal
repetition timers shall be used thereafter.  Receipt of operation, a MGC can assign identical StreamIDs to a speech stream and Transaction
Pending after receipt of a text stream to indicate that incoming speech
should reply shall be transformed into text.

21.2.1.  H.320 Gateway ignored.

D.1.5.  Repeating Requests, Responses and Acknowledgements

The Context for a point-to-point multimedia call in an H.320-H.323 gate-
way contains two muxing Terminations.  It contains protocol is organized as a muxing Termination
that sources set of transactions, each of which is
composed request and sinks the H.221 frames on DS0s.  This Termination
references a number of DS0s, six in response, commonly referred to as an acknowledge-
ment.  The protocol messages, being carried over UDP, may be subject to
losses. In the example for a call with a total
bandwidth of 384 kbit/s.  Each absence of these DS0s a timely response, transactions are also terminations repeated.
Entities are expected to keep in
their own right. The mux/demux descriptor memory a list of the muxing Termination
describes how the audio, video and data streams are transported over the
six 64 kbit/s bearer channels.

The second muxing Termination sources and sinks responses that
they sent to recent transactions, i.e. a list of all the media flows on responses they
sent over the
packet network Side. Assuming that there are audio, video last LONG-TIMER seconds, and data
streams, the Termination contains a muxDescriptor with a list of the transactions
that are currently being executed.

The repetition mechanism is used to guard against three
bearer descriptors.  No multiplexing types of possi-
ble errors:

*    transmission errors, when for example a packet is involved in this muxing Termina-
tion: every media flow maps lost due to one stream noise
     on a line or congestion in a queue;

*    component failure, when for example an interface to a entity
     becomes unavailable;

*    entity failure, when for example an entire entity become unavail-
     able.

The entities should be able to derive from the network.

Internet draft              MEGACO Protocol           September 21, 1999

             +----------------------------------------------+
             |                   Context C1                 |
             |       +-------+              +-------+       |
             |       | H.323 |              | H.320 |       |
             | +-----+       |              |       +-----+ |
            ---| RTP |       |------O-------|       | DS0 |---
             | |Audio|       |              |       |     | |
             | +-----+       |              |       +-----+ |
             |       |       |              |       |       |
             | +-----+       |              |       +-----+ |
            ---| RTP |       |------O-------|       | DS0 |---
             | |Video|       |              |       |     | |
             | +-----+       |              |       +-----+ |
             |       |       |              |       |       |
             | +-----+       |              |       +-----+ |
            ---| RTP |       |------O-------|       | DS0 |---
             | |Data |       |              |       |     | |
             | +-----+       |              |       +-----+ |
             |       |       |              |       |       |
             |       +-------+              +-------+       |
             |                                              |
             +----------------------------------------------+

                    Figure 6 H.320 past history an estimate
of the packet loss rate due to transmission errors.  In a properly con-
figured system, this loss rate should be kept very low, typically less
than 1%.  If a Media Gateway Controller or a Media Gateway Context

The following has to repeat
a message more than a few times, it is very legitimate to assume that

Internet draft              MEGACO Protocol             January 27, 2000

something else than a transmission error is occurring.  For example,
given a call flow loss rate of 1%, the probability that five consecutive transmis-
sion attempts fail is 1 in 100 billion, an event that should occur less
than once every 10 days for a point-to-point H.320 to H.323 call
initiated from Media Gateway Controller that processes 1
000 transactions per second. (Indeed, the WAN Side. The call flow shows number of repetition that either is
considered excessive should be a function of the H.323
or H.320 Side can initiate opening (or closing) an audio or video chan-
nel through prevailing packet loss
rate.) We should note that the gateway.  In H.320, there "suspicion threshold", which we will call
"Max1", is normally lower than the "disconnection threshold", which
should be set to a larger value.

A classic retransmission algorithm would simply count the requirement number of suc-
cessive repetitions, and conclude that such
mode changes take at most 20 milliseconds. the association is broken after
retransmitting the packet an excessive number of times (typically
between 7 and 11 times.) In order to account for the call flow possibility of an
undetected or in-progress "failover", we see modify the classic algorithm so
that
messages if the Media Gateway receives a valid ServiceChange message
announcing a failover, it will start transmitting outstanding commands
to that new MGC.  Responses to commands are exchanged between MG and MGC still transmitted to the
source address of the command.

In order to automatically adapt to network load, this document specifies
exponentially increasing timers.  If the initial timer is set to inform 200
milliseconds, the MGC loss of a request
for a mode change from the H.320 Side. The MGC fifth retransmission will then send an OLC to
the H.323 terminal.

1.   MGC gets an incoming call with (Q.931) call type of data and sends be detected after
about 6 seconds.  This is probably an Add command acceptable waiting delay to MG, detect
a failover. The repetitions should continue after that delay not only in
order to create perhaps overcome a Context with one muxing termina-
     tion and one DS0 termination, indicating transient connectivity problem, but also in the parameters
order to allow some more time for the
     muxing termination execution of a failover - waiting
a total delay of 30 seconds is probably acceptable.

It is, however, important that Bonding will the maximum delay of retransmissions be used and
bounded.  Prior to any retransmission, it is checked that the multiplex
     type is H.221.

             MEGACO/1.0 [124.124.124.121]:55566
             Transaction = 9999 {
                 Context = $ {
                    Add = $ {
                        Mux = H221 {DS0_A},
                        Media {

Internet draft              MEGACO Protocol           September 21, 1999

                           Stream = 1111 {
                              LocalControl {
                                  Mode = SendReceive,
                                  PackageMux/Mux = yes
                              }
                           }
                        },
                        Events = 2222 {
                             Bonding/CallID {Action {NotifyAction}},
                             Bonding/TransferRate {Action {NotifyAction}}
                        }
                    }
                 }
             }

The MuxDescr contains time
elapsed since the mux type, and an ordered list sending of termina-
tionIds used in the call (here there initial datagram is only one). no greater than T-
MAX. If the termina-
tionIds are not yet added to the context, more than T-MAX time has elapsed, the MG takes care of adding
them. In the LocalControl, a muxing package parameter marks the stream
as being part of a muxing termination (necessary?).

At this stage in the session there is only an audio channel, using 56
kbit/s G.711 coder (corresponding to H.221 mode 0F).  A script is used
to monitor concludes that the line for Bonding MGC
has failed, and H.221 in-band H.221 framing.

[Editor's Note: it begins its recovery process. When the ABNF does not have MG establishes
a script descriptor - this would
need new control association, it can retransmit to be added if a script is needed for this case]

2. the new MGC.  The MG acknowledges value
T-MAX is related to the Context creation, informing LONG- TIMER value: the MGC of LONG-TIMER value is
obtained by adding to T-MAX the
     ContextID 2000 and TerminationID A4444 (for maximum propagation delay in the muxing termination)
     it assigned.

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 9999 {
                Context = 2000 {Add= A4444}
             }

3. net-
work.

D.2.  using TCP

Protocol messages as defined in this document may be transmitted over
TCP.  When no port is specified by the termination finds Bonding, it assigns a Bonding call ID x
     and accepts other side (see section 7.2.8),
the proposed call transfer rate requested by commands should be sent to the cal-
     ling H.320 endpoint. default port. The MG then sends a Notify message to defined protocol
has messages as the MGC
     informing it unit of transfer, while TCP is a stream-oriented
protocol.  TPKT, according to RFC1006 SHALL be used to delineate mes-
sages within the Bonding call identifier 'x' and the transfer
     rate:

             MEGACO/1.0 [124.124.124.222]:55555
             Transaction = 10000 {
                Context = 2000 { TCP stream.

Internet draft              MEGACO Protocol           September 21, 1999

                    Notify = A4444 {ObservedEvents =2222 {
                                       19990729T22040400:Bonding/CallID{CallID=x},
                                       Bonding/TransferRate {TransferRate=384}
                                   }
                    }
                }
             }

             The Notify is acknowledged:

             MEGACO/1.0 [124.124.124.121:]55566
             Reply = 10000 {
                Context =             January 27, 2000 {Notify}
             }

4.   The MGC allocates additional phone numbers

In a transaction-oriented protocol, there are still ways for the call and transaction
requests or responses to be lost.  As such, it is recommended that enti-
ties using TCP transport implement application level timers for each
request and each response, similar to those specified for application
level framing over UDP.

D.2.1.  Providing the MG to send these back At-Most-Once functionality

Messages, being carried over TCP, are not subject to transport losses,
but loss of a transaction request or its reply may nonetheless be noted
in real implementations. In the calling side by changing
     the signals descriptor:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10001 {
                Context = 2000 {
                    Modify = A4444 {
                      Signals {
                        Bonding/AddPhoneNrs{Phone=N1,Phone=N2,Phone=N3,
                        Phone=N4,Phone=N5}
                        }
                    }
                }
             }

5. absence of a timely response, commands
are repeated. Most commands are not idempotent.  The state of the MG replies to
would become unpredictable if, for example, Add commands were executed
several times.

To guard against such losses, it is recommended that entities follow the MGC's message
procedures in section D.1.1

D.2.2.  Transaction identifiers and sends the additional phone
     numbers back to three way handshake

For the calling Side via Bonding.

6.   When same reasons, it is possible that transaction replies may be
lost even with a reliable delivery protocol such as TCP.  It is recom-
mended that entities follow the SGW notifies procedures in section D.1.2

D.2.3.  Computing retransmission timers

With reliable delivery, the MGC incidence of incoming calls for the phone
     numbers associated with Bonding call x, the MGC sends Modify com-
     mands loss of a transaction request
or reply is expected to be very low.  Therefore, only simple timer
mechanisms are required. Exponential back-off algorithms should not be
necessary, although they could be employed where, as in an MGC, the MG code
to add the appropriate DS0 bearer channels do so is already required, since MGCs must implement ALF/UDP as well
as TCP.

D.2.4.  Provisional responses

As with UDP, executing some transactions may require a long time. Enti-
ties that can predict that a transaction will require a long execution
time may send a provisional response, "Transaction Pending". They should
send this response if they receive a repetition of a transaction that is
still being executed.

Entities that receive a Transaction Pending shall switch to the
     Termination created previously; the MG acknowledges these commands.
     For instance, a longer
repetition timer for the first two additional DS0s added:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10002 {
                Context = 2000 {
                   Modify = A4444 {
                      Mux = H221 {DS0_1,DS0_2,DS0_3,DS0_4,DS0_5}
                   } that transaction.

Entities shall retain Transactions and replies until they are confirmed.
The basic procedure of section D.1.4 should be followed, but simple
timer values should be sufficient.

Internet draft              MEGACO Protocol           September 21, 1999

                }
             }

             A reply to this Modify is sent by the MG.

7.   With the final Modify in which bearer channels (DS0s)             January 27, 2000

D.2.5.  Ordering of commands

TCP provides ordered delivery of transactions.  No special procedures
are added to
     the muxing termination, the MGC request the MG required.  It should be noted that ALF/UDP allows sending entity to notify it
modify its behavior under congestion, and in particular, could reorder
transactions when
     H.221 frames are detected.

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10003 {
                 Context = 2000 {
                        Modify = A4444 {
                            Events = 2223 {Bonding/H221Frames}
                        }
                 }
             }

             A reply to this Modify is sent by the MG.

8.   Once H.221 framing is found, a Notify is sent to the MGC.

             MEGACO/1.0 [124.124.124.222]:55555
             Transaction = 10004 {
                Context = 2000 {
                    Notify = A4444 {ObservedEvents =2223 {
                      19990729T22050005:Bonding/H221Frames{H221Frame=x}}}
                }
             }

             The Notify congestion is acknowledged:

             MEGACO/1.0 [124.124.124.121:]55566
             Reply = 10004 {
                Context = 2000 {Notify}
             }

9.   The MGC instructs encountered.  TCP could not achieve the Termination to listen
same results.

ANNEX E BASIC PACKAGES

This Annex contains definitions of some packages for DTMF tones in use with MEGACO.

E.1.  Generic

      PackageID: g (0x000e)
      Version: 1
      Extends: None
      Description:
            Generic package for commonly encountered items

E.1.1.  Properties

None

E.1.2.  Events

Cause
      EventID:  cause (0x0001)
      Generic error eventEvent Descriptor
      Parameters:
              General Cause
                  ParameterID: Generalcause (0x0001)
                  This parameter groups the
     audio stream, and possibly to play an announcement to failures into six groups,
                  which the calling
     user.

10. MGC may act upon.
                  Possible values:      Enumerated,
                        "NR" Normal Release (0x0001)
                              "UR" Unavailable Resources (0x0002)
                              "FT" Failure, Temporary (0x0003)
                              "FP" Failure, Permanent (0x0004)
                              "IW" Interworking Error (0x0005)
                              "UN" Unsupported (0x0006)
            Failure Cause
                      ParameterID: Failurecause (0x0002)
                  Possible Values:      OCTET STRING
                  Description: The audio announcement will be played and then the Termination will
     listen for DTMF tones in Release Cause is the audio portion of value generated
                       by the mux and it com-
     mences Released equipment, i.e. a TCS4/IIS signaling exchange released network
                       connection.  The concerned value is defined in the BAS channel. The

Internet draft              MEGACO Protocol           September 21, 1999

     information received is considered the destination alias z for this
     call.

11.             January 27, 2000

                       appropriate bearer control protocol.

Internet draft              MEGACO Protocol             January 27, 2000

        E.1.3.  Signals

        None

        E.1.4.  Statistics

        None

        E.2.  Base Root Package

        Base Root Package

              PackageID: root (0x000f)
              Version: 1
              Extends: None
              Description:
                    This package defines Gateway wide properties.

        E.2.1.  Properties

        MaxNrOfContexts
                PropertyID: maxNumberOfContexts (0x0001)
              The MG Notifies value of this property gives the MGC maximum number of
              contexts that can exist at least three pieces of information: 1)
     frame alignment found, 2) H.320 capabilities, any time.  The NULL context
              is not included in this number.
              Type: Double
              Possible values: 1 and 3) destination
     alias  z. up
        MaxTerminationsPerContext
              PropertyID: maxTerminationsPerContext (0x0002)
              The maximum number of allowed terminations in a context,
                    see section 6.1
              Type: Integer
              Possible Values: any integer
              Defined In: TerminationState
        normalMGExecutionTime
              PropertyId: normalMGExecutionTime (0x0003)
              Settable by the MGC sends ARQ to resolve IP address for alias z

12.  Once indicate the address is resolved, interval within which
                    the MGC does H.225 call setup. . .
     gets caps expects a response to any transaction from H.323 etc.  Note that we assume that
                    the MG (exclusive of network delay)
              Type: Integer
              Possible Values: any integer, represents milliseconds
        normalMGCExecutionTime
              PropertyId: normalMGCExecutionTime (0x0004)
              Settable by the MGC sets up to indicate the H.245 connection with interval within which
                    the MG should expects a response to any transaction
                    from the MGC (exclusive of network delay)

Internet draft              MEGACO Protocol             January 27, 2000

              Type: Integer
              Possible Values: any integer, represents milliseconds
        ProvisionalResponseTimerValue
              PropertyId: ProvisionalResponseTimerValue (0x0005)
              Indicates the called party.

13.  The MGC sends a Modify time within which to the H.320 termination causing expect a new capa-
     bility Pending
                    Response if a Transaction cannot be completed.
                    Initially set to normalMGExecutionTime or
                    normalMGCExecutionTime as appropriate, plus network
                    delay, but may be sent from lowered.
        Pattern
              PropertyId: Pattern (0x0006)
              Name pattern of a set of terminations in the MG gateway.
                    Used to discover the H.320 terminal, based on
     the received capabilities the MGC got from the H.323 endpoint.

14.  MGC may get an OLC from H.323 Side names of terminations that
                    can be audited.  Includes ephemeral terminations.
                    MGs SHOULD use one pattern for audio, each type of
                    termination (same packages implemented), but no
                    two Patterns can have the MGC will then Add
     a packet Termination same value.
              Type: String
              Possible Value:
                    A string of up to 64 characters using the Context. In this example, following
                    characters:
                            a-z,A-Z,0-9, and "/" - the MGC sets actual character
                                in the transmitting IP address and UDP port.

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10013 {
                 Context = 2000 {
                   Add  = $ {
                      Mux = H225-0 {A4444}, ;not sure what terminationId belongs name
                            * - any set of characters
                            ?a - any single character
                            ?0 - any digit
                            ?a - any alpha
                            [n,n,..,n] - alternatives, one of the
                                alternatives listed, n can be a substring
                                of alphas or digits
                            [n-n] - range, any number in the mux
                      Media { Stream = 1212 {
                        LocalControl { MaxJitterBuffer=40, Mode = SendReceive},
                        Local = SDP {c=IN IP4 ANY
                                     m=audio ANY RTP/AVP 0 99
                                     a=rtpmap:99 G729
                          },
                        Remote = SDP {c=IN IP4 45.123.1.1
                                      m=audio 5555 RTP/AVP 0 4}

                        } ; RTP profile range,
                                n can be a number or an alpha, for G.723 example
                                 [00-27] or [a-e]
                      Note, mixing of alternatives or ranges is 4
                      }
                   }
                 }
             } allowed,
                          as in: [0,3-5,8]
              Characteristics: Read-only
        MaxPatterns
              PropertyId: MaxPatterns (0x0007)
              The Modify is accepted with number of patterns in the following reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 10013 {
                Context = 2000 {
                  Add= A4445 {
                    Media {
                       Stream = 1212 { gateway
              Type: Integer
              Possible Value: any integer
              Characteristics: Read-only
        PatternNum
              PropertyId: PatternNum (0x0008)
              Which pattern to read, zero based.  Set by the MGC to
                    read a specific pattern in Pattern
              Type: Integer
              Possible Value: any integer less than MaxPatterns

Internet draft              MEGACO Protocol           September 21, 1999

                          Local = SDP {c=IN IP4 111.1.1.1
                                       m=audio 6666 RTP/AVP 0 99
                                       a=rtpmap:98 G729}
                       }
                    }
                  }
                }
             }

     The MGC assigns a StreamID to the media stream to allow the MG             January 27, 2000

E.2.2.  Events

None

E.2.3.  Signals

None

E.2.4.  Statistics

None

E.2.5.  Procedures

None

E.3.  Tone Generator Package

PackageID: tonegen (0x0001)
      Version: 1
      Extends: None
      Description:
            This package defines signals to
     identify the streams that have generate audio tones.
            This package does not specify parameter values. It is
            intended to be connected within the Context.
     The MG acknowledges the command and reports the assigned Termina-
     tionId to the MGC, as well extendable. Generally, tones are defined
            as the IP address an individual signal with a parameter, ind,
            representing "interdigit" time delay, and UDP port it
     selected for the Local Descriptor.

15.  The MGC sends a Modify tone id to
            be used with playtones.  A tone id should be kept
            consistent with any tone generation for the H.320 termination sending a Stream-
     Descriptor same tone.
            MGs are expected to be provisioned with the MG:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10013 {
                 Context = characteristics
            of appropriate tones for the country in which the MG is located.

E.3.1.  Properties

None

E.3.2.  Events

None

E.3.3.  Signals

Play tone

      SignalID: pt (0x0001)
      Plays audio tone over an audio channel
      Signal Type: Brief

Internet draft              MEGACO Protocol             January 27, 2000 {
                   Modify= A4445 {
                      Media {
                          Stream = 1212 {
                              LocalControl {Mode = SendReceive},
                              Remote = SDP {m=audio
                                            a=sendrecv}
                          }
                      }
                   }
                 }
             }

      Duration: Provisioned
      Additional Parameters:
            Tone id list
                  ParameterID: tl       (0x0001)
                  Type: list of tone ids.
                  List of tones to be played in sequence.
                        The MG acknowledges the Modify command.

     At list SHALL contain one or more tone ids.
            Inter signal duration
                  ParameterID: ind (0x0002)
                  Type: integer.
                  Timeout between two consecutive tones in milliseconds

No tone ids are specified in this point package. Packages that extend this
package can add possible values for tone id as well as adding individual
tone signals

E.3.4.  Statistics

None

E.3.5.  Procedures

None

E.4.  Tone Detection Package

PackageID: tonedet (0x0002)
      Version: 1
      Extends: None
      This Package defines events for audio tone detection.
            Tones are selected by name (tone id). MGs are expected
            to be provisioned with the MG knows that characteristics of appropriate
            tones for the audio streams from country in which the packet
     and circuit sides have MG is located.

This package does not specify parameter values. It is intended to be connected because they have
extendable.

E.4.1.  Properties

None

E.4.2.  Events

Start tone detected
      EventID: std, 0x0001
      Detects the same
     StreamID.

16.  The H.320 side may do start of a mode switch to H.263 video for example. tone. The
     H.320 termination will then send an event to the MGC requesting
     H.263 video:

             MEGACO/1.0 [124.124.124.222]:55555
             Transaction = 10004 {
                Context = 2000 { characteristics of positive

Internet draft              MEGACO Protocol           September 21, 1999

                    Notify = A4444 {
                        ObservedEvents =2224 {
              19990729T22050100:H242Pkg/ModeChange{Mode=AddH263}
                        }
                    }
                }
             }             January 27, 2000

            tone detection is implementation dependent.
      EventsDescriptor parameters:
            Tone id list
                  ParameterID: tl (0x0001)
                  Type:  list of tone ids
                  Possible values: The MGC sends a reply to only tone id defined in this Notify.

17.  The MGC must send an OLC to the H.323 side.

18.  The MGC modifies the packet termination, by adding another RTP flow
     and changing the stream descriptor to include the video.  In the
     same Transaction, the H.320 termination
                              package is modified "wild card" which is "*" in
                        text encoding and 0x0000 in binary.
                        Extensions to include the
     video:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10013 {
                 Context = 2000 {
                   Modify= A4445 {
                      Media { Stream = 1213 {
                        LocalControl {Mode = SendReceive},
                        Local = SDP {c=IN IP4 ANY
                                     m=video ANY RTP/AVP 34},
                                      ;RTP profile this package would add
                        possible values for H.263 tone id.
                        If tl is "wild card", any tone id is detected
      ObservedEventsDescriptor parameters:
            Tone id
                  ParameterID: tid (0x0003)
                  Type: Enumeration
                  Possible values: "wildcard" as defined above is 34
                        Remote = SDP {c=IN IP4 45.123.1.2
                                      m=video 5556 RTP/AVP 34}
                              }
                      }
                   },
                   Modify= A4444 {
                      Media { Stream = 1213 {
                              LocalControl {Mode = SendReceive},
                              Local = SDP {m=video
                                           a=sendrecv}
                              }
                      }
                   }
                 }
             }

     The MG already knows the parameters of the video stream on the
     H.320 side.  The
                        only thing that value defined in this package. Extensions
                        to this package would add additional possible
                        values for tone id
End tone detected
      EventID: etd, 0x0002
      Detects the controller has end of a tone.
      EventDescriptor parameters:
            Tone id list
                  ParameterID: tl (0x0001)
                  Type: enumeration or list of enumerated types
                  Possible values: No possible values are specified
                        in this package.  Extensions to do this package
                        would add possible values for tone id
      ObservedEventsDescriptor parameters:
            Tone id
                  ParameterID: tid (0x0003)
                  Type: Enumeration
                  Possible values: "wildcard" as defined above is the
                        only value defined in this package.
                        Extensions to set this package would add possible
                        values for tone id
            Duration
                  ParameterId: dur (0x0002)
                  Type: integer, in milliseconds
                  This parameter contains the StreamID duration of the video stream. tone
                        from first detection until it stopped.
Long tone detected
      EventID: ltd, 0x0003
      Detects that a tone has been playing for at least a certain
            amount of time
      EventDescriptor parameters:
            Tone id list

Internet draft              MEGACO Protocol           September 21, 1999

The  of             January 27, 2000

                  ParameterID: tl (0x0001)
                  Type: enumeration or list
                  Possible values: "wildcard" as defined above is the Modify
                        only value defined in this package. Extensions
                        to terminationId A4445 this package would return add possible values for
                        tone id
            Duration:
                  ParameterID: dur (0x0002)
                  Type: integer, duration to the MGC the IP
address and port of the Local descriptor.

21.2.2.  Multipoint Context Example

This example shows how a multimedia context can be used test against
                  Possible values: any legal integer, expressed in
                        milliseconds
      ObservedEventsDescriptor parameters:
            Tone id:
                  ParameterID: tid (0x0003)
                  Possible values: No possible values are specified
                  in this package.  Extensions to bridge an
H.320 user and three H.323 users into a single multipoint conference.
In the picture the types of media flowing over the links between this package
                  would add possible values for tone id

E.4.3.  Signals

None

E.4.4.  Statistics

None

E.4.5.  Procedures

None

E.5.  Basic DTMF Generator Package

PackageID: dg (0x0003)
      Version: 1
      Extends: tonegen version 1
      This package defines the
terminations are shown for clarity. The bridging functionality is a con-
text property, there is no separate bridge entity in basic DTMF tones as signals and
            extends the connection
model.

Internet draft              MEGACO Protocol           September 21, 1999

          +--------------------------------------------------------+
          | Context x                                              |
          |                                                        |
          |         +---------+                 +-------+          |
          |         |         |                 |       |          |
          | +-------|         |                 |       |          |
          | |  RTP  |         |                 |       |--------+ |
          | | Audio |         |-             /-|       | DS-0-1 | |
          | +-------| H.225.0 |             /  | H.221 |--------+ |
          |         |   MUX   |            /   |  MUX  |          |
          | +-------|         |           /    |       |          |
          | |  RTP  |         |          /     |       |--------+ |
          | | Video |         |     ___/     /|       | DS-0-2 | |
          | +-------|         |      | |     / |       |--------+ |
          |         |         |     /___   /  |       |          |
          | +-------|         |    /      /   |       |          |
          | | T.120 |         |          /   /|       |          |
          | | Data  |         |  / |     |  / |       |          |
          | +-------|         |    |     |  /  |       |          |
          |         +---------+ / | |     | |  +-------+          |
          |                     | |      / | |                    |
          |         +---------+ | |  ___/  | | +---------+        |
          |         |         | | |   | |   | | |         |        |
          | +-------|         | | |  /___  | | |         |-------+|
          | |  RTP  |         |/  | /      |           |  RTP  ||
          | | Audio |         |   |/          |         | Audio ||
          | +-------| H.225.0 |   |         |   | H.225.0 |-------+|
          |         |   MUX   |  /         /  |   MUX   |        |
          | +-------|         | /         /   |         |-------+|
          | |  RTP  |         |/         /             |  RTP  ||
          | | Video |         |      ___/      |         | Video ||
          | +-------|         |       | |       |         |-------+|
          |         |         |      /___      |         | allowed values of parameter tl of playtone
            in tonegen.

E.5.1.  Properties

None

E.5.2.  Events

None

Internet draft              MEGACO Protocol             January 27, 2000

E.5.3.  Signals

dtmf character 0
      SignalID: d0 (0x0010)
      Generate DTMF 0 tone. The physical characteristic of DTMF 0
            is defined in the gateway.
      Signal Type: Brief
      Duration: Provisioned
      Additional Parameters:
            None
      Additional Values:
            d0 (0x0010) is defined as a toneid for playtone

The other dtmf characters are specified in exactly the same way.  For
brevity's sake only a table with the signal names and the signal IDs is
included.  Note that each dtmf character is defined as both a signal and
a toneid, thus extending the basic tone generation package.  Also note
that dtmf SignalIds are different from the names used in a digit map.

                    ________________________________
                   | Signal Name     | +-------|  Signal ID  |     /
                   |         |-------+| dtmf character 1|  d1 (0x0011)|
                   | dtmf character 2|  d2 (0x0012)|
                   | T.120 dtmf character 3|  d3 (0x0013)|
                   |         |----/       ----| dtmf character 4|  d4 (0x0014)|
                   | T.120 || dtmf character 5|  d5 (0x0015)|
                   | dtmf character 6|  d6 (0x0016)|
                   | Data dtmf character 7|  d7 (0x0017)|
                   | dtmf character 8|  d8 (0x0018)|
                   | dtmf character 9|  d9 (0x0019)|
                   | dtmf character *|  d* (0x0020)|
                   | Data  || dtmf character #|  d# (0x0021)|
                   | +-------| dtmf character A|  da (0x001a)|
                   | dtmf character B|  db (0x001b)|
                   |         |-------+| dtmf character C|  dc (0x001c)|
                   |         +---------+                 +---------+ dtmf character D|  dd (0x001d)|
                   |_________________|_____________|

E.5.4.  Statistics

None

E.5.5.  Procedures

None

Internet draft              MEGACO Protocol             January 27, 2000

E.6.  DTMF detection Package

PackageID: dd (0x0004)
      Version: 1
      Extends: tonedet version 1
      This package defines the basic DTMF tones detection.
            This Package extends the possible values of tone id
            in the "start tone detected" "end tone detected"
            and "long tone detected" events.

Additional tone id values are all tone ids described in package dg
(basic DTMF generator package).

Implementers of this package shall support d0-d9,d* and d#.  Support of
dA-dD is optional.

E.6.1.  Properties

None

E.6.2.  Events

DTMF digits
      EventIds are defined with the same names as the SignalIds
            defined in the table found in section E.5.3
DigitMap Completion Event
      EventID: ce, 0x0001
      Raised when the termination tone is detected on a digit map.
      EventsDescriptor parameters: none
      ObservedEventsDescriptor parameters:
            DigitString
                  ParameterID: ds (0x0001)
                  Type:  list of tone ids
                  Possible values: any of the DTMF or MF digits

E.6.3.  Signals

None

E.6.4.  Statistics

None

E.6.5.  Procedures

None

Internet draft              MEGACO Protocol             January 27, 2000

E.7.  Call Progress Tones Generator Package

      PackageID: cg, 0x0005
      Version: 1
      Extends: tonegen version 1
      This package defines the basic call progress tones as signals
            and extends the allowed values of the tl parameter of
            playtone in tonegen.

E.7.1.  Properties

None

E.7.2.  Events

None

E.7.3.  Signals

Dial Tone
      SignaID: dt (0x0030)
      Generate dial tone. The physical characteristic of dial tone
            is available in the gateway.
      Signal Type: Timeout
      Duration: Provisioned
      Additional Parameters:
            None
      Additional Values
            dt (0x0030) is defined as a tone id for playtone

The other tones of this package are defined in exactly the same way. For
brevity's sake only a table with the signal names and the signal IDs is
included.  Note that each tone is defined as both a signal and a toneid,
thus extending the basic tone generation package.
                                 l |
          +--------------------------------------------------------+
                               Figure l.
Signal Name!Signal ID/tone id Ringing Tone!rt (0x0031) Busy Tone!bt
(0x0032) Congestion Tone!ct (0x0033) Special Information
Tone!sit(0x0034) Warning Tone!wt (0x0035) Payphone Recognition Tone!pt
(0x0036) Call Waiting Tone!cw (0x0037) Caller Waiting Tone!cr (0x0038)

E.7.4.  Statistics

None

Internet draft              MEGACO Protocol             January 27, 2000

E.7.5.  Procedures

NOTE - The required set of tone ids corresponds to those defined in
Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)].  See
E.180 for definition of the meanings of these tones.

E.8.  Call Progress Tones Detection Package

PackageID: cd (0x0006)
      Version: 1
      Extends: tonedet version 1
      This package defines the basic call progress detection tones.
            This Package extends the possible values of tone id
            in the "start tone detected", "end tone detected" and
            "long tone detected" events.
      Additional values
            tone id values are defined for start tone detected,
                  end tone detected and long tone detected with
                  the same values as those in package cg (call
                  progress tones generation package).

The required set of tone ids corresponds to Recommendation E.180/Q.35
[ITU-T Recommendation E.180/Q.35 (1998)].  See Recommendation E.180/Q.35
for definition of the meanings of these tones.

E.8.1.  Properties

none

E.8.2.  Events

Events are defined as in the dtmf detection package (dd) for the tones
listed in the table of section E.7.3

E.8.3.  Signals

none

E.8.4.  Statistics

none

E.8.5.  Procedures

none

Internet draft              MEGACO Protocol             January 27, 2000

E.9.  Analog Line Supervision Package

PackageID: al, 0x0009
      Version: 1
      Extends: None
      This package defines events and signals for an analog line.

E.9.1.  Properties

None

E.9.2.  Events

onhook
      EventID: on (0x0004)
      Detects handset going on hook.
      EventDescriptor parameters
            None
      ObservedEventsDescriptor parameters
            None
offhook
      EventID: of (0x0005)
      Detects handset going off hook.
      EventDescriptor parameters
            None
      ObservedEventsDescriptor parameters
            None
flashhook
      EventID: fl, 0x0006
      Detects handset flash. A flash occurs when an onhook is
followed by an offhook between a minimum and
maximum duration.
      EventDescriptor parameters
            Minimum duration
                  ParameterID: mindur (0x0004)
                  Type: integer in milliseconds
                  Default value is provisioned
            Maximum duration
                  ParameterID: maxdur (0x0005)
                  Type: integer in milliseconds
                  Default value is provisioned
      ObservedEventsDescriptor parameters
            None

E.9.3.  Signals

ring

Internet draft              MEGACO Protocol             January 27, 2000

      SignalID: ri, 0x0002
      Applies ringing on the line
      Signal Type: TimeOut
      Duration: Provisioned
      Additional Parameters:
            Cadence
                  ParameterID: cad (0x0006)
                  Type: list of integers representing durations of
                        alternating on and off segments, constituting
                        a complete ringing cycle starting with an on.
                        Units in milliseconds
                  Default is fixed or provisioned.  Restricted function
                        MGs may ignore cadence values they are
                        incapable of generating.
            Frequency
                  ParameterID: freq (0x0007)
                  Type: integer in Hz
                  Default is fixed or provisioned.  Restricted function
                        MGs may ignore frequency  values they are
                        incapable of generating.

E.9.4.  Statistics

None

E.9.5.  Procedures

None

E.10.  Basic Continuity Package

PackageID: ct (0x000a)
      Version: 1
      Extends: None
      This package defines events and signals for continuity test.

E.10.1.  Properties

None

E.10.2.  Events

Completion
      EventID: cmp, 0x0005
      Detects test completion.
      EventDescriptor parameters

Internet draft              MEGACO Protocol             January 27, 2000

            None
      ObservedEventsDescriptor parameters
            Result
                  ParameterID: res (0x0008)
                  Type: Enumeration
                  Possible values: success (0x0001), failure (0x0000)

E.10.3.  Signals

Initiate
      SignalID: ini (0x0003)
      Initiates continuity test of a specified type
      Signal Type: OnOff
      Additional Parameters:
            Test type
                  ParameterID: tt
                  Type: enumeration of possible test types
                  Possible Values: q724
                  Default is provisioned
Respond
      SignalID: rsp (0x0004)
      Responds to a continuity test of a specified type
      Signal Type: OnOff
      Additional Parameters:
            Test type
                  ParameterID: tt
                  Type: enumeration of possible test types
                  Possible Values: q724
                  Default is provisioned

E.10.4.  Statistics

None

E.10.5.  Procedures

When a MGC initiates or responds to a MG by sending the Initiate or
Response signal to the MG, the MG shall perform the continuity test in
accordance with section 7 Multimedia Context Example

21.2.3.  Single Media Call (for 4-wire speech circuits) or section 8 (for
2-wire speech circuits) of Recommendation Q.724.

E.11.  Network Package

      PackageID: nt (0x000b)
      Version: 1
      Extends: None

Internet draft              MEGACO Protocol             January 27, 2000

      This package defines properties of network terminations
            independent of network type.

E.11.1.  Properties

Maximum Jitter Buffer
      PropertyID: jit (0x0007)
      This property puts a maximum size on the jitter buffer.
      Type: integer in milliseconds
      Possible Values: This property is specified in milliseconds.
      Defined In: LocalControlDescriptor
      Characteristics: read/write

E.11.2.  Events

network failure
      EventID: netfail, 0x0005
      The single media termination generates this event upon detection of a
            failure due to external or internal network reasons.
      EventDescriptor parameters
            none
      ObservedEventsDescriptor parameters
            cause
                  ParameterID: cs (0x0001)
                  Type: String
                  Possible values: any text string
                  This parameter may be included with the call flow example
describes failure
                  event to provide diagnostic information on the
                  reason of failure.
quality alert
      EventID: qualert, 0x0006
      This property allows the MG to indicate a call loss of quality
            of the network connection. The MG may do this by
            measuring packet loss, interarrival jitter, propogation
            delay and then indicating this using a percentage of
            quality loss.
      EventDescriptor parameters
            Threshold
                  ParameterId: th (0x0001)
                  Type: integer
                  Possible Values: threshold for percent of quality
                        loss measured, calculated based on a
                        provisioned method, that could take into
                        consideration packet loss, jitter, and delay
                        for example.  Event is triggered when
                        calculation exceeds the threshold.

Internet draft              MEGACO Protocol             January 27, 2000

      ObservedEventsDescriptor parameters
            Threshold
                  ParameterId: th (0x0001)
                  Type: integer
                  Possible Values: percent of quality loss measured,
                        calculated based on a provisioned method,
                        that originates could take into consideration packet loss,
                        jitter, and delay for example.

E.11.3.  Signals

none

E.11.4.  Statistics

Duration
      StatisticsID: dur (0x0001)
      Description: Provides duration of time the termination has
            been in the SCN context.
      Type: Double, in milliseconds
Octets Sent
      StatisticID: os (0x0002)
      Type: double
      Possible Values: any 64 bit integer
Octets Received
      StatisticID: or (0x0003)
      Type: double
      Possible Values: any 64 bit integer

E.11.5.  Procedures

none

E.12.  RTP Package

      PackageID: rtp (0x000c)
      Version: 1
      Extends: Network Package version 1
      This package is used to support packet based multimedia
            data transfer by means of the Real-time Transport Protocol
            (RTP) [RFC 1889].

E.12.1.  Properties

None

Internet draft              MEGACO Protocol             January 27, 2000

E.12.2.  Events

Payload Transition
      EventID: pltrans, 0x0001
      This event detects and notifies when there is terminated a transition
      of the RTP payload format from one format to another.
      EventDescriptor parameters
            none
      ObservedEventsDescriptor parameters
            ParameterName: rtppayload
                  ParameterID: rtppltype, 0x01
                  Type: list of enumerated types.
                  Possible values: The encoding method shall be
                        specified by using one or several valid
                        encoding names, as defined in the RTP AV
                        Profile or registered with IANA.

E.12.3.  Signals

None

E.12.4.  Statistics

Packets Sent
      StatisticID: ps (0x0004)
      Type: double
      Possible Values: any 64 bit integer
Packets Received
      StatisticID: pr (0x0005)
      Type: double
      Possible Values: any 64 bit integer
Packet Loss
      StatisticID: pl (0x0006)
      Describes the current rate of packet network.  The packet network signaling loss on an RTP stream,
      as defined in this example IETF RFC 1889. Packet loss is H.323
but other signaling protocols such expressed as SIP can be used,
      percentage value: number of packets lost in the interval
      between two reception reports, divided by the number of
      packets expected during that interval.
      Type: double
      Possible Values: a 32 bit whole number and a 32 bit fraction.
Jitter
      StatisticID: jit (0x0007)
      Requests the purpose current value of the example is to describe MG/MGC interactions. interarrival jitter
            on an RTP stream as defined in IETF RFC 1889.
            Jitter measures the variation in interarrival time
            for RTP data packets.
Delay

Internet draft              MEGACO Protocol           September 21, 1999

          +---------------------------------------------------+
          | Context x                                         |
          |                                                   |
          | +-------------+        +-+        +-------------+ |
          | |  RTP Audio  |--------|*|--------|  DS0 Audio  | |
          | | Termination |        +-+        | Termination | |
          | +-------------+                   +-------------+ |
          |                                                   |
          +---------------------------------------------------+

                            Figure 8 Single Media Call Example

The assumption is made that the signalling between             January 27, 2000

      StatisticID:delay (0x0008)
      Requests the signalling gate-
way (SGW) and MGC is based on Q.931. current value of packet propagation delay
            expressed in timestamp units. Same as average latency.

E.12.5.  Procedures

none

E.13.  DS0  Package

PackageID: ds0 (0x000d)
      Version: 1
      Extends: Network Package version 1
      This does not indicate that no
other signalling can be package is used on this interface.

1.   The SGW sends a Setup message to support DS0 terminations.

E.13.1.  Properties

Echo Cancellation
      PropertyID: ec (0x0008)
      By default, the MGC after receiving an IAM
     from a SCN switch.

2.   From the IAM message, the MGC may infer which circuit on which MG telephony gateways always perform
      echo cancellation.  However, it is involved and where necessary, for some
      calls, to terminate the call.  How turn off these operations.
      Type: boolean
      Possible Values:
            "on" (when the MGC does
     this, echo cancellation is requested) and
            "off" (when it is turned off.)
            The default is "on".
      Defined In: LocalControlDescriptor
        Characteristics: read/write
Gain Control
      PropertyID: gain (0x000a)
      Gain control, or usage of of signal level adaptation and
            noise level reduction is outside used to adapt the scope level of this document.

3.   The MGC creates a Context for
            the call.  The Context contains two
     terminations: one signal. However, it is necessary, for the SCN side and one example
            for the packet side. In modem calls, to turn off this example, function.
      Type: enumeration (integer)
      Possible Values:
            The gain control parameter may either be specified
            as "automatic" (0xffffffff), or as an explicit number
            of decibels of gain (any other integer value).
            The default is provisioned in the MGC has selected a particular physical termina-
     tion; DS0/13/2.

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 9999 {
               Context = $ {
                 Add = DS0/13/2 {
                   Media { TerminationState {
                             BufferedEventHandling{Step,Process}},
                             Stream = 1111 {
                               LocalControl {
                                 Mode = SendReceive,
                                 Package1/GainControl=0,
                                 Package1/EchoCancellation=G165,
                                 Package1/VoiceActDet=yes
                                },
                                Local = SDP {c=LOCAL
                                             m=audio 0 LOCAL 0
                                             a=recv
                                             a=ptime:10 MG.
      Defined In: LocalControlDescriptor
      Characteristics: read/write

Internet draft              MEGACO Protocol           September 21, 1999

                                }; SDP profile 0 is G.711mu-law sampled at
             8kHz
                             }
                        }
                    },
                 Add = $ {
                   Mux = H225-0 {DS0/13/2}, ; is terminationId correct here
             for             January 27, 2000

E.13.2.  Events

none

E.13.3.  Signals

none

E.13.4.  Statistics

None

E.13.5.  Procedures

None

APPENDIX A      EXAMPLE CALL FLOWS (INFORMATIVE)

All Megaco implementors must read the mux?
                   Media { Stream = 1111 {
                             LocalControl {
                               Mode = ReceiveOnly,
                               Package1/MaxJitterBuffer=40, ; in ms
                               Package1/PreferredPacketization=20, ; normative part of this document
carefully before implementing from it. No one should use the examples in ms
                               Package1/PreferredCodecs=[G723, PCMU],
                               Package1/Gain=0 ;
this section as stand-alone explanations of how to create protocol mes-
sages.

The examples in dB
                             },
                             Local = this section use SDP {c=IN IP4 ANY
                                          m=audio ANY RTP/AVP ANY
                                          a=sendrecv
                             }, for encoding of the Local and
Remote = stream descriptors. SDP {c=IN IP4 ANY
                                           m=audio ANY RTP/AVP ANY
                                           a=sendrecv
                             }
                           }
                        }
                    }
                 }
             }

     The different media flows are identified by a StreamID.  In the
     case that is defined in RFC 2327. If there is only one medium, this StreamID can be omitted.

     We see any
discrepancy between the SDP in the examples, and RFC 2327, the RFC
should be consulted for correctness. Audio profiles used are those
defined in RFC 1890, and others registered with IANA. For example, G.711
A-law is called PCMA in the command syntax how SDP, and is assigned profile 0. G.723 is
profile 4, and H263 is profile 34. See also http://www.isi.edu/in-
notes/iana/assignments/rtp-parameters

A.1.  Residential Gateway to Residential Gateway Call

This example scenario illustrates the MGC uses use of the elements of the proto-
col to set up a "$" Residential Gateway to leave Residential Gateway call over an
IP-based network.  For simplicity, this example assumes that both
Residential Gateways involved in the
     assignment of names call are controlled by the same
Media Gateway Controller.

20.1.1.  Programming Residential GW Analog Line Terminations for both Idle
Behavior

The following illustrates the Context itself API invocations from the Media Gateway
Controller and Media Gateways to get the Termina-
     tions Terminations in it, to this scenario
programmed for idle behavior.  Both the MG.

3.   The MG accepts originating and terminating
Media Gateways have idle AnalogLine Terminations programmed to look for
call initiation events (i.e.-offhook) by using the Context creation Modify Command with this reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 9999 {
               Context = 2000 {
                 Add,
                 Add= A4445 {
                   Media {
                     Stream = 1111 {
                       Local = SDP {v=0

Internet draft              MEGACO Protocol           September 21, 1999

                                    c=IN IP4 45.123.1.1
                                    m=audio 5555 RTP/AVP 0 4
                                    a=ptime:20
                        } ; RTP profile for G.723             January 27, 2000

the appropriate parameters.  The null Context is 4
                      }
                    }
                  }
                }
             }

     This step shows how used to indicate that
the Terminations are not yet involved in a Context. The ROOT termination
is used to indicate the entire MG instead of a termination within the
MG.

In this example, MG1 has the IP address 124.124.124.222, MG2 is
125.125.125.111, and the MGC is 123.123.123.4. The default Megaco port
is 55555 for all three.

1.   An MG reports to the registers with an MGC what parameters it
     filled in for using the IP address and UDP port ServiceChange command:

     MG1 to which media should be
     addressed.

4. MGC:
     MEGACO/1 [124.124.124.222]
     Transaction = 9998 {
         Context = - {
             ServiceChange = ROOT {Services {
                 Method=Restart,
                 ServiceChangeAddress=55555, Profile=ResGW/1}
             }
         }
     }

2.   The MGC sends a Setup message to the destination endpoint, here
     assumed reply:

     MGC to be MG1:
     MEGACO/1 [123.123.123.4]:55555
     Reply = 9998 {
        Context = - {ServiceChange = ROOT {
          Services {ServiceChangeAddress=55555, Profile=ResGW/1} } }
     }

3.   The MGC programs a H.323 endpoint (terminal, GW, ...).  It indicates Termination in the fastStart element that either G.711 or G.723 may be used for
     the voice stream.

5. NULL context. The H.323 endpoint sends an Alerting message back to termina-
     tionId is A4444, the MGC,
     informing it of streamId is 1, the codec to be used (assume G.723 for both direc-
     tions) and requestId in the transport address.

6. Events
     descriptor is 2222. The MGC sends a Modify command to   mId is the MG to set identifier of the Mode sender of
     this message, in this case, it is the IP address and Bearer
     information port
     [123.123.123.4]:55555. Mode for this stream is set to SendReceive.
     "al" is the packet side  Remote Descriptor:

             MEGACO/1.0 [124.124.124.121:]55566 analog line supervision package.

     MGC to MG1:
     MEGACO/1 [123.123.123.4]:55555
     Transaction = 10000 9999 {
         Context = 2000 - {
             Modify = A4445 A4444 {
                 Media { Stream = 1111 1 {
                       Remote
                          LocalControl {
                              Mode = SDP {c=IN SendReceive,

Internet draft              MEGACO Protocol             January 27, 2000

                              ds0/gain=2,  ; in dB,
                              ds0/ec=G165
                          },
                          Local {
     v=0
     c=IN IP4 111.1.1.1 $
     m=audio 1111 $ RTP/AVP 0 4}
     a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
                             ; detection algorithm
                          }
                      }
                 },
                 Events = 2222 {al/of}
             }
         }
     }

5.

The MG dialplan script could have been loaded into the MG previously.  Its
function would be to wait for the OffHook, turn on dialtone and start
collecting DTMF digits. However in this example, we use the digit map,
which is put into place after the offhook is detected (step 5 below).

Note that the embedded EventsDescriptor could have been used to combine
steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.

4.   The MG1 accepts the Modify command with this reply:

             MEGACO/1.0

     MG1 to MGC:
     MEGACO/1 [124.124.124.222]:55555
     Reply = 10000 9999 {
        Context = 2000 {Modify}

Internet draft              MEGACO Protocol           September 21, 1999 - {Modify = A4444}
     }

6.   The MGC sends an Alerting message to

5.   A similar exchange happens between MG2 and the SGW.

7.   The MGC, resulting in an
     idle Termination called endpoint at some instance sends a Connect message to A5555.

A.1.2. Collecting Originator Digits and Initiating Termination

The following builds upon the
     MGC.

8.   In response previously shown conditions.  It illus-
trates the transactions from the Media Gateway Controller and originat-
ing Media Gateway (MG1) to get the Connect, originating Termination (A4444)
through the MGC sends stages of digit collection required to initiate a Modify command connection
to the
     MG terminating Media Gateway (MG2).

Internet draft              MEGACO Protocol             January 27, 2000

6.   MG1 detects an offhook event from User 1 and reports it to change the Activity of the Local stream descriptor on
     Media Gateway Controller via the SCN
     Side:

             MEGACO/1.0 [124.124.124.121:]55566 Notify Command.

     MG1 to MGC:
     MEGACO/1 [124.124.124.222]:55555
     Transaction = 10001 10000 {
        Context = 2000 {
                 Modify = A4445 {
                   Media - {
                     Stream
            Notify = 1111 A4444 {ObservedEvents =2222 {
                       Local = SDP {a=sendrecv}
              19990729T22000000:al/of}}
        }
     }
                 }
               }
             }

9.   The

7.   And the Notify is acknowledged.

     MGC sends a Connect message to the SGW

10.  The MG accepts the Modify command with this reply:

             MEGACO/1.0 [124.124.124.222]:55555 MG1:
     MEGACO/1 [123.123.123.4]:55555
     Reply = 10001 10000 {
         Context = 2000 {Modify}
             }

21.2.4.  H.323 and FAS Signaling in MG

{Editor's note: This section needs reviewing  to make sure it reflects
the changes of the Santiago meeting. - {Notify = A4444}
     }

8.   The following flow describes an H.320 to H.323 gateway call where MGC Modifies the
signaling termination to play dial tone, and media terminations to look for the SCN and packet network both
reside on the MG.  In this case the MG terminates
     digits now. There is also an ISDN PRI interface
and embedded event to stop dialtone upon
     detection of the packet interface first digit. dd is H.323 IP and also resides on the MG. The
signaling capabilities are represented as physical H.323 DTMF Detection package, and FAS termi-
nations that exchange events with
     ce is the completion event.

     MGC to indicate changes in call
state. This gateway session uses Bonding channel aggregation making MG1:
     MEGACO/1 [123.123.123.4]:55555
     Transaction = 10001 {
         Context = - {
             Modify = A4444 {
                 Events = 2223 {
                     al/on, dd/ce {DigitMap=Dialplan0}
                 },
                 Signals {cg/dt},
                 DigitMap= Dialplan0{
     (0S| 00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x.S)}
             }
         }
     }

9.   And the Modify is acknowledged.

Internet draft              MEGACO Protocol           September 21, 1999

example a super-set of gateway call that uses H.221 channel aggregation.

1.   The MG creates a FAS termination and an H.323 termination on
     power-on and reports these events             January 27, 2000

     MG1 to the MGC in a Notify.

2.   MGs FAS termination gets an incoming call with (Q.931) call type MGC:
     MEGACO/1 [124.124.124.222]:55555
     Reply = 10001 {
         Context = - {Modify = A4444}
     }

10.  Next, digits are accumulated by MG1 as they are dialed by User 1.
     Dialtone is stopped upon detection of
     data, the MG sends a Notify to the MGC.

3.   The MGC creates a context and Adds a FAS termination to it, con-
     taining H.320 and Bonding packages, to connect first digit, using the B channel.

4.
     embedded event in step 8. When an appropriate match is made of col-
     lected digits against the termination finds Bonding, it assigns a Bonding call ID x
     and then allocates additional phone numbers currently programmed Dialplan for the call and sends
     these back to the calling side via Bonding.

5.   The MG sends a A4444,
     another Notify is sent to the Media Gateway Controller.

     MG1 to MGC:
     MEGACO/1 [124.124.124.222]:55555
     Transaction = 10002 {
        Context = - {
            Notify = A4444 {ObservedEvents =2223 {
              19990729T22010001:dd/ce{tones="916135551212"}}}
        }
     }

11.  And the MGC.

6.   The Notify is acknowledged.

     MGC sends an Add to MG1:
     MEGACO/1 [123.123.123.4]:55555
     Reply = 10002 {
         Context = - {Notify = A4444}
     }

12.  The controller then analyses the MG to create a multimedia context digits and
     sends determines that a Modify con-
     nection needs to be made from MG1 to move/add MG2. Both the DS0 TDM termination
     A4444, and an RTP termination are added to the a new mul-
     timedia context .

7.   The FAS termination detects signaling for 5 additional B channels,
     sends a Notify to MGC, and in MG1.
     Mode is ReceiveOnly since Remote descriptor values are not yet
     specified. Preferred codecs are in the MGC's preferred order of
     choice.

     MGC adds these B channels to the mux
     termination MG1:
     MEGACO/1 [123.123.123.4]:55555
     Transaction = 10003 {
         Context = $ {
            Add = A4444,
            Add = $ {

Internet draft              MEGACO Protocol             January 27, 2000

                Media {
                  Stream = 1 {
                       LocalControl {
                           Mode = ReceiveOnly,

                           nt/jit=40, ; in the MG

8.   The MG detect Bonding and sends a Notify to the MGC

9. ms
                       },
                       Local {
     v=0
     c=IN IP4 $
     m=audio $ RTP/AVP 4
     a=ptime:30
     v=0
     c=IN IP4 $
     m=audio $ RTP/AVP 0
                       }
                  }
               }
            }
         }
     }

NOTE - The MGC sends states its preferred parameter values as a modify to move the termination into the multimedia
     context

10. series of sdp
blocks in  Local. The remaining B channels connect MG fills in the same manner

11.  After all five additional DS0s have been added the H.320 termina-
     tion can complete Bonding and start looking for H.221 framing.

12.  Once H.221 framing is found a Notify is sent to the MGC. Local Descriptor in the Reply.

13.  The H.221 Termination will play  MG1 acknowledges the audio announcement new Termination and listen
     for DTMF tones fills in the audio portion of the mux Local IP
     address and it commences UDP port. It also makes a
     TCS4/IIS signaling exchange in the BAS channel. The information
     received is considered the destination z alias choice for this call.

14.  The MG Notifies the MGC of codec based on
     the destination alias  z.

15.  The MGC sends ARQ preferences in Local. MG1 sets the RTP port to resolve IP address 2222.

     MEGACO/1 [124.124.124.222]:55555
     Reply = 10003 {
        Context = 2000 {
           Add = A4444,
           Add=A4445{
              Media {
                  Stream = 1 {
                      Local {
     v=0
     c=IN IP4 124.124.124.222
     m=audio 2222 RTP/AVP 4
     a=ptime:30
     a=recvonly
                      } ; RTP profile for alias z

16.  Once the address G.723 is resolved, the MGC Adds an H.323 signaling to
     the multimedia context 4
                  }
              }

Internet draft              MEGACO Protocol           September 21, 1999

17.  The H.323 termination in the context starts H.225/h.245 call setup
     and media negotiation sequence.

18.             January 27, 2000

           }
        }
     }

14.  The MG sends MGC will now associate A5555 with a Notify new Context on MG2, and
     establish an RTP Stream (i.e, A5556 will be assigned), SendReceive
     connection through to the originating user, User 1. The MGC also
     sets ring on A5555.

     MGC announcing the completion of call
     signaling.

19.  In the MG capabilities received from the H.323 terminations are
     forward to the H.320 termination and vice versa. MG2:
     MEGACO/1 [123.123.123.4]:55555
     Transaction = 50003 {
         Context = $ {
            Add = A5555  { Media {
                 Stream = 1 {
                      LocalControl {Mode = SendReceive} }},
                 Signals {al/ri}
                 },
            Add  = $ {Media {
                 Stream = 1 {
                      LocalControl {
                         Mode = SendReceive,
                         nt/jit=40 ; in ms
                      },
                      Local {
     v=0
     c=IN IP4 $
     m=audio $ RTP/AVP 4
     a=ptime:30
                      },
                      Remote {
     v=0
     c=IN IP4 124.124.124.222
     m=audio 2222 RTP/AVP 4
     a=ptime:30
                      } ; RTP profile for G.723 is 4
                  }
               }
           }
        }
     }

17.  This is acknowledged. The GW sends a
     Notify to the MGC whenever an H.242 or H.245 media capability
     exchange occurs.

20.  MG may get an OLC stream port number is different from H.323 Side for audio, the MG will send a
     Notify to

Internet draft              MEGACO Protocol             January 27, 2000

     control port number. In this case it is 1111 (in the MGC

21.  The MGC will Add an Audio/RTP termination SDP).

     MG2 to the context.

22. MGC:
     MEGACO/1 [124.124.124.222]:55555
     Reply = 50003 {
        Context = 5000 {
           Add = A5556{
              Media {
                 Stream = 1 {
                     Local {
     v=0
     c=IN IP4 125.125.125.111
     m=audio 1111 RTP/AVP 4
     }
                 } ; RTP profile for G723 is 4
              }
            }
        }
     }

18.  The MGC will send a Modify to the H.221 termination causing the
     H.221 mux to change above IPAddr and the selected audio channel (G.711, G.723
     etc.) UDPport need to be opened.  The H.320 side may do a mode switch to H.263
     video for example. The H.221 termination will then send a Notify given to
     the MGC requesting H.263 video.  The MG1 now.

     MGC will send an Add Video/RTP
     termination to the context and a MG1:
     MEGACO/1 [123.123.123.4]:55555
     Transaction = 10005 {
       Context = 2000 {
         Modify = A4444 {
           Signals {cg/rt}
         },
         Modify H.320/video = A4445 {
            Media {
                 Stream = 1 {
                     Remote {
     v=0
     c=IN IP4 125.125.125.111
     m=audio 1111 RTP/AVP 4
                     }
                 } ; RTP profile for G723 is 4
             }
         }
       }
     }

     MG1 to the context.

21.2.5.  Simple text telephone call MGC:
     MEGACO/1 [124.124.124.222]:55555
     Reply = 10005 {

Internet draft              MEGACO Protocol             January 27, 2000

        Context = 2000 {Modify = A4444, Modify = A4445}
     }

19.  The Simple Text Telephone Call flow example describes a call that ori-
ginates in a Text Telephone in the SCN two gateways are now connected and is terminated in an H.323
Annex G Text Conversation capable terminal in User 1 hears the packet network. RingBack.
     The
purpose of MG2 now waits until User2 picks up the example receiver and then the
     two-way call is established.

     From MG2 to describe MG/MGC interactions. The SGW sends
a Setup message to the MGC:

     MEGACO/1 [125.125.125.111]:55555
     Transaction = 50005 {
        Context = 5000 {
            Notify = A5555 {ObservedEvents =1234 {
              19990729T22020002:al/of}}
        }
     }

     From MGC after receiving an IAM from an SCN switch.

2. to MG2:

     MEGACO/1 [123.123.123.4]:55555
     Reply = 50005 {
         Context = - {Notify = A5555}
     }

     From the IAM message, the MGC may infer which circuit to MG2:

     MEGACO/1 [123.123.123.4]:55555
     Transaction = 50006 {
        Context = 5000 {
           Modify = A5555 {
              Events = 1235 {al/on},
              Signals { } ; to turn off ringing
           }
        }
     }

     From MG2 to MGC:

     MEGACO/1 [125.125.125.111]:55555
     Reply = 50006 {
      Context = 5000 {Modify = A4445}
     }

20.  Change mode on which MG
     is involved and where MG1 to terminate SendReceive, and stop the call.

3.   The ringback.

Internet draft              MEGACO Protocol             January 27, 2000

     MGC creates a to MG1:
     MEGACO/1 [123.123.123.4]:55555
     Transaction = 10006 {
        Context for the call.  The = 2000 {
           Modify = A4445 {
              Media {
                 Stream = 1 {
                    LocalControl {
                       Mode=SendReceive
                    }
                 }
              }
           },
           Modify = A4444 {
              Signals { }
           }
        }
     }

     from MG1 to MGC:
     MEGACO/1 [124.124.124.222]:55555
     Reply = 10006 {
        Context contains two
     terminations: one for = 2000 {Modify = A4445, Modify = A4444}}

21.  The MGC decides to Audit the SCN side and one for RTP termination on MG2.

     MEGACO/1 [123.123.123.4]:55555
     Transaction = 50007 {
        Context = - {AuditValue = A5556{
           Audit{Media, DigitMap, Events, Signals, Packages, Statistics }}
        }
     }

22.  The MG2 replies. An RTP termination has no events nor signals, so
     these are left out in the packet side:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction reply .

     MEGACO/1 [125.125.125.111]:55555
     Reply = 50003 50007 {
        Context = $ - {
                    Add
            AuditValue = DS0/12/2 A5556 {
               Media {
                  Stream = 1212 1 {
                      LocalControl { Mode = ReceiveOnly,
                                  Package1/VoiceActivityDet=No,
                                  Package1/PreferredCodecs=T140},
                                Local= SDP {c=LOCAL
                                            m=text 0 LOCAL 0 SendReceive,
                         nt/jit=40 },

Internet draft              MEGACO Protocol           September 21, 1999

                                }
                              }
                       },
                      Modem=V18,
                      Signals {Package_texttel/signal1 {name1=value1}}
                    },
                    Add  = $ {
                      Media { Stream = 1212 {
                                LocalControl             January 27, 2000

                      Local {
                                  Mode = ReceiveOnly,
                                  Package1/PreferredCodecs=T140
                                },
                                Local= SDP {c=IN
     v=0
     c=IN IP4 ANY
                                            m=text ANY 125.125.125.111
     m=audio 1111 RTP/AVP 0 95
                                            a=rtpmap:95 T140  4
     a=ptime:30
                     },
                                Remote= SDP {c=IN
                      Remote {
     v=0
     c=IN IP4 ANY
                                             m=text ANY 124.124.124.222
     m=audio 2222 RTP/AVP 0 95
                                             a=rtpmap:95 T140  4
     a=ptime:30
                      } } },
               Packages {nt-1, rtp-1},
               Statistics { rtp/ps=1200,  ; packets sent
                            nt/os=62300, ; octets sent
                            rtp/pr=700, ; packets received
                            nt/or=45100, ; octets received
                            rtp/pl=0.2,  ; % packet loss
                            rtp/jit=20,
                            rtp/delay=40 } ; avg latency
            }
         }
     }

             This is acknowledged:

23.  When the MG creates MGC receives an onhook signal from one of the context and returns info.

             MEGACO/1.0 [124.124.124.222]:55555
             Reply MGs, it
     brings down the call. In this example, the user at MG2 hangs up
     first.

     From MG2 to MGC:

     MEGACO/1 [125.125.125.111]:55555
     Transaction = 50003 50008 {
        Context = 5000 {Add,
                                Add = A5556 {
                                   Media {
                                       Stream
            Notify = 1212 A5555 {ObservedEvents =1235 {
                                          Local = SDP {c=IN IP4 111.1.1.1
                                            m=text 1111 RTP/AVP 0 95
                                            a=rtpmap:95 T140}
               19990729T24020002:al/on}
            }
        }
     }
                }
             }

2.   The

     From MGC sends a Setup message to the destination endpoint, here
     assumed to be a H.323 endpoint (terminal, GW, ...).  It indicates
     in the fastStart element that a reliable data channel shall be used
     and T.140 shall be used as the applicationCapability of the Data MG2:

     MEGACO/1 [123.123.123.4]:55555
     Reply = 50008 {
         Context = - {Notify = A5555}
     }

Internet draft              MEGACO Protocol           September 21, 1999

     stream.

3.             January 27, 2000

24.  The H.323 endpoint MGC now sends an Alerting message back both MGs a Subtract to take down the MGC,
     informing it of call. Only
     the data stream subtracts to be used and the transport
     address.

4.   The MG2 are shown here. Each termination has its own
     set of statistics that it gathers. An MGC sends a Modify command may not need to the MG request
     both to set the mode be returned. A5555 is a physical termination, and remote
     termination description on the packet side:

             MEGACO/1.0 [124.124.124.121:]55566 A5556 is
     an RTP termination.

     From MGC to MG2:

     MEGACO/1 [123.123.123.4]:55555
     Transaction = 50004 50009 {
        Context = 2000 5000 {
                   Modify
           Subtract = A5555 {Audit{Statistics}},
           Subtract = A5556 {Audit{Statistics}}
        }
     }

     From MG2 to MGC:

     MEGACO/1 [125.125.125.111]:55555
     Reply = 50009 {
                      Media
        Context = 5000 {
                         Stream
          Subtract = 1212 A5555 {
                             LocalControl
               Statistics {
                               Mode = SendReceive
                  nt/os=45123, ; Octets Sent
                  nt/dur=40 ; in seconds
                  }
            },
                             Remote
            Subtract = SDP {c=IN IP4 222.2.2.2
                                           m=text 2222 RTP/AVP 0 95
                                           a=rtpmap:95 T140
                             }
                         }
                      } A5556 {
               Statistics {
                  rtp/ps=1245, ; packets sent
                  nt/os=62345, ; octets sent
                  rtp/pr=780, ; packets received
                  nt/or=45123, ; octets received
                  rtp/pl=10, ;  % packets lost
                  rtp/jit=27,
                  rtp/delay=48 ; average latency
               }
            }
        }

             The MG accepts the Modify commands with this reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50004 {
                Context = 2000 {Modify}
     }

5.

25.  The MGC sends an Alerting message now sets up both MG1 and MG2 to be ready to detect the SGW.

6.   The called endpoint at some instance sends next
     off-hook event. See step 1. Note that this could be the default
     state of a Connect message to termination in the
     MGC.

7.   In response to null context, and if this were the Connect,
     case, no message need be sent from the MGC sends a Modify command to the
     MG MG. Once a termi-
     nation returns to change the mode of the SCN side termination null context, it goes back to SendRecv:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 50005 {
                Context = 2000 {
                   Modify = DS0/12/2 { the default

Internet draft              MEGACO Protocol           September 21, 1999

                      Media {
                         Stream = 1212 {
                             LocalControl {
                               Mode = SendReceive
                             }
                         }
                      }
                   }
                }
             }

8.   The MGC sends a Connect message to the SGW

9.   The MG accepts the Modify command with this reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50005 {
                Context =             January 27, 2000 {Modify}
             }

21.2.5.1.  Basic operation

21.2.5.2.  Voice channels in the simple text only case

21.2.5.3.  Operation with the alternating text and voice case

     termination values for that termination.