draft-ietf-megaco-protocol-03.txt   draft-ietf-megaco-protocol-04.txt 
Internet Engineering Task Force Fernando Cuervo Internet Engineering Task Force Fernando Cuervo
INTERNET DRAFT Nortel Networks INTERNET DRAFT Nortel Networks
July 30, 1999 Christian Huitema September 21, 1999 Bryan Hill
Expires January 30,2000 Telcordia Technologies Expires March 21, 2000 Gotham Networks
<draft-ietf-megaco-protocol-03.txt> Keith Kelly <draft-ietf-megaco-protocol-04.txt> Nancy Greene
NetSpeak Nortel Networks
Christian Huitema
Telcordia Technologies
Abdallah Rayhan
Nortel Networks
Brian Rosen Brian Rosen
FORE Systems FORE Systems
Paul Sijben John Segers
Lucent Technologies Lucent Technologies
Eric Zimmerer
Level 3 Communications
MEGACO Protocol Megaco Protocol
Status of this document Status of this document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is nappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IMPORTANT NOTE This document will expire in March 2000.
In accordance with agreements reached between IETF and ITU, the text of Internet draft MEGACO Protocol September 21, 1999
the protocol, IETF version 03, is found at:
ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/megacoHGCP9.pdf
Internet draft MEGACO Protocol July 30, 1999 Table of Contents
Abstract 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
MEGACO/Recommendation H.248 defines the protocols used between elements Internet draft MEGACO Protocol September 21, 1999
of a physically decomposed multimedia gateway. There are no functional
differences from a system view between a decomposed gateway, with dis-
tributed sub-components potentially on more than one physical devices,
and a monolithic gateway.
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
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
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
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 This document does not define how gateways, multipoint control units or
integrated voice response units (IVRs) work. Instead it creates a gen- integrated voice response units (IVRs) work. Instead it creates a gen-
eral framework that is suitable for these applications. eral framework that is suitable for these applications.
Packet network interfaces may include IP, ATM or possibly others. The Packet network interfaces may include IP, ATM or possibly others. The
interfaces will support a variety of SCN signalling systems, including interfaces will support a variety of SCN signaling systems, including
tone signalling, ISDN, ISUP, QSIG, and GSM. National variants of these tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of these
signaling systems will be supported where applicable. 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.
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.
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.
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.
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
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
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
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.
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
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
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
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
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.
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)
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
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.
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.
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 |
|___________________|
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.
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
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.
Internet draft MEGACO Protocol September 21, 1999
Context 1 Context 2 Context 3
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| ^ ^ | | ^ | | ^ |
| | | | | | | | | |
| +--+ +--+ | | +---+ | | +--+ |
| | | | | | | | | |
| v v | | v | | | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway
Context 1 Context 2 Context 3
+------------------+ +------------------+ +------------------+
| +----+ | | +----+ | | +----+ |
| | T2 | | | | T2 | | | | T2 | |
| +----+ | | +----+ | | +----+ |
| | | | ^ | | ^ ^ |
| | | | | | | | | |
| +--+ | | +---+ | | +--+ +--+ |
| | | | | | | | | |
| v | | v | | v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
| | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ |
+------------------+ +------------------+ +------------------+
1. T2, T3 oneway 2. T2, T3 bothway 3. T1, T2 bothway
Figure 4: Example topologies
Internet draft MEGACO Protocol September 21, 1999
__________________________________________________________________________
|Topology| Description |
|________|_________________________________________________________________|
|1 | No topology descriptors. |
| | |
| | When no topology descriptors included, all terminations have a |
| | both way connection to all other terminations. |
|________|_________________________________________________________________|
|2 | T1, T2, Isolated. |
| | |
| | Removes the connection between T1 and T2. |
| | T3 has a both way connection with both T1 and T2. T1 and T2 |
| | have bothway connection to T3. |
|________|_________________________________________________________________|
|3 | T3, T2, oneway. |
| | |
| | A oneway connection from T3 to T2 (i.e. T2 receives media flow |
| | from T3). A bothway connection between T1 and T3. |
|________|_________________________________________________________________|
|4 | T2, T3, oneway. |
| | |
| | A oneway connection between T2 to T3. T1 and T3 remain |
| | bothway connected |
|________|_________________________________________________________________|
|5 | T2, T3 bothway. |
| | |
| | T2 is bothway connected to T3. This results in the same as 2. |
|________|_________________________________________________________________|
|6 | T1, T2 bothway. |
| | |
| | All terminations are considered connected to each other. |
| | This is the same as 1. |
|________|_________________________________________________________________|
A topology change is performed by including a topology descriptor in an
Add or Modify command. Allowing a topology descriptor in an Add command
facilitates addition of a Termination to a Context and setting the
topology in one atomic action.
When the topology is included in the "Add" command, then either "Ter-
minationA" or "TerminationB" shall be of value "*" to indicate the ter-
mination being added to the context.
7.2. Command Application Programming Interface
Following is an Application Programming Interface (API) describing the
Commands of the protocol. This API is shown to illustrate the Commands
and their parameters and is not intended to specify implementation
(e.g.-via use of blocking function calls). It will describe the input
parameters in parentheses after the command name and the return values
in front of the Command. This is only for descriptive purposes; the
Internet draft MEGACO Protocol September 21, 1999
actual Command syntax and encoding are specified in later subsections.
All parameters enclosed by square brackets ([. . . ]) are considered
optional.
7.2.1. Add
The Add Command adds a Termination to a Context.
[TerminationID]
[,MediaDescriptor]
[,ModemDescriptor]
[,MuxDescriptor]
[,EventsDescriptor]
[,SignalsDescriptor]
[,DigitMapDescriptor]
[,ObservedEventsDescriptor]
[,StatisticsDescriptor]
[,PackagesDescriptor]
Add( TerminationID
[, MediaDescriptor]
[, ModemDescriptor]
[, MuxDescriptor]
[, EventsDescriptor]
[, SignalsDescriptor]
[, DigitMapDescriptor]
[, AuditDescriptor]
)
The TerminationID specifies the termination to be added to the Context.
For an existing Termination, the TerminationID would be specific. For a
Termination which does not yet exist, the TerminationID is specified as
Choose ("$") in the command. The new TerminationID will be returned.
Wildcards may be used in an Add, but such usage would be unusual. If
the wildcard matches more than one TerminationID, all possible matches
are attempted, with results reported for each one. The order of
attempts when multiple TerminationIDs match is not specified.
The optional MediaDescriptor describes all media streams.
The optional ModemDescriptor and MuxDescriptor specify a modem and mul-
tiplexer if applicable. For convenience, if a Multiplex Descriptor is
present in an Add command and lists any Terminations that are not
currently in the Context, such Terminations are added 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.
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
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]
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
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
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
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
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.
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
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
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
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.
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.
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
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.
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.
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.
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.
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
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
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
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
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
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
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
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.
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
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] )
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
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
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
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
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
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 )
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")
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")
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.
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 | | | |
|_________|___________|______|________|
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:
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.
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:
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
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}
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
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
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
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
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.
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 {
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}
}
}
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
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
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
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
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:
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}
}
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
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}
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.
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.
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 {
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 {
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}
}
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
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 {
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 {
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.
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.
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.
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
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
Internet draft MEGACO Protocol September 21, 1999