[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 2885

Internet Engineering Task Force                          Fernando Cuervo
INTERNET DRAFT                                           Nortel Networks
September 21, 1999                                            Bryan Hill
Expires March 21, 2000                                   Gotham Networks
<draft-ietf-megaco-protocol-04.txt>                         Nancy Greene
                                                         Nortel Networks
                                                       Christian Huitema
                                                  Telcordia Technologies
                                                         Abdallah Rayhan
                                                         Nortel Networks
                                                             Brian Rosen
                                                            FORE Systems
                                                             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 to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This document will expire in March 2000.









Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 1]


Internet draft              MEGACO Protocol           September 21, 1999


                           Table of Contents

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 2]


Internet draft              MEGACO Protocol           September 21, 1999


8.  TRANSACTIONS .............................................. 38
   8.1.  Common Parameters .................................... 39
      8.1.1.  Transaction Identifiers ......................... 39
      8.1.2.  Context Identifiers ............................. 39
   8.2.  Transaction Application Programming Interface ........ 39
      8.2.1.  TransactionRequest .............................. 40
      8.2.2.  TransactionReply ................................ 40
      8.2.3.  TransactionPending .............................. 41
   8.3.  Messages ............................................. 41
9.  TRANSPORT ................................................. 42
10.  SECURITY CONSIDERATIONS .................................. 42
   10.1.  Protection of Protocol Connections .................. 42
   10.2.  Interim AH-within-MEGACO/H.248 scheme ............... 43
   10.3.  Protection of Media Connections ..................... 44
11.  MG-MGC CONTROL INTERFACE ................................. 44
   11.1.  Multiple Virtual MGs ................................ 45
   11.2.  Cold Start .......................................... 45
   11.3.  Failure of an MG .................................... 46
   11.4.  Failure of an MGC ................................... 46
12.  PACKAGE DEFINITION ....................................... 47
   12.1.  Guidelines for defining packages .................... 47
   12.2.  Example Package ..................................... 48
   12.3.  Package Registration ................................ 52
13.  IANA CONSIDERATIONS ...................................... 52
   13.1.  Packages ............................................ 52
   13.2.  Error Codes ......................................... 53
14.  CONTACT INFORMATION ...................................... 53
ANNEX A - ASN.1 DESCRIPTION OF THE PROTOCOL (NORMATIVE) ....... 54
   A.1.   Specification language .............................. 54
   A.2.   Syntax specification ................................ 54
ANNEX B - TEXT ENCODING OF THE PROTOCOL (NORMATIVE) ........... 55
   B.1.   Translation Mechanism ............................... 55
   B.2.   ABNF specification .................................. 55
ANNEX C - BINARY ENCODING OF THE PROTOCOL ..................... 65
   C.1.   Translation mechanism ............................... 65
ANNEX D - TAGS FOR MEDIA STREAM PROPERTIES .................... 66
   D.1.   General Media Attributes ............................ 66
   D.2.   Multiplex properties ................................ 66
   D.3.   Properties for BearerDescriptor ..................... 67
   D.4.   For DS0 ............................................. 67
   D.5.   For ATM VC .......................................... 67
   D.6.   Frame Relay ......................................... 67
   D.7.   RTP Stream .......................................... 67
Annex E - TRANSPORT USING UDP AND APPLICATION LAYER FRAMING ... 68
   E.1.   Providing At-Most-Once functionality ................ 68
   E.2.   Transaction identifiers and three-way handshake ..... 69
   E.3.   Computing retransmission timers ..................... 69
   E.4.   Provisional responses Executing some transactions ... 70



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 3]


Internet draft              MEGACO Protocol           September 21, 1999


   E.5.   Ordering of commands ................................ 73
   E.6.   Fighting the restart avalanche ...................... 74
ANNEX F - TRANSPORT USING TCP ................................. 75
   F.1.   Providing the At-Most-Once functionality ............ 75
   F.2.   Transaction identifiers and three way handshake ..... 76
   F.3.   Computing retransmission timers ..................... 76
   F.4.   Provisional responses ............................... 76
   F.5.   Ordering of commands ................................ 76
   F.6.   Fighting the restart avalanche ...................... 77
ANNEX G EXAMPLE CALL FLOWS .................................... 77
   G.1.   Residential Gateway to Residential Gateway Call ..... 77
      G.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






























Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 4]


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 and Commands ..................... 38
Figure 6 H.320 Gateway Context .................................. 89
Figure 7 Multimedia Context Example ............................. 97
Figure 8 Single Media Call Example .............................. 98









































Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 5]


Internet draft              MEGACO Protocol           September 21, 1999


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 systems, including
tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of these
signaling 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

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

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

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

ITU-T 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"

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 1997.

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 6]


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

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

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.

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.

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.




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 7]


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 and perform other IVR functions, or may perform media con-
ferencing.

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 line to a
packet network. A residential gateway typically contains one or two ana-
log lines and is located at the customer premises.

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

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

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

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

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






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 8]


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
DTMF    Dual Tone Multi Frequency
FAS     Facility Associated Signaling
GK      GateKeeper
GW      GateWay
IP      Internet Protocol
ISUP    ISDN User Part
MG      Media Gateway
MGC     Media Gateway Controller
NAS     Network Access Server
NFAS    Non Facility Associated Signaling
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 Gateway
SS7     Signalling System No7

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 conference, a Termination can be multimedia and sources or sinks
multiple media streams.  The media stream parameters, as well as modem,
and bearer parameters are encapsulated within the Termination.

A Context is an association between a collection of Terminations. There
is a special type of Context, the null Context, which contains all 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.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers            [Page 9]


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.

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




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 10]


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




















Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 11]


Internet draft              MEGACO Protocol           September 21, 1999



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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 12]


Internet draft              MEGACO Protocol           September 21, 1999


conferences might allow three or more terminations per Context.

6.1.1.  Context Properties and Descriptors

The properties of Contexts include

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

*    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 (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 used to (implicitly) create Contexts and modify the
parameter values of existing Contexts.  The protocol has commands to add
Terminations to Contexts subtract them from Contexts, and to move Termi-
nations between Contexts.  Contexts are deleted implicitly when the last
remaining Termination is subtracted from it.

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 to or Subtract'ed from a Context, it is taken from
or to the null Context, respectively.

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.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 13]


Internet draft              MEGACO Protocol           September 21, 1999


Statistics are reported to the MGC upon request (by means of the Audit-
Value command, see Section 7.2.5) and when the Termination is taken out
of the call it is in.

Multimedia gateways may process multiplexed media streams.  For example,
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 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. The media streams can be associated with
streams sourced/sunk by other Terminations in the Context.

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.

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 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).  For example, if there were TerminationIDs of
R13/3/1, R13/3/2 and R13/3/3, the TerminationID R13/3/* would match all
of them.  There are some circumstances where ALL Terminations must be
referred to.  The TerminationID "*" suffices, and is referred to as
"ALL".  When a TerminationID is required, but the Termination does not
yet exist, the "CHOOSE" TerminationID "$" may be used.

6.2.3.  Packages

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 14]


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 12.  An
MGC can audit a Termination to determine which Packages it realizes.

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.

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

Properties not included in the base protocol are defined in Packages.
These properties are referred to by a name consisting of the PackageName
and a PropertyID.  Most properties have default values described in the
Package description. Actual or allowed values of properties can be set
and inspected by MGCs.  Related properties are grouped into descriptors
for convenience.

When a Termination is Added to a Context, its property values can be set
by including the appropriate descriptors as parameters to the Add com-
mand.  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 Termination is Subtracted from a Context, properties are reset to
the values they had just prior to the most recent Add command.

The following table lists all of the possible Descriptors and their use.
Not all descriptors are legal as input or output parameters to every
command.  Descriptors







Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 15]


Internet draft              MEGACO Protocol           September 21, 1999


______________________________________________________________________________
|Descriptor Name|  Description                                               |
|_______________|____________________________________________________________|
|Modem          |  Identifies modem type and properties when applicable      |
|_______________|____________________________________________________________|
|Mux            |  Describes multiplex type for multimedia terminations      |
|               |   (e.g. H.221, H.223, H.225.0) and Terminations forming    |
|               |    input mux                                               |
|_______________|____________________________________________________________|
|Media          |  A list of media stream specifications (see below)         |
|_______________|____________________________________________________________|
|Events         |  Describes events to be listened for by the MG and what to |
|               |   do when an event is detected                             |
|_______________|____________________________________________________________|
|Signals        |  Describes signals and/or actions to be applied (e.g.      |
|               |   ringback)                                                |
|_______________|____________________________________________________________|
|Requested Info |  In Audit, identifies which information is desired         |    |_______________|____________________________________________________________|
|Packages       |  In Audit, returns a list of Packages realized by          |
|               |  Termination                                               |
|_______________|____________________________________________________________|
|DigitMap       |  Instructions for handling DTMF tones at the MG            | |_______________|____________________________________________________________|
|ServiceChange  |  In ServiceChange, what, why, etc.                         |
|_______________|____________________________________________________________|
|ObservedEvents |  In Notify, report of events observed                      | |_______________|____________________________________________________________|
|Statistics     |  In Subtract and Audit, Report of Statistics kept on a     |
|               |    Termination                                             |
|_______________|____________________________________________________________|
|Extension      |  Allows inclusion of vendor-specific extensions            |
|_______________|____________________________________________________________|


Within the Media descriptor, there is the Termination State descriptor
and one or more Stream Descriptors.  A stream is identified by a
streamID.  The streamID is used 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 a
termination within it.  A special TerminationID, "ROOT" is reserved for
this purpose.  A package (MG) defines the properties of Root.  Root thus



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 16]


Internet draft              MEGACO Protocol           September 21, 1999


may have properties and events (signals and statistics are not appropri-
ate for root).  Accordingly, the root terminationID may appear in:

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

*    a Notify command - to report an event

*    an AuditValue return - to examine the values of properties

*    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 is an error.

7.  COMMANDS

The protocol provides 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 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 are sent to the MG by the MGC,
except Notify. Notify is sent to the MGC by the MG.  ServiceChange may
be sent by either entity to the other.

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 17]


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 command returns the current state of proper-
     ties, events and signals of Terminations.

6.   AuditCapabilities. The AuditCapabilities command returns all the
     possible values for Termination properties, events and signals
     allowed by the Media 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
     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.

These commands are detailed in 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.  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.





Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 18]


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 DescriptorName=<someID>{parm=value,
parm=value....}

Properties may be fully specified, overspecified 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" value, allow the
     command 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, mandatory parameters (i.e.-mandatory parameters not speci-
fied in any descriptor) result in the command responder retaining the
previous value for that property.

7.1.3.  Modem Descriptor

The Modem descriptor specifies the modem type and parameters, if any.

By default, no modem descriptor is present in a Termination.

7.1.4.  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.

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




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 19]


Internet draft              MEGACO Protocol           September 21, 1999


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

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

7.1.5.  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

The Termination State Descriptor contains the TerminationBuffered param-
eter, the serviceStates parameter and properties of a termination
(defined in Packages) that are not stream specific.

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

1.   BufferedEventProcessingMode - specifies whether buffered events
     should be processed or discarded.

2.   BufferedEventNotificationMode - specifies whether the Media Gateway
     is expected to detect the requested event and notify the controller
     once (step by step) or repeatedly.

The serviceStates parameter describes the overall state of the termina-
tion (not stream-specific). A Termination can be in one of the following
states: "test", "out of service", or "in service". "in service" is the
default state.

7.1.7.  Stream Descriptor

A Stream descriptor specifies the parameters of a single bi-directional
media stream.  These parameters are structured into three descriptors,
one that contains termination properties specific to a stream, and one
each for local and remote flows. Stream Descriptor











Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 20]


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 between the |
|                       | MG and the MGC                                       |
|_______________________|______________________________________________________|
|   Local Descriptor    | Contains properties that specify the Local side of a |
|                       | media flow, and are of interest between two MGs      |
|_______________________|______________________________________________________|
|   Remote Descriptor   | Contains properties that specify the Remote side of  |
|                       | a media flow, and are of interest between two MGs    |
|_______________________|______________________________________________________|


7.1.8.  LocalControl Descriptor

The LocalControl Descriptor contains the Mode parameter and properties
of a termination (defined in Packages) that are stream specific, and are
of interest between the MG and the MGC.

The allowed values for the mode parameter are "send only" (sendonly),
"receive only" (recvonly), "send/receive" (sendrecv),  "inactive" (inac-
tive), "loop back" (looback) and "delete" (delete).  "Send" and
"Receive" are with respect to the stream within a termination, so that,
for example, a stream set to mode=sendonly can talk but it cannot
listen.

Mode set to delete is used to remove a stream from a termination.


7.1.9.  Local and Remote Descriptors

The Local and Remote Descriptors contain the parameters describing the
flows sent to and received from the MG, and are of interest between two
MGs.  They are encoded as SDP strings as specified in RFC2327, or tag-
value pairs as specified in Annex D.  Local is the capability of the
local MG and is typically sent from MG to MGC, and subsequently used as
part of a capability negotiation between two MGCs.  Remote is the param-
eters describing the flows the remote MG will send/receive, is typically
sent from MCG to MG, and is the result of 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 a nego-
tiated version of MG A's Local Descriptor as its Remote Descriptor.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 21]


Internet draft              MEGACO Protocol           September 21, 1999


7.1.10.  Events Descriptor

The EventsDescriptor parameter contains a RequestIdentifier and a list
of events that the Media Gateway is requested to detect and report.  The
RequestIdentifier is used to correlate the request with the notifica-
tions that it may trigger.  Requested events include, for example, fax
tones, continuity tones, and on-hook and off-hook transitions.

Each event in the descriptor contains the Event name, an optional
Action, and optional parameters.  The Event name consists of a Package
Name (where the event is defined) and an EventID.  Events can have
parameters.  This allows a single event description to have some varia-
tion in meaning without creating large numbers of individual events.
Parameters are defined in the package and are named.  The Action parame-
ter specifies one of several possible actions to take upon the
occurrence of the event:

                            Event Actions
 ______________________________________________________________________________
|NotifyAction        | A Notify message is sent by the MG when the Event is    |
|                    | detected                                                |
|____________________|_________________________________________________________|
|AccumulateByValue   | The Event is added to the Event Buffer                  |
|____________________|_________________________________________________________|
|AccumulateByDigitMap| The Event is processed by the specified Digit Map       |
|____________________|_________________________________________________________|


When Accumulate by Digit Map is specified in an Action, a Digit Map or
the name of a pre- stored DigitMap is specified with 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 that the dial-tone Signal be stopped when a digit is
detected.  If no embedded Signals descriptor is specified, the produc-
tion of Signals continues as specified in the command.

Only 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.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 22]


Internet draft              MEGACO Protocol           September 21, 1999


7.1.11.  Signals Descriptor

A SignalsDescriptor is a parameter that contains the set of signals that
the Media Gateway is asked to apply to a Termination.  Signals are named
with a Package name (where the signal is defined) and a SignalID.

There are three types of signals:

*    on/off - the signal lasts until it is turned off,

*    timeout - the signal lasts until it is turned off or a specific
     period of time elapses,

*    brief - the signal duration is so short that it will stop on its
     own unless a new signal is applied that causes it to stop; no
     timeout value is needed.

Signals can have parameters.  This allows a single signal description to
have some variation in meaning without creating large numbers of indivi-
dual signals.  A common use for this capability is to produce signals
such as dialtone that have national variants.

     Signal{ Line/Dialtone{US} }

A new SignalDescriptor replaces any existing SignalDescriptor.  Any sig-
nals applied to the Termination not 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 the
list of descriptors to be returned from the Audit command.  Possible
items in the RequestedInfo Descriptor are:

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 23]


Internet draft              MEGACO Protocol           September 21, 1999


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


7.1.13.  ServiceChange Descriptor

The ServiceChangeDescriptor contains the following parameters:

*    ServiceChangeMethod

*    ServiceChangeReason

*    Port

*    Delay

*    Version

*    MGCIdToTry


7.1.14.  DigitMap Descriptor

A DigitMap is a dialing plan resident in the Media Gateway used for
detecting and reporting digit events received on a Termination.  The
DigitMap Descriptor contains a DigitMap name and the DigitMap to be
assigned.  A digit map may be preloaded into the MG by management action
and referenced by name in an EventDescriptor, may be defined dynamically
and subsequently referenced by name, or the actual digitmap itself may
be specified in the EventDescriptor.

DigitMaps defined in a DigitMapDescriptor can occur in any of the stan-
dard Termination manipulation Commands of the protocol.  A DigitMap,
once defined, can be used on all Terminations specified by the (possibly
wildcarded) TerminationID in such a command.  When a DigitMap is defined
dynamically in a DigitMap Descriptor:

*    A new DigitMap is created by specifying a name that is not yet
     defined.  The value shall be present.

*    A DigitMap value is updated by supplying a new value for a name
     that is already defined.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 24]


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 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 the Media Gateway can determine that at least one more digit is
     needed for a digit string to match any of the allowed patterns in
     the digit map, then the interdigit timer value should be set to a
     long duration (e.g.-16 seconds).

3.   If the DigitMap specifies that a variable number of additional
     digits may be needed then the short timer is used.

The timers are configurable parameters to a DigitMap.

The formal syntax of the digit map is described by the DigitMap rule in
the formal syntax description of the protocol (See Annex A and Annex B).
A DigitMap, according to this syntax, is defined either by a string or
by a list of strings. Each string in the list is an alternative 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 the event parameter to the end of an internal state variable
     called the "current dial string"

2.   Apply the current dial string to the DigitMap, attempting a 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 match), send the current dial string to
     the MGC.

Note that unexpected timers, for example, can cause over-qualified
matches.

7.1.15.  Statistics Descriptor

The Statistics parameter provides information describing the status and
usage of a Termination during its existence within a specific Context.
There is a set of standard statistics kept for each termination where
appropriate (number of octets sent and received for example).  The



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 25]


Internet draft              MEGACO Protocol           September 21, 1999


particular statistical properties that are reported for a given Termina-
tion are determined by the Packages realized by the Termination.
Statistics are reported when the Termination is Subtracted from the Con-
text.  Statistics may also be returned from the AuditValue command.

7.1.16.  Topology Descriptor

A topology descriptor is used specify flow directions between termina-
tions in a conference. Contrary to the descriptors in previous sections,
the topology descriptor applies to a Context instead of a Termination.
The default topology of a Context is that is that each termination's
transmission is received by all other terminations.  The Topology
Descriptor optional to implement.

A topology descriptor consists of a sequence of  triples of the form
(T1, T2, association). T1 and T2 specify Terminations within the Con-
text, possibly using the ALL wildcard.  The association specifies how
media flows between these to Terminations as follows.

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

*    (T1, T2, oneway) means that the Terminations that match T2 receive
     media from the Terminations matching T1, but not vice versa.  In
     this case it is not allowed to use wildcards such that there are
     Terminations that match both T1 and T2.

*    (T1, T2, bothway) means that the Terminations matching T2 receive
     media from the Terminations matching T1, and vice versa.  In this
     case it is allowed to use wildcards such that there are Termina-
     tions that match both T1 and T2.  However, if there is a Termina-
     tion that matches both, no loopback is introduced; loopbacks are
     created by setting the TerminationMode.

The Figure below and the Table following it show some examples of the
effect of including topology descriptors in commands.















Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 26]


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
















Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 27]


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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 28]


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 to the context as
if individual Add commands listing the Terminations were invoked.

The EventsDescriptor parameter is optional.  If present, it provides the
list of events that should be detected on the Termination.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 29]


Internet draft              MEGACO Protocol           September 21, 1999


The SignalsDescriptor parameter is optional.  If present, it provides
the list of signals that should be applied to the Termination.

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

The AuditDescriptor is optional.  If present, the command will return
descriptors as specified in the AuditDescriptor.

7.2.2.  Modify

The Modify Command modifies the properties 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 the Context
is to be modified. Use of wildcards in the TerminationID may be
appropriate for some operations. If the wildcard matches more than one
TerminationID, all possible matches are attempted, with results reported
for each one.  The order of attempts when multiple TerminationIDs match
is not specified. The "choose" option is an error, as modify may only be
used on existing Terminations.

The remaining parameters to Modify are the same as those to Add.  The
Media Descriptor is optional for Modify.

7.2.3.  Subtract

The Subtract Command disconnects a Termination from its Context and



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 30]


Internet draft              MEGACO Protocol           September 21, 1999


returns statistics on the Termination's participation in the Context.

        [TerminationID]
        [,MediaDescriptor]
        [,ModemDescriptor]
        [,MuxDescriptor]
        [,EventsDescriptor]
        [,SignalsDescriptor]
        [,DigitMapDescriptor]
        [,ObservedEventsDescriptor]
        [,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 set of related) Terminations in the
Context of the Subtract Command are to be subtracted. If the wildcard
matches more than one TerminationID, all possible matches are attempted,
with results reported for each one.  The order of attempts when multiple
TerminationIDs match is not specified. The "choose" option is an error,
as subtract may only be used on existing Terminations.

The Statistics parameter is returned to report information collected on
the Termination or Terminations specified in the Command.  The informa-
tion reported applies to the Termination's or Terminations' existence in
the Context from which it or they are being subtracted.

The AuditDescriptor is optional.  If present, the command will return
descriptors as specified in the AuditDescriptor.

7.2.4.  Move

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

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 31]


Internet draft              MEGACO Protocol           September 21, 1999


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


The TerminationID specifies the Termination to be moved.  It may be
wildcarded.  If the wildcard matches more than one TerminationID, all
possible matches are attempted, with results reported for each one.  The
order of attempts when multiple TerminationIDs match is not specified.
By convention, the Termination is subtracted from its previous Context.

The remaining descriptors are processed as in the Modify Command.  The
AuditDescriptor with the Statistics option, for example, would return
statistics on the Termination just prior to the Move.

7.2.5.  AuditValue

The AuditValue Command returns the current values of properties, events,
signals and statistics associated with Terminations.

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


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

The appropriate descriptors, with the current values for the



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 32]


Internet draft              MEGACO Protocol           September 21, 1999


Termination, are returned from AuditValue.  ObservedEvents returns a
list of events in the EventBuffer (BufferedEventDescriptor returns Buf-
ferMode and ProcessingMode).  PackagesDescriptor returns a list of pack-
ages realized by the Termination.

AuditValue results depend on the Context, viz. Specific, null, or
unspecified.  The TerminationID may be specific, 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 a Context      |
|Null       |  Root         |  Audit of Media Gateway state and events         |
|Null       |  all          |  List of all Terminations in the Media Gateway   |
|Null       |  wildcard     |  List of all matching Terminations               |
|Null       |  specific     |  Audit of a single Termination in outside of any |
|           |                      Context                                     |
|Unspecified|  Root         |  Audit of Media Gateway state and events         |
|Unspecified|  all          |  List of all Terminations in the Media Gateway   |
|           |               |  and the Context(s) to which they are associated |
|Unspecified|  wildcard     |  List of all matching Terminations and the       |
|           |               |      Context to which they are associated        |
|___________|_______________|__________________________________________________|


7.2.6.  AuditCapabilities

The AuditCapabilities Command returns the possible values of properties,
events, signals and statistics associated with Terminations.

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


The appropriate descriptors, with the possible values for the Termina-
tion are returned from AuditCapabilities.  Descriptors may be repeated



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 33]


Internet draft              MEGACO Protocol           September 21, 1999


where there are multiple possible values.

Interpretation of what capabilities are requested for various values of
ContextID and TerminationID is the same as in AuditValue.

7.2.7.  Notify

The Notify Command allows the Media Gateway to notify the Media Gateway
Controller of events occurring within the Media Gateway.

                Notify(TerminationID,
                           ObservedEventsDescriptor)


The TerminationID parameter specifies the Termination issuing the Notify
Command.  The TerminationID shall be a fully qualified name.

The ObservedEventsDescriptor contains the RequestID and a list of events
that the Media Gateway detected in the order that they were detected.
The RequestID returns the RequestID parameter of the EventsDescriptor
that triggered the Notify Command.  It is used to correlate the notifi-
cation with the request that triggered it.  The events in the list must
have been requested via the RequestedEvents parameter of the triggering
EventsDescriptor.  The list must contain the events that were either
accumulated (but not notified) or treated according to digit map (but no
match found yet) and well as the final event that triggered the detec-
tion or provided a final match in the digit map.  Each event in the list
is accompanied by properties associated with the event and an indication
of the time that the event was detected.  Unsolicited Notify Commands
are not possible.

7.2.8.  ServiceChange

The ServiceChange Command allows the Media Gateway to notify the Media
Gateway Controller that a Termination or group of Terminations is about
to be taken out of service or has just been returned to service.  It
also allows a MGC to hand over control of a MG to another MGC.

        [ServiceChangeDescriptor]
              ServiceChange(TerminationID,
                            ServiceDescriptor
              )


The TerminationID parameter specifies the Termination(s) that are taken
out of or returned to service.  Wildcarding of Termination names is
quite useful here, with the exception that the "choose" mechanism shall
not be used.  Use of the "Root" TerminationID indicates a ServiceChange



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 34]


Internet draft              MEGACO Protocol           September 21, 1999


affecting the entire Media Gateway.

The ServiceDescriptor contains the following parameters:

*    ServiceChangeMethod

*    ServiceChangeReason

*    ServiceChangeDelay

*    Port

*    Profile

*    MGCIdToTry

The ServiceChangeMethod parameter specifies the type of ServiceChange
that will or has occurred:

1.   Graceful - indicates that the specified Terminations will be taken
     out of service after the specified ServiceChangeDelay; established
     connections are not yet affected, but the Media Gateway Controller
     should refrain from establishing new connections and should attempt
     to gracefully tear down existing connections IP P

2.   Forced - indicates that the specified Terminations were taken
     abruptly out of service and any established connections associated
     with them were lost

3.   Restart - indicates that service will be restored on the specified
     Terminations after expiration of the ServiceChangeDelay; the Termi-
     nations are assumed to now not be associated with any Context

4.   Disconnected - always applied with the Root TerminationID, indi-
     cates that the MG lost communication with the MGC, but it was sub-
     sequently restored.  Since MG state may have changed, the MGC may
     wish to use the Audit command to resynchronize its state with the
     MG's.

5.   Handoff - sent from the MGC to the MG, this reason indicates that
     the MGC is going out of service and a new MGC association must be
     established.

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

The optional Port parameter specifies the port number to be used for



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 35]


Internet draft              MEGACO Protocol           September 21, 1999


subsequent communications.  It can be specified in the input parameter
descriptor or the returned result descriptor.

The optional ServiceChangeDelay parameter is expressed in seconds.  If
the delay is absent or set to zero the delay value should be considered
to be null.  In the case of a "graceful" ServiceChangeMethod, a null
delay indicates that the Media Gateway Controller should wait for the
natural removal of existing connections and should not establish new
connections.  The ServiceChangeDelay is always considered null in the
case of the "forced" method.

The Profile parameter specifies the Profile (if any) of the protocol
supported.  The Profile includes the version of the profile supported.

A ServiceChange Command specifying the "Root" for the TerminationID is a
registration command by which a Media Gateway announces its existence to
the Media Gateway Controller. The Media Gateway is expected to be pro-
visioned with the 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 to be used by the MGC for sending messages in the Port parameter
in the input ServiceChangeDescriptor.  The MGC specifies the port number
for the MG to use in the returned result ServiceDescriptor.

The Media Gateway Controller may return a MGCIdToTry parameter that
describes the 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 Gateway specified in a MGCIdToTry, if provided, shall
be contacted before any further alternate MGCs.  On a HandOff message
from MGC to MG, the MGCIdToTry is the new MGC that will take over from
the current MGC.

7.2.9.  Generic Command Syntax

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

The protocol syntax is defined in Annex A.

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

The mechanism for binary encoding is specified in Annex C.





Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 36]


Internet draft              MEGACO Protocol           September 21, 1999


7.3.  Command Error Codes

Errors consist of an IANA registered alphanumeric token and an explana-
tory string.

The identified error codes are:

Note: we need to renumber the error codes.

400 - Bad Request
401 - Protocol Error
402 - Unauthorized
403 - Syntax Error in Transaction
410 - Incorrect identifier
411 - The transaction refers to an unknown ContextId
412 - No ContextIDs available
420 - No such Event or signal in this package
421 - Unknown action or illegal combination of actions
422 - Syntax Error in Action
430 - Unknown TerminationID
431 - No TerminationID matched a wildcard
432 - Out of TerminationIDs or No TerminationID available
433 - TerminationID is already in 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 in this command
446 - Descriptor appears twice in a command
450 - No such property in this package
451 - Parameter illegal in this Descriptor
453 - Parameter or Property appears twice 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 or invalid mode
518 - Out of space to store digit map
519 - Gateway does not have a digit map
520 - Termination is "ServiceChangeing"
526 - Insufficient bandwidth



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 37]


Internet draft              MEGACO Protocol           September 21, 1999


529 - Internal hardware failure"
581 - Does Not Exist


8.  TRANSACTIONS

Commands between the Media Gateway Controller and the Media Gateway are
grouped into Transactions, each of which is 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 other is where the controller
requests the gateway to create a new Context.  Following is a graphic
representation of the Transaction, Action and Command relationships.

          +----------------------------------------------------------+
          | Transaction x                                            |
          |  +----------------------------------------------------+  |
          |  | Action 1                                           |  |
          |  | +---------+  +---------+  +---------+  +---------+ |  |
          |  | | Command |  | Command |  | Command |  | Command | |  |
          |  | |    1    |  |    2    |  |    3    |  |    4    | |  |
          |  | +---------+  +---------+  +---------+  +---------+ |  |
          |  +----------------------------------------------------+  |
          |                                                          |
          |  +----------------------------------------------------+  |
          |  | Action 2                                           |  |
          |  | +---------+                                        |  |
          |  | | Command |                                        |  |
          |  | |    1    |                                        |  |
          |  | +---------+                                        |  |
          |  +----------------------------------------------------+  |
          |                                                          |
          |  +----------------------------------------------------+  |
          |  | Action 3                                           |  |
          |  | +---------+  +---------+  +---------+              |  |
          |  | | Command |  | Command |  | Command |              |  |
          |  | |    1    |  |    2    |  |    3    |              |  |
          |  | +---------+  +---------+  +---------+              |  |
          |  +----------------------------------------------------+  |
          +----------------------------------------------------------+
                  Figure 5 Transactions, Actions and Commands


Transactions are presented as TransactionRequests.  Corresponding
responses to a TransactionRequest are received in a single reply.  There



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 38]


Internet draft              MEGACO Protocol           September 21, 1999


are two types of replies, a TransactionReply, and a TransactionPending.

Transactions guarantee ordered Command processing.  That is, Commands
within a Transaction are executed sequentially. At the first failing
Command in a Transaction, processing of the remaining Commands in that
Transaction stops.  If a command contains a wildcarded terminationID,
each of the actual TerminatioIDs matching the wildcard is attempted.  A
response within 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 in an error when executed, any
commands following the wildcarded command are not attempted.

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.

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 Media
Gateway and is unique within the scope of the Media Gateway.  The Media
Gateway Controller shall use the ContextID supplied by the Media Gateway
in all subsequent Transactions relating to that Context.  The protocol
makes reference to two distinguished values that may be used by the
Media Gateway Controller when it has no ContextID to use in a Transac-
tion:

1.   The "null" Context, which is used to refer to a Termination that is
     currently not associated with a Context.

2.   The "unspecified" Context, which is used to request 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 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 39]


Internet draft              MEGACO Protocol           September 21, 1999


input parameters and return values expected to be used by the various
Transactions of the protocol from a very high level.  Transaction syntax
and encodings are specified in later subsections.

8.2.1.  TransactionRequest


The TransactionRequest is invoked by the sender.  There is one Transac-
tion per request invocation.  A request contains one or more Actions,
each of which specifies its target Context and one or more Commands per
Context.

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


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

The ContextID parameter must specify a value to pertain to all Commands
that follow up to either the next specification of a ContextID parameter
or the end of the TransactionRequest, whichever comes first.  The Con-
textID may be specific, unspecified, or null.

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 transaction. A reply contains one or more Actions, each
of which must specify its target 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.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 40]


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 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 a TransactionReply consisting of the Tran-
sactionID and a single error descriptor.

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

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 { } )

The TransactionID parameter must specify a keyword value for correlation
with the corresponding TransactionRequest from the sender.  A property
of root (normalMGExecutionTime) is settable by the MGC to indicate the
interval within which the MGC expects a response to any transaction from
the MG.  Another property (normalMGCExecutionTime) is settable by the
MGC to indicate the interval within which the MG should expects a
response to any transaction from the MGC.  Senders may receive more than
one TransactionPending for a command.

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 a major/minor version with one or two digits each.




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 41]


Internet draft              MEGACO Protocol           September 21, 1999


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.

The MG is provisioned with a DNS name or IP address of a primary and
zero or more secondary MGCs (see section 7.2.8) which is the address the
MG uses to send messages to the MGC.   The MGC receives the Servi-
ceChange message from the MG and can determine the MGs IP address.
Responses to commands are sent back to the source address of the com-
mands.  The initial ServiceChange message should be sent to port ???? if
using TCP and port ???? if using UDP. The ServiceChange command contains
a ServiceChangePort parameter.  The MG specifies the TCP/UDP port number
it wishes the MGC to use for communication.  The MGC replies with the
Port set to the TCP/UDP port number it wishes the MG to use for further
communications.

10.  SECURITY CONSIDERATIONS

10.1.  Protection of Protocol Connections

A security mechanism is clearly needed to prevent unauthorized entities
from using the MEGACO/H.248 protocol for setting up unauthorized calls
or interfering with authorized calls. The security mechanism for the
MEGACO/H.248 protocol 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 all the
above security services plus confidentiality of messages, if desired.
For instance, the ESP encryption service should be requested if the ses-
sion descriptions are used to carry session keys, as defined in SDP.

MEGACO/H.248 implementations employing the ESP header SHALL comply with
section 5 of [RFC2406], which defines a minimum set of algorithms for
integrity checking and encryption. Similarly, MEGACO/H.248 implementa-
tions employing the AH header SHALL comply with section 5 of [RFC2402],
which defines a minimum set of algorithms for integrity checking using
manual keys.

MEGACO/H.248 implementations SHOULD use IKE [RFC2409] to permit more
robust keying options. MEGACO/H.248 implementations employing IKE SHOULD
support authentication with RSA signatures and RSA public key



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 42]


Internet draft              MEGACO Protocol           September 21, 1999


encryption.

10.2.  Interim AH-within-MEGACO/H.248 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 MEGACO/H.248 protocol where the underlying network implementation
does not support IPsec.

As an interim solution, the MEGACO/H.248 protocol defines an optional AH
header within the MEGACO/H.248 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 "tran-
sport 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 functionality, 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 AH-within-
MEGACO/H.248 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/H.248 protocol SHALL implement IPsec where
the underlying operating system supports IPsec.  Implementations of the
MEGACO/H.248 protocol using IPv4 SHALL implement the interim AH-within-
MEGACO/H.248 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 AH-within- MEGACO/H.248
interim scheme.

All implementations of the AH-within-MEGACO/H.248 interim mechanism
SHALL comply with section 5 of [RFC2402] which defines a minimum set 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 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 mis-
behaving MGCs. However, they will provide an identification of these
misbehaving entities, which should then be deprived of their authoriza-
tion through maintenance procedures.






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 43]


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






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 44]


Internet draft              MEGACO Protocol           September 21, 1999


11.1.  Multiple Virtual MGs

A virtual MG consists of a set of statically partitioned Terminations.
The model does not require that other resources be statically allocated,
just Terminations.  The mechanism for allocating Terminations to virtual
MGs is a management method outside the scope of the protocol.  Each of
the virtual MGs appears to the MGC as a complete MG client.

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

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

If recovering from the event requires manipulation of the interface
state, there can be only one MGC who can do so.  These issues are
resolved by allowing any of the MGCs to create EventDescriptors to be
notified 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 is used to designate which MGC has read/write
capability, and is designated the Master MGC.

Each virtual MG has its own Root Termination.  In most cases the values
for the properties of the Root Termination are independently settable by
each MGC.  Where there can only be one value, the parameter is read-only
to all but the Master MGC.

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 Secon-
dary MGCs.  Upon a cold start of the MG, it will issue a ServiceChange
command with a "Restart" method, on the Root Termination to its primary
MGC.  If the MGC accepts the MG, it will send a Transaction Accept, with
the MGCIdToTry set to itself.  If the MG receives a MGCIdToTry not equal
to the MGC it contacted, it sends a ServiceChange to the MGC specified
in 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 the Primary MGC, or a designated
successor, the MG tries it's pre-provisioned Secondary MGCs, in order.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 45]


Internet draft              MEGACO Protocol           September 21, 1999


11.3.  Failure of an MG

If a MG fails, but is capable of sending a message to the MGC, it sends
a ServiceChange with an appropriate method (graceful or forced) and
specifies the Root TerminationID.  When it returns to service, it sends
a ServiceChange with a "Restart" method.

Allowing the MGC to send duplicate messages to both MGs accommodates
pairs of MGs that are capable of redundant failover of one of the MGs.
Only the Working MG shall accept or reject transactions.  Upon failover,
the Primary MG sends a ServiceChange command with a "Failover" method
and a "Failed MG" reason.  The MGC then uses the primary MG as the
active MG.  When the error condition is repaired, the Working MG can
send a "ServiceChange" with a "Restart" method.

11.4.  Failure of an MGC

If the MG detects a failure of it's controlling MGC, it attempts to con-
tact the next MGC on its pre-provisioned list.  It starts it's attempts
at the beginning (Primary MGC), unless that was the MGC that failed, in
which case it starts at it's first Secondary MGC.  It sends a Servi-
ceChange message 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 MG 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, it should behave as if it's MGC failed, and start
contacting secondary MGCs.

When the MGC initiates a HandOff, the handover should be transparent to
Operations on the Media Gateway.  Commands in progress continue, tran-
saction replies are sent to the new MGC, and the MG should expect out-
standing transaction replies from the new MGC.  All connections should
stay up.

It is possible that the MGC could be implemented in such a way that a
failed MGC is replaced by a working MGC where the identity of the new
MGC is the same as the failed one.  In such a case, MGCIdToTry would be
specified with the previous value.  In such a case, the MG shall behave
as if the value was changed, and send a ServiceChange message, as above.

failover by the above mechanism.






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 46]


Internet draft              MEGACO Protocol           September 21, 1999


12.  PACKAGE DEFINITION

The primary mechanism for extension is by means of Packages.  Packages
define additional Properties, Events, Signals and Statistics that may
occur on Terminations.

Packages defined by IETF will appear in separate RFCs.

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

Packages defined by ITU-T will be described in Annexes to H.248.

12.1.  Guidelines for defining packages

Packages define properties, events, signals and statistics.  Names of
all such defined constructs shall consist of the ID of the package, the
character "/" and the ID of the item, for example, "tone/ring".  A Pack-
age shall contain the following sections:

1.   Full Package name, PackageID, and description.  PackageIDs shall be
     a string of up to 64 characters, containing no spaces, and consist-
     ing of alphas and digits, and possibly including the special char-
     acter underscore ("_").  The PackageID is used in a TerminationSta-
     teDescriptor, or the LocalControl Descriptor, for example,
     "tone/dialtone" specifies a signal "dialtone" in the package
     "tone".  The Package name is descriptive only.

2.   Properties defined by the package, specifying a Property name, Pro-
     pertyID, possible values, and description.  PropertyID shall be a
     string of up to 64 characters, containing no spaces, and consisting
     of alphas and digits, and possibly including the special character
     underscore ("_"). The PropertyID is used in a TerminationSta-
     teDescriptor, or the LocalControl Descriptor.  For example
     "foo/color" specifies the "color" property defined in 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, and consisting of alphas and
     digits, and possibly including the special character underscore
     ("_").  EventIDs and PropertyIDs are used in an Event Descriptor.
     For example "line/offhook" specifies the "offhook" event defined in
     the "line" package.  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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 47]


Internet draft              MEGACO Protocol           September 21, 1999


     parameter. SignalID and ParameterIDs shall be a string of up to 64
     characters, containing no spaces, and consisting of alphas and
     digits, and possibly including the special character underscore
     ("_"). SignalID and PropertyIDs are used in a Signal Descriptor.
     The Signal name is descriptive only.

5.   Statistics defined by the package, specifying a Statistic name,
     StatisticID, units, and description. StatisticID shall be a string
     of up to 64 characters, containing no spaces, and consisting of
     alphas and digits, and possibly including the special character
     underscore ("_"). The StatisticID is used in 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 to detect and generate tones
          on 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 from ITU??????

Section 3. Events

          3.1 ToneDetected

               EventID: tonedt

               Parameters:

                    3.1.2 Stream ID

                         ParameterID: streamid

                         Direction: IN

                         Possible Values: Integer in the range of 0-256




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 48]


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




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 49]


Internet draft              MEGACO Protocol           September 21, 1999


                         Possible Values: Integer (32 bit)

                         Description:  When eventtype is END, the length
                         of the tone detected

               Description: Detects a DTMF tone.  Reports stream and
               which tone was detected.

          3.2       SilenceDetected

               EventID: silencedt

               Parameters:

                    3.2.1 Stream ID

                         ParameterID: streamid

                         Direction: IN

                         Possible Values: Integer in the range of 0-256

                         Description: id 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 of silence has occurred.

Section 4. Signals

          4.1 Play Tones

               SignalID: playtone

               Parameters:

                    4.1.1 Stream ID



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 50]


Internet draft              MEGACO Protocol           September 21, 1999


                         ParameterID: streamid

                         Direction: IN

                         Possible Values: Integer in the range of 0-256

                         Description: id of audio stream 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 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 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 51]


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

The following considerations SHALL be met to register a package with
IANA:

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

2.   A public document or a standard forum document, which can be refer-
     enced as the document that describes the package following the
     guideline above, must be specified.  The document SHALL specify the
     version of the Package that it describes.

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

4.   The document should be available on a public web server and should
     have a stable url. The site should provide a mechanism to provide
     comments and appropriate responses should be returned.

The following package names are reserved

*    dtmf

*    generic

*    keypad

*

Packages registered by other than recognized standards bodies shall have
a minimum package name length of 8 characters

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






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 52]


Internet draft              MEGACO Protocol           September 21, 1999


13.2.  Error Codes

The following considerations SHALL be met to register an error code with
IANA:

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

2.   A complete description of the conditions under which the error is
     detected shall be included in a publicly available document.  The
     description shall be sufficiently clear to differentiate the error
     from all other existing error codes.

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

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

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

6.   An error number shall not be redefined, nor modified except by the
     organization or individual that originally defined it, or their
     successors or assigns.

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 53]


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 - ASN.1 DESCRIPTION OF THE PROTOCOL (NORMATIVE)

15.1.  Specification language

The baseline text for this section will be taken from APC-1608.

15.2.  Syntax specification

This section will contain the protocol syntax specification using the
language described in the previous section.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 54]


Internet draft              MEGACO Protocol           September 21, 1999


16.  ANNEX B - TEXT ENCODING OF THE PROTOCOL (NORMATIVE)

16.1.  Translation Mechanism

A future edition of this document will describe how the syntax of Annex
A is translated into ABNF.  This version contains hand-coded ABNF

16.2.  ABNF specification

The protocol syntax is presented in ABNF according 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 |
        1*(transactionRequest | 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 | subtractRequest | auditRequest |
                  notifyRequest | serviceChangeRequest)

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




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 55]


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 | MoveToken | ModifyToken ) EQUAL TerminationID
             [LBRKT ammParameter *(COMMA ammParameter) RBRKT]

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

ammsReply = ( AddToken | MoveToken | 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 |
             [EQUAL TerminationID] terminationAudit )

terminationAudit = LBRKT auditReturnParameter
                   *(COMMA auditReturnParameter) RBRKT

contextAudit = EQUAL CtxToken terminationIDList

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

auditDescriptor = AuditToken LBRKT auditItem  *(COMMA auditItem) RBRKT

notifyRequest = NotifyToken EQUAL TerminationID
               LBRKT observedEventsDescriptor RBRKT

notifyReply = NotifyToken ( commandError | [EQUAL TerminationID] )



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 56]


Internet draft              MEGACO Protocol           September 21, 1999


serviceChangeRequest = serviceChangeToken EQUAL TerminationID
                       LBRKT serviceChangeDescriptor RBRKT

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

errorDescriptor = ErrorToken EQUAL ErrorCode LBRKT quotedString RBRKT

ErrorCode = 1*3(DIGIT) ; could be extended

TransactionID = UINT32

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

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

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

domainAddress = "[" (IPv4address | IPv6address) "]"
;RFC2373 contains the definition of IP6Addresses.
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex
V4hex = 1*3(DIGIT) ; "0".."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 of pathNAME must not exceed 64 chars.
; "*" should not appear more than twice in pathNAME.
pathNAME = NAME *(["/"] ["*"] (ALPHA | DIGIT)) ["*"]

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

mediaDescriptor = mediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT

; at-most-once per item
; and either streamParm or streamDescriptor but not both
mediaParm = (streamParm | streamDescriptor |
terminationStateDescriptor)

; at-most-once



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 57]


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 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 per item
terminationStateParm =(terminationBuffered | propertyParm |
serviceStates)

serviceStates = ServiceStatesToken EQUAL ( TestToken |
                OutOfSvcToken | InSvcToken )

terminationBuffered = BufferedEventHandlingToken LBRKT
                      bufferedEventHandling [COMMA



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 58]


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




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 59]


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 )
digitString = 1*(digitStringElement)
digitStringElement = digitPosition [DOT]
digitPosition = digitMapLetter | digitMapRange



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 60]


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 is REQUIRED on first ServiceChange
;request&response
serviceChangeParm = (serviceChangeMethod | serviceChangeReason |
                   serviceChangeDelay | serviceChangePort |
                   serviceChangeProfile | extension |
                   serviceChangeMgcId )
serviceChangeMethod = MethodToken EQUAL (FailoverToken |
                ForcedToken | GracefulToken | RestartToken |
                DisconnectedToken | HandOffToken | extensionParameter)

;need some reasons!!!, or should it be 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 61]


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 is used to describe SDP defined in RFC2327.
; Caution should be taken if CRLF in RFC2327 is used.
; To be safe, use EOL in this ABNF.
; Whenever "}" appears in SDP, it is escaped by "
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 )



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 62]


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")



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 63]


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")






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 64]


Internet draft              MEGACO Protocol           September 21, 1999


17.  ANNEX C - BINARY ENCODING OF THE PROTOCOL

17.1.  Translation mechanism

This section will specify the mechanism for obtaining a binary encoding
from the syntax specification given in Annex A.  It will also contain a
compiler to generate binary encoded protocol messages according to this
mechanism.











































Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 65]


Internet draft              MEGACO Protocol           September 21, 1999


18.  ANNEX D - TAGS FOR MEDIA STREAM PROPERTIES

As an alternative to SDP, Remote and Local Descriptors may be specified
as a list of tag=value pairs.  The >, <, alternative options as speci-
fied in section ???? may be used.  The possible tag values are:

18.1.  General Media Attributes

Note that these attributes are not necessarily applicable to all codecs
or required for fully describe a particular codec's mode 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 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 be linked.

                 _____________________________________
                | Full Tag|  Short Tag|  Type|  Values|
                |_________|___________|______|________|
                | H.221   |           |      |        |
                |_________|___________|______|________|
                | H.223   |           |      |        |
                |_________|___________|______|________|
                | V.76    |           |      |        |
                |_________|___________|______|________|
                | H.2250  |           |      |        |
                |_________|___________|______|________|
                | Null    |           |      |        |
                |_________|___________|______|________|






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 66]


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 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 this the local and
remote side. Both will have the form of:






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 67]


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 by the other side (see section 7.2.8), the com-
mands should be sent to the default MEGACO port, ????.


19.1.  Providing At-Most-Once functionality

Messages, being carried over UDP, may be subject to losses. In the
absence of a timely response, commands are repeated. Most commands are
not idempotent.  The state of the MG would become unpredictable if, for
example, Add commands were executed several times.  The transmission
procedures shall thus provide an "At-Most-Once" functionality.

MECACO/Recommendation H.248 entities are expected to keep in memory a
list of the responses that they sent to recent transactions and a list
of the transactions that are currently outstanding. The transaction
identifiers of incoming messages are compared to the transaction iden-
tifiers of the recent responses. 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 the maximum
propagation delay of a packet in the network.  A suggested value is 30
seconds.

The copy of the responses may be destroyed either LONG-TIMER seconds
after the response is issued, or when the MG (or the MGC) receives a
confirmation that the response has been received, through the "Response
Acknowledgement parameter". For transactions that are acknowledged
through this parameter, the MG shall keep a copy of the transaction-id
for LONG-TIMER seconds after the response is issued, in order to detect
and ignore duplicate copies of the transaction response that could be
produced by the network.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 68]


Internet draft              MEGACO Protocol           September 21, 1999


19.2.  Transaction identifiers 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, or to use the same number space for all MGs that
belong to some arbitrary group.  MGCs may decide to share the load of
managing a large MG between several independent processes.  These
processes will share the same transaction number space.  There are 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 different processes.  The implemen-
tations shall guarantee that unique transaction identifiers are allo-
cated to all transactions that originate from a logical MGCs. MGs can
simply detect duplicate transactions by looking at the transaction iden-
tifier only.

The Response Acknowledgement parameter can be found in any message. It
carries a set of "confirmed transaction-id ranges." Entities may choose
to delete the copies of the responses to transactions whose id is
included in "confirmed transaction-id ranges" received in the 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
the transaction-id.

Messages that carry the "Response Acknowledgement" parameter may be
transmitted in any order.  The entity shall retain the union of the
"confirmed transaction-id ranges" received in recent messages.

19.3.  Computing retransmission timers

It is the responsibility of the requesting entity to provide suitable
time outs for all outstanding transactions, and to retry transactions
when time outs have been exceeded. Furthermore, when repeated transac-
tions fail to be acknowledged, it is the 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:



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 69]


Internet draft              MEGACO Protocol           September 21, 1999


the average acknowledgement delay, AAD, estimated through an exponen-
tially smoothed average of the observed delays,

*    the average deviation, ADEV, estimated through an exponentially
     smoothed average of the absolute value of the difference between
     the observed delay and the current average.  The retransmission
     timer, in TCP, is set to the sum of the average delay plus N times
     the average deviation. In MEGACO/Recommendation H.248, the maximum
     value of the timer should however be bounded, in order to guarantee
     that no repeated packet would be received by the gateways after
     LONG-TIMER seconds.  A suggested maximum value is 4 seconds.

After any retransmission, the entity should do the following:

*    It should double the estimated value of the average delay, AAD

*    It should compute a random value, uniformly distributed between 0.5
     AAD and AAD

*    It should set the retransmission timer to the sum of that random
     value and N times the average deviation.

This procedure has two effects. Because it includes an exponentially
increasing component, it will automatically slow down the stream of mes-
sages in case of congestion. Because it includes a random component, it
will break the potential synchronization between notifications triggered
by the same external event.

19.4.  Provisional responses Executing some transactions may require a
long time. Long execution times may interact with the timer based
retransmission procedure. This may result either in an inordinate number
of retransmissions, or in timer values that become too long to be effi-
cient. Entities that can predict that a transaction will require a long
execution time may send a provisional response, "Transaction Pending".
They should send this response if they receive a repetition of a tran-
saction that is still being executed.

Entities that receive a Transaction Pending shall switch to a longer
repetition timer for that transaction.  The root termination has a pro-
perty (ProvisionalResponseTimerValue) which can be set to the requested
maximum number of milliseconds between receipt of a command and
transmission of the TransactionPending response.

The protocol is organized as a set of transactions, each of which is
composed request and a response, commonly referred to as an acknowledge-
ment.  The protocol messages, being carried over UDP, may be subject to
losses. In the absence of a timely response, transactions are repeated.
Entities are expected to keep in memory a list of the responses that



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 70]


Internet draft              MEGACO Protocol           September 21, 1999


they sent to recent transactions, i.e. a list of all the responses they
sent over the last LONG-TIMER seconds, and a list of the transactions
that are currently being executed.

The transaction identifiers of incoming transactions are compared to the
transaction identifiers of the recent responses. If a match is found,
the entity does not execute the transaction, but simply repeats the
response. The remaining transactionIds will be compared to the list of
current transactions. If a match is found, the entity does not execute
the transaction, which is simply ignored - a response will be provided
when the execution of the transaction is complete.

The repetition mechanism is used to guard against three types of possi-
ble errors:

*    transmission errors, when for example a packet is lost due to noise
     on a line or congestion in a queue,

*    component failure, when for example an interface to a entity
     becomes unavailable,

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

The entities should be able to derive from the past history an estimate
of the packet loss rate due to transmission errors.  In a properly con-
figured system, this loss rate should be kept very low, typically less
than 1%.  If a Media Gateway Controller or a Media Gateway has to repeat
a message more than a few times, it is very legitimate to assume that
something else than a transmission error is occurring.  For example,
given a loss rate of 1%, the probability that 5 consecutive transmission
attempts fail is 1 in 100 billion, an event that should occur less than
once every 10 days for a Media Gateway Controller that processes 1,000
transactions per second. (Indeed, the number of repetition that is con-
sidered excessive should be a function of the prevailing packet loss
rate.) We should note that the "suspicion threshold", which we will call
"Max1", is normally lower than the "disconnection threshold", which
should be set to a larger value.

{Editor's note, the following is all intertwined with MGCP failover
mechanism, it must be edited to deal with whatever we decide to use in
MEGACO/H.248}









Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 71]


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)


A classic retransmission algorithm would simply count the number of suc-
cessive repetitions, and conclude that the association is broken after
re-transmitting the packet an excessive number of times (typically
between 7 and 11 times.) In order to account for the possibility of an
undetected or in-progress "failover", we modify the classic algorithm so
that if the Media Gateway receives a valid ServiceChange message
announcing a failover, it will start transmitting outstanding commands
to that new MGC.  Responses to commands are still transmitted to the
source address of the command.

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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 72]


Internet draft              MEGACO Protocol           September 21, 1999


H.248 specifies exponentially increasing timers.  If the initial timer
is set to 200 milliseconds, the loss of a fifth retransmission will be
detected after about 6 seconds.  This is probably an acceptable waiting
delay to detect a failover.   The repetitions should continue after that
delay not only in order to perhaps overcome a transient connectivity
problem, but also in order to allow some more time for the execution of
a failover - waiting a total delay of 30 seconds is probably acceptable.

It is however important that the maximum delay of retransmissions be
bounded.  Prior to any retransmission, it is checked that the time
elapsed since the sending of the initial datagram is no greater than T-
MAX. If more than T-MAX time has elapsed, the MG concludes that the MGC
has failed, and it begins its recovery process. The value T-MAX is
related to the LONG-TIMER value: the LONG-TIMER value is obtained by
adding to T-MAX the maximum propagation delay in the network.

19.5.  Ordering of commands

The MEGACO/Recommendation H.248 does not mandate that the underlying
transport protocol guarantees the sequencing of transactions sent to an
entity.  This property tends to maximize the timeliness of actions, but
it has a few drawbacks.  For example:

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

*    If a new command is transmitted before a previous one is 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 only one outstanding
     command (Add or Modify or Move).  However, a 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, 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 the triggering notification



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 73]


Internet draft              MEGACO Protocol           September 21, 1999


     request.

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  may not be sent until the
     wild-carded Subtract command is acknowledged.

5.   AuditValue and AuditCapability is not subject to any sequencing.

6.   ServiceChange shall always be the first command sent by a MG as
     defined by the restart procedure. Any other command or response
     must be delivered after this ServiceChange command.

These rules do not affect the Media Gateway, which should always respond
to commands.

19.6.  Fighting the restart avalanche

Let's suppose that a large number of Media Gateways are powered on
simultaneously.  If they were to all initiate a ServiceChange transac-
tion, the Media Gateway Controller would very likely be swamped, leading
to message losses and network congestion during the critical period of
service restoration. In order to prevent such avalanches, the following
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 and 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.   The Media Gateway should then wait for either the end of this timer
     or the detection of a local user activity, such as for example an
     off-hook transition on a residential Media Gateway.

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

The restart procedure simply requires the MG to guarantee that the first
message that the Media Gateway Controller sees from this MG is a 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 74]


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


20.  TRANSPORT USING TCP

MECACO/Recommendation H.248 messages may be transmitted over TCP.  When
no port is specified by the other side (see section 7.2.8), the commands
should be sent to the default 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 and each response, similar to those speci-
fied for application level framing over UDP.

20.1.  Providing the At-Most-Once functionality

Messages, being carried over TCP, are not subject to transport losses,
but loss of a transaction request or its reply may none-the-less be



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 75]


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, it is recommended that entities follow the
procedures 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, the incidence of loss of a transaction request
or reply is expected to be very low.  Therefore, only simple timer
mechanisms are required. Exponential back-off algorithms should not be
necessary, although they could be employed where, as in an MGC, the code
to do so is already required, since MGCs must implement ALF/UDP as well
as TCP.

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 long execution
time may send a provisional response, "Transaction Pending".  They
should send this response if they receive a repetition of a transaction
that is still being executed.

Entities that receive a Transaction Pending shall switch to a longer
repetition timer for that transaction.

Entities shall retain Transactions and replies until they are confirmed.
The basic procedure of section E.4 should be followed, but simple timer
values should be sufficient.

20.5.  Ordering of commands

TCP provided ordered delivery of transactions.  No special procedures
are required.  It should be noted that ALF/UDP allows sending entity to
modify its behavior under congestion, and in particular, could reorder
transactions when congestion is encountered.  TCP could not achieve the
same results.






Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 76]


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 is 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 in the 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

21.1.  Residential Gateway to Residential Gateway Call

This example scenario illustrates the 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 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 in a Context.

1.   An MG registers with an MGC using the ServiceChange command:

     MEGACO/1.0 [124.124.124.222]:55555
     Transaction = 9998 {
         Context = - {
             ServiceChange = ROOT {Services {



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 77]


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 = 9998 {
        Context = - {ServiceChange = 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 = 9999 {
         Context = - {
             Modify = A4444 {
                 Media {
                     TerminationState {
                         BufferedEventHandling{Step,Process}
                      },
                      Stream = 1111 {
                          LocalControl {
                              Mode = SendReceive,
                              Package1/GainControl=2,  ; in dB,
                              Package1/Encryption=xxx,
                              Package1/EchoCancellation=G165,
                              Package1/VoiceActDet=yes
                          },
                          Local = SDP {c=LOCAL
                                       m=audio 0 LOCAL 0
                                       a=sendrecv
                                       a=ptime:10
                          } ; SDP profile 0 is G.711mu-law sampled
                              at 8kHz
                     }
                 },
                 Events = 2222 {Package1/offhook}
             }
         }



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 78]


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 = 9999 {
        Context = - {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 = 10000 {
        Context = - {
            Notify = A4444 {ObservedEvents =2222 {
              19990729T22000000:Package1/offhook}}
        }
     }

     IP 7.  And the Notify is acknowledged



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 79]


Internet draft              MEGACO Protocol           September 21, 1999


     MEGACO/1.0 [124.124.124.121]:55566
     Reply = 10000 {
         Context = - {Notify}
     }


8.   The MGC Modifies the termination to look for digits now.

     MEGACO/1.0 [124.124.124.121]:55566
     Transaction = 10001 {
         Context = - {
             Modify = A4444 {
                 Events = 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 = 10001 {
         Context = - {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 = 10002 {
        Context = - {
            Notify = A4444 {ObservedEvents =2223 {
              19990729T22010001:Package1/digits{digits=16135551212}}}
        }
     }


11.  And the Notify is acknowledged




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 80]


Internet draft              MEGACO Protocol           September 21, 1999


     MEGACO/1.0 [124.124.124.121]:55566
     Reply = 10002 {
         Context = - {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 = 10003 {
         Context = $ {
            Add = A4444,
            Add = $ {
                Media {
                  Stream = 1111 {
                       LocalControl {
                           Mode = ReceiveOnly,
                           Package1/MaxJitterBuffer=40, ; in ms
                           Package1/PreferredPacketization=20, ; in ms
                           Package1/PreferredCodecs=[G723, PCMU],
                           Package1/Gain=0 ; in dB
                       },
                       Local = SDP {c=IN IP4 ANY
                                    m=audio ANY RTP/AVP ANY
                                    a=sendrecv
                       },
                       Remote = SDP {c=IN IP4 ANY
                                     m=audio ANY RTP/AVP ANY
                                     a=sendrecv
                       }
                   }
                },
                Events = 2224 {Package1/onhook}
            }
         }
     }


NOTE: The MGC states its preferred parameter values in the LocalControl.
Local and Remote could be left empty in the Request from MGC to MG. In
any case, the MG fills in the Local in the Reply.

13.  MG1 acknowledges the new Termination and fills in the Local IP



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 81]


Internet draft              MEGACO Protocol           September 21, 1999


     address and 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 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
     connection through to the originating user, 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 {
                         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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 82]


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 = 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 and UDPport need to be given to MG1 now.

     From MGC 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 to MGC:



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 83]


Internet draft              MEGACO Protocol           September 21, 1999


     MEGACO/1.0 [124.124.124.222]:55555
     Reply = 10004 {
        Context = 2000 {Modify}
     }


17.  The two gateways are now connected and User  1 hears the RingBack.
     The MG2 now waits until User2 picks up the receiver and then the
     two-way call is established.

             From MG2 to MGC:

             MEGACO/1.0 [124.124.124.222]:55555
             Transaction = 50004 {
                Context = 5000 {
                    Notify = A5555 {ObservedEvents =1234 {
                      19990729T22020002:Package1/offhook}}
                }
             }

             From MGC to MG2:

             MEGACO/1.0 [124.124.124.121]:55566
             Reply = 50004 {
                 Context = - {Notify}
             }

             From MGC 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 to MGC:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50005 {
              Context = 5000 {Modify, Modify}
             }



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 84]


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 = 2000 {Modify= A4445
                }
             }


19   The MGC decides to Audit the RTP termination on MG2.

             MEGACO/1.0 [124.124.124.121]:55566
             Transaction = 50006 {
                Context = - {AuditValue = A5556{
                   Audit{Media, DigitMap, Events, Signals }}
                }
             }


20.  The MGC replies.

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50006 {
                Context = - {
                   AuditValue {
                       Media {
                          TerminationState {
                              BufferedEventHandling{Process}
                          },
                          Stream = 1212 {
                              LocalControl {
                                 Mode = SendReceive,
                                 Package1/MaxJitterBuffer=40, ; in ms



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 85]


Internet draft              MEGACO Protocol           September 21, 1999


                                 Package1/PreferredPacketization=20, ; in ms
                                 Package1/PreferredCodecs=G723,
                                 Package1/Gain=0  ; in dB
                              },
                              Local = 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 for G.723 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 an onhook signal from one of the MGs, it
     brings down the call. In this example, the user at MG2 hangs up
     first.

             From MG2 to MGC:

             MEGACO/1.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}



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 86]


Internet draft              MEGACO Protocol           September 21, 1999


             }


22.  The MGC now sends both MGs a Subtract to take down the call. Only
     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 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.  The MGC now sets up both MG1 and MG2 to be ready to detect the next
     off-hook event. See step 1. Note that this could be the default
     state of a termination in the null context, and if this were the
     case, no message need be sent from the MGC to the MG. Once a termi-
     nation returns to the null context, it goes back to the default
     termination values for that termination.




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 87]


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 the SCN or IP Side call signaling.  Once multimedia is
detected the MGC will create the Context and appropriate Terminations.

In general, a Termination will associate all media of an individual user
and handles network jitter Streams sourced/sinked by a Termination are
identified by a StreamId to instruct the MG how to connect them.  Media
from terminations with identical streamIDs are connected.  The MGC can
instruct the MG to synchronize streams by setting Context properties.
One of the properties of a Context is the mixing properties. In the fig-
ure below these are represented by the black dots in the context.

The concept of connecting streams makes for a straight forward implemen-
tation of functionality such as speech-to-text transmediation.  If an MG
supports this type of operation, a MGC can assign identical StreamIDs to
a speech stream and a text stream to indicate that incoming speech
should be transformed into text.

21.2.1.  H.320 Gateway

The Context for a point-to-point multimedia call in an H.320-H.323 gate-
way contains two muxing Terminations.  It contains a muxing Termination
that sources and sinks the H.221 frames on DS0s.  This Termination
references a number of DS0s, six in the example for a call with a total
bandwidth of 384 kbit/s.  Each of these DS0s are also terminations in
their own right. The mux/demux descriptor 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 the media flows on the
packet network Side. Assuming that there are audio, video and data
streams, the Termination contains a muxDescriptor with a list of three
bearer descriptors.  No multiplexing is involved in this muxing Termina-
tion: every media flow maps to one stream on the network.













Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 88]


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 Gateway Context


The following is a call flow for a point-to-point H.320 to H.323 call
initiated from the WAN Side. The call flow shows that either the H.323
or H.320 Side can initiate opening (or closing) an audio or video chan-
nel through the gateway.  In H.320, there is the requirement that such
mode changes take at most 20 milliseconds.  In the call flow we see that
messages are exchanged between MG and MGC to inform the MGC of a request
for a mode change from the H.320 Side. The MGC 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
     an Add command to MG, to create a Context with one muxing termina-
     tion and one DS0 termination, indicating in the parameters for the
     muxing termination that Bonding will be used and that the multiplex
     type is H.221.

             MEGACO/1.0 [124.124.124.121]:55566
             Transaction = 9999 {
                 Context = $ {
                    Add = $ {
                        Mux = H221 {DS0_A},
                        Media {



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 89]


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 the mux type, and an ordered list of termina-
tionIds used in the call (here there is only one).  If the termina-
tionIds are not yet added to the context, 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 the line for Bonding and H.221 in-band H.221 framing.

[Editor's Note: the ABNF does not have a script descriptor - this would
need to be added if a script is needed for this case]

2.   The MG acknowledges the Context creation, informing the MGC of the
     ContextID 2000 and TerminationID A4444 (for the muxing termination)
     it assigned.

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 9999 {
                Context = 2000 {Add= A4444}
             }


3.   When the termination finds Bonding, it assigns a Bonding call ID x
     and accepts the proposed call transfer rate requested by the cal-
     ling H.320 endpoint.  The MG then sends a Notify message to the MGC
     informing it of the Bonding call identifier 'x' and the transfer
     rate:

             MEGACO/1.0 [124.124.124.222]:55555
             Transaction = 10000 {
                Context = 2000 {



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 90]


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 = 2000 {Notify}
             }


4.   The MGC allocates additional phone numbers for the call and
     requests the MG to send these back to 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.   The MG replies to the MGC's message and sends the additional phone
     numbers back to the calling Side via Bonding.

6.   When the SGW notifies the MGC of incoming calls for the phone
     numbers associated with Bonding call x, the MGC sends Modify com-
     mands to the MG to add the appropriate DS0 bearer channels to the
     Termination created previously; the MG acknowledges these commands.
     For instance, 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}
                   }



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 91]


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) are added to
     the muxing termination, the MGC request the MG to notify it 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 is acknowledged:

             MEGACO/1.0 [124.124.124.121:]55566
             Reply = 10004 {
                Context = 2000 {Notify}
             }



9.   The MGC instructs the Termination to listen for DTMF tones in the
     audio stream, and possibly to play an announcement to the calling
     user.

10.  The audio announcement will be played and then the Termination will
     listen for DTMF tones in the audio portion of the mux and it com-
     mences a TCS4/IIS signaling exchange in the BAS channel. The



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 92]


Internet draft              MEGACO Protocol           September 21, 1999


     information received is considered the destination alias z for this
     call.

11.  The MG Notifies the MGC of at least three pieces of information: 1)
     frame alignment found, 2) H.320 capabilities, and 3) destination
     alias  z. The MGC sends ARQ to resolve IP address for alias z

12.  Once the address is resolved, the MGC does H.225 call setup. . .
     gets caps from H.323 etc.  Note that we assume that the MGC sets up
     the H.245 connection with the called party.

13.  The MGC sends a Modify to the H.320 termination causing a new capa-
     bility set to be sent from the MG to 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 for audio, the MGC will then Add
     a packet Termination to the Context. In this example, the MGC sets
     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 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 for G.723 is 4
                      }
                   }
                 }
             }

             The Modify is accepted with the following reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 10013 {
                Context = 2000 {
                  Add= A4445 {
                    Media {
                       Stream = 1212 {



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 93]


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 to
     identify the streams that have to be connected within the Context.
     The MG acknowledges the command and reports the assigned Termina-
     tionId to the MGC, as well as the IP address and UDP port it
     selected for the Local Descriptor.

15.  The MGC sends a Modify to the H.320 termination sending a Stream-
     Descriptor to the MG:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10013 {
                 Context = 2000 {
                   Modify= A4445 {
                      Media {
                          Stream = 1212 {
                              LocalControl {Mode = SendReceive},
                              Remote = SDP {m=audio
                                            a=sendrecv}
                          }
                      }
                   }
                 }
             }

             The MG acknowledges the Modify command.


     At this point the MG knows that the audio streams from the packet
     and circuit sides have to be connected because they have the same
     StreamID.

16.  The H.320 side may do a mode switch to H.263 video for example. 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 {



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 94]


Internet draft              MEGACO Protocol           September 21, 1999


                    Notify = A4444 {
                        ObservedEvents =2224 {
              19990729T22050100:H242Pkg/ModeChange{Mode=AddH263}
                        }
                    }
                }
             }

             The MGC sends a reply to 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 is modified 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 for H.263 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 the controller has to do is to set
     the StreamID of the video stream.




Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 95]


Internet draft              MEGACO Protocol           September 21, 1999


The  of the Modify to terminationId A4445 would return 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 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 the
terminations are shown for clarity. The bridging functionality is a con-
text property, there is no separate bridge entity in the connection
model.








































Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 96]


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 ||
          | +-------|         |       | |       |         |-------+|
          |         |         |      /___      |         |        |
          | +-------|         |     /          |         |-------+|
          | | T.120 |         |----/       ----|         | T.120 ||
          | | Data  |         |                 |         | Data  ||
          | +-------|         |                 |         |-------+|
          |         +---------+                 +---------+        |
          +--------------------------------------------------------+
                               Figure 7 Multimedia Context Example


21.2.3.  Single Media Call The single media the call flow example
describes a call that originates in the SCN and is terminated in the
packet network.  The packet network signaling in this example is H.323
but other signaling protocols such as SIP can be used, the purpose of
the example is to describe MG/MGC interactions.



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 97]


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 the signalling gate-
way (SGW) and MGC is based on Q.931.  This does not indicate that no
other signalling can be used on this interface.

1.   The SGW sends a Setup message to the MGC after receiving an IAM
     from a SCN switch.

2.   From the IAM message, the MGC may infer which circuit on which MG
     is involved and where to terminate the call.  How the MGC does
     this, is outside the scope of this document.

3.   The MGC creates a Context for the call.  The Context contains two
     terminations: one for the SCN side and one for the packet side. In
     this example, 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 98]


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 the mux?
                   Media { Stream = 1111 {
                             LocalControl {
                               Mode = ReceiveOnly,
                               Package1/MaxJitterBuffer=40, ; in ms
                               Package1/PreferredPacketization=20, ; in ms
                               Package1/PreferredCodecs=[G723, PCMU],
                               Package1/Gain=0 ; in dB
                             },
                             Local = SDP {c=IN IP4 ANY
                                          m=audio ANY RTP/AVP ANY
                                          a=sendrecv
                             },
                             Remote = 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 there is only one medium, this StreamID can be omitted.

     We see in the command syntax how the MGC uses a "$" to leave the
     assignment of names for both the Context itself and the Termina-
     tions in it, to the MG.

3.   The MG accepts the Context creation 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers           [Page 99]


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 is 4
                      }
                    }
                  }
                }
             }


     This step shows how the MG reports to the MGC what parameters it
     filled in for the IP address and UDP port to which media should be
     addressed.

4.   The 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 either G.711 or G.723 may be used for
     the voice stream.

5.   The H.323 endpoint sends an Alerting message back to the MGC,
     informing it of the codec to be used (assume G.723 for both direc-
     tions) and the transport address.

6.   The MGC sends a Modify command to the MG to set the Mode and Bearer
     information for the packet side  Remote Descriptor:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10000 {
               Context = 2000 {
                 Modify = A4445 {
                   Media {
                     Stream = 1111 {
                       Remote = SDP {c=IN IP4 111.1.1.1
                                     m=audio 1111 RTP/AVP 0 4}
                         }
                      }
                   }
                }
             }



5.   The MG accepts the Modify command with this reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 10000 {
                Context = 2000 {Modify}



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 100]


Internet draft              MEGACO Protocol           September 21, 1999


             }


6.   The MGC sends an Alerting message to the SGW.

7.   The called endpoint at some instance sends a Connect message to the
     MGC.

8.   In response to the Connect, the MGC sends a Modify command to the
     MG to change the Activity of the Local stream descriptor on the SCN
     Side:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 10001 {
               Context = 2000 {
                 Modify = A4445 {
                   Media {
                     Stream = 1111 {
                       Local = SDP {a=sendrecv}
                     }
                   }
                 }
               }
             }


9.   The 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
             Reply = 10001 {
                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. }

The following flow describes an H.320 to H.323 gateway call where the
signaling and media terminations for the SCN and packet network both
reside on the MG.  In this case the MG terminates an ISDN PRI interface
and the packet interface is H.323 IP and also resides on the MG. The
signaling capabilities are represented as physical H.323 and FAS termi-
nations that exchange events with the MGC to indicate changes in call
state. This gateway session uses Bonding channel aggregation making the



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 101]


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 to the MGC in a Notify.

2.   MGs FAS termination gets an incoming call with (Q.931) call type 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 the B channel.

4.   When the termination finds Bonding, it assigns a Bonding call ID x
     and then allocates additional phone numbers for the call and sends
     these back to the calling side via Bonding.

5.   The MG sends a Notify to the MGC.

6.   The MGC sends an Add to the MG to create a multimedia context and
     sends a Modify to move/add the DS0 termination to the new mul-
     timedia context .

7.   The FAS termination detects signaling for 5 additional B channels,
     sends a Notify to MGC, and the MGC adds these B channels to the mux
     termination in the MG

8.   The MG detect Bonding and sends a Notify to the MGC

9.   The MGC sends a modify to move the termination into the multimedia
     context

10.  The remaining B channels connect 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.

13.  The H.221 Termination will play the audio announcement and listen
     for DTMF tones in the audio portion of the mux and it commences a
     TCS4/IIS signaling exchange in the BAS channel. The information
     received is considered the destination z alias for this call.

14.  The MG Notifies the MGC of the destination alias  z.

15.  The MGC sends ARQ to resolve IP address for alias z

16.  Once the address is resolved, the MGC Adds an H.323 signaling to
     the multimedia context



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 102]


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.  The MG sends a Notify to the 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.  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 from H.323 Side for audio, the MG will send a
     Notify to the MGC

21.  The MGC will Add an Audio/RTP termination to the context.

22.  The MGC will send a Modify to the H.221 termination causing the
     H.221 mux to change and the selected audio channel (G.711, G.723
     etc.) 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 to
     the MGC requesting H.263 video.  The MGC will send an Add Video/RTP
     termination to the context and a Modify H.320/video to the context.

21.2.5.  Simple text telephone call

The Simple Text Telephone Call flow example describes a call that ori-
ginates in a Text Telephone in the SCN and is terminated in an H.323
Annex G Text Conversation capable terminal in the packet network. The
purpose of the example is to describe MG/MGC interactions. The SGW sends
a Setup message to the MGC after receiving an IAM from an SCN switch.

2.   From the IAM message, the MGC may infer which circuit on which MG
     is involved and where to terminate the call.

3.   The MGC creates a Context for the call.  The Context contains two
     terminations: one for the SCN side and one for the packet side:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 50003 {
                 Context = $ {
                    Add = DS0/12/2 {
                                   Media { Stream = 1212 {
                                LocalControl {
                                  Mode = ReceiveOnly,
                                  Package1/VoiceActivityDet=No,
                                  Package1/PreferredCodecs=T140},
                                Local= SDP {c=LOCAL
                                            m=text 0 LOCAL 0



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 103]


Internet draft              MEGACO Protocol           September 21, 1999


                                }
                              }
                       },
                      Modem=V18,
                      Signals {Package_texttel/signal1 {name1=value1}}
                    },
                    Add  = $ {
                      Media { Stream = 1212 {
                                LocalControl {
                                  Mode = ReceiveOnly,
                                  Package1/PreferredCodecs=T140
                                },
                                Local= SDP {c=IN IP4 ANY
                                            m=text ANY RTP/AVP 0 95
                                            a=rtpmap:95 T140
                                },
                                Remote= SDP {c=IN IP4 ANY
                                             m=text ANY RTP/AVP 0 95
                                             a=rtpmap:95 T140
                                }
                              }
                       }
                    }
                 }
             }

             This is acknowledged: the MG creates the context and returns info.

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50003 {
                Context = 5000 {Add,
                                Add = A5556 {
                                   Media {
                                       Stream = 1212 {
                                          Local = SDP {c=IN IP4 111.1.1.1
                                            m=text 1111 RTP/AVP 0 95
                                            a=rtpmap:95 T140}
                                       }
                                   }
                               }
                }
             }


2.   The 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



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 104]


Internet draft              MEGACO Protocol           September 21, 1999


     stream.

3.   The H.323 endpoint sends an Alerting message back to the MGC,
     informing it of the data stream to be used and the transport
     address.

4.   The MGC sends a Modify command to the MG to set the mode and remote
     termination description on the packet side:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 50004 {
                Context = 2000 {
                   Modify = A5556 {
                      Media {
                         Stream = 1212 {
                             LocalControl {
                               Mode = SendReceive
                             },
                             Remote = SDP {c=IN IP4 222.2.2.2
                                           m=text 2222 RTP/AVP 0 95
                                           a=rtpmap:95 T140
                             }
                         }
                      }
                   }
                }
             }

             The MG accepts the Modify commands with this reply:

             MEGACO/1.0 [124.124.124.222]:55555
             Reply = 50004 {
                Context = 2000 {Modify}
             }


5.   The MGC sends an Alerting message to the SGW.

6.   The called endpoint at some instance sends a Connect message to the
     MGC.

7.   In response to the Connect, the MGC sends a Modify command to the
     MG to change the mode of the SCN side termination to SendRecv:

             MEGACO/1.0 [124.124.124.121:]55566
             Transaction = 50005 {
                Context = 2000 {
                   Modify = DS0/12/2 {



Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 105]


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
























Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers          [Page 106]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/