draft-ietf-megaco-protocol-00.txt   draft-ietf-megaco-protocol-01.txt 
Internet Engineering Task Force Fernando Cuervo Internet Engineering Task Force Fernando Cuervo
INTERNET DRAFT Nortel Networks INTERNET DRAFT Nortel Networks
March 25, 1999 Christian Huitema April 16, 1999 Christian Huitema
Expires September 25, 1999 Telcordia Technologies Expires October 16, 1999 Telcordia Technologies
<draft-ietf-megaco-protocol-00.txt> Keith Kelly <draft-ietf-megaco-protocol-01.txt> Keith Kelly
NetSpeak NetSpeak
Brian Rosen Brian Rosen
FORE Systems FORE Systems
Paul Sijben Paul Sijben
Lucent Technologies Lucent Technologies
Eric Zimmerer Eric Zimmerer
Level 3 Communications Level 3 Communications
MEGACO Protocol Proposal 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.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
IMPORTANT NOTE IMPORTANT NOTE
This version of the draft has been rushed so that members of the WG not This version of the draft has been rushed so that members of the WG not
part of the small design team that created this document could have part of the small design team that created this document could have
early input to the design process. The last few sections of the document early input to the design process. The last few sections of the document
have not been reviewed by the team, and are largely lifted from other have not been reviewed by the team, and are largely lifted from other
documents, especially the MGCP document. The design team did not reach documents, especially the MGCP document. The design team did not reach
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
consensus on several major issues, including how the protocol messages consensus on several major issues, including how the protocol messages
will be encoded. This has complicated text in several areas. The latter will be encoded. This has complicated text in several areas. The latter
sections (the un-reviewed ones) make assumptions on encoding which have sections (the un-reviewed ones) make assumptions on encoding which have
not been agreed to. The team feels that presenting the information con- not been agreed to. The team feels that presenting the information con-
tained in these sections will assist readers to understand the proposal tained in these sections will assist readers to understand the proposal
in greater depth, and thus chose to leave the text as is. in greater depth, and thus chose to leave the text as is.
Abstract Abstract
skipping to change at page 3, line 5 skipping to change at page 3, line 5
* The Syntax section presents the syntactical elements of the proto- * The Syntax section presents the syntactical elements of the proto-
col independent of its encoding. col independent of its encoding.
* The Transport section presents how the protocol is carried on a * The Transport section presents how the protocol is carried on a
packet network and describes the reliability and fail-over mechan- packet network and describes the reliability and fail-over mechan-
isms that it supports. isms that it supports.
* The Event Packages and Termination Classes section describes the * The Event Packages and Termination Classes section describes the
elements of commonly implemented devices and services. elements of commonly implemented devices and services.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Table of Contents Page Table of Contents Page
1. Introduction .............................................. 5 1. Introduction .............................................. 5
1.1. High Level Description of the Protocol ............... 5 1.1. High Level Description of the Protocol ............... 5
1.1.1. Connection Model ................................ 5 1.1.1. Connection Model ................................ 5
1.1.2. Terminations .................................... 8 1.1.2. Terminations .................................... 8
1.1.3. Termination Capabilities ........................ 8 1.1.3. Termination Capabilities ........................ 8
1.1.4. Termination Dynamics ............................ 9 1.1.4. Instantiation of a Termination An MG realizes ... 9
1.1.5. Issuing Commands in Transactions ................ 10 1.1.5. Termination Dynamics ............................ 9
1.1.6. Sample Command Flow ............................. 12 1.1.6. Issuing Commands in Transactions ................ 11
1.1.7. Sample Command Flow ............................. 12
2. Commands .................................................. 15 2. Commands .................................................. 15
2.1. Names and Common Parameters .......................... 16 2.1. Names and Common Parameters .......................... 16
2.1.1. Context Identifiers ............................. 16 2.1.1. Context Identifiers ............................. 16
2.1.2. Termination Names ............................... 16 2.1.2. Termination Names ............................... 16
2.1.3. Specifying Properties ........................... 17 2.1.3. Specifying Properties ........................... 17
2.1.4. Termination State Properties .................... 17 2.1.4. Termination State Properties .................... 18
2.1.5. Termination Descriptors ......................... 19 2.1.5. Termination Descriptors ......................... 19
2.1.6. Events, Signals and Packages .................... 19 2.1.6. Events, Signals and Packages .................... 19
2.1.7. SignalDescriptors ............................... 21 2.1.7. SignalDescriptors ............................... 20
2.1.8. EventDescriptors ................................ 21 2.1.8. EventDescriptors ................................ 21
2.1.9. Digit Maps ...................................... 23 2.1.9. Digit Maps ...................................... 21
2.1.10. Statistics ..................................... 24 2.1.10. Statistics ..................................... 23
2.2. Termination Management Commands ...................... 25 2.2. Termination Management Commands ...................... 24
2.2.1. Add ............................................. 25 2.2.1. Add ............................................. 24
2.2.2. Modify .......................................... 27 2.2.2. Modify .......................................... 25
2.2.3. Subtract ........................................ 28 2.2.3. Subtract ........................................ 27
2.2.4. Move ............................................ 29 2.2.4. Move ............................................ 28
2.2.5. Audit ........................................... 30 2.2.5. Audit ........................................... 28
2.3. MG-Issued Commands ................................... 31 2.3. MG-Issued Commands ................................... 30
2.3.1. Notify .......................................... 31 2.3.1. Notify .......................................... 30
2.3.2. ServiceChange ................................... 32 2.3.2. ServiceChange ................................... 31
2.4. Error Codes .......................................... 34 2.4. The following table lists the defined commands, and .. 33
3. Security Considerations ................................... 34 3. MG-MGC Control Associations ............................... 33
3.1. Protection of Media Connections ...................... 36 3.1. Multiple MGCs per MG ................................. 33
4. Syntax .................................................... 38 3.2. Cold Start ........................................... 34
3.3. Upon failure to obtain a reply, either from the ...... 35
****************************************************************** 3.4. Failover ............................................. 35
The text in the following sections HAS NOT BEEN REVIEWED by the 3.4.1. Failure of an MG ................................ 35
Design team and is presented for clarity without implying 3.4.2. Failure of an MGC ............................... 35
consensus or correctness. 3.5. Error Codes .......................................... 36
****************************************************************** 4. Security Considerations ................................... 36
4.1. Protection of Media Connections ...................... 38
4.1. Termination Names .................................... 42 5. Syntax .................................................... 40
4.2. Events, Signals and Packages ......................... 43 5.1. Termination Names .................................... 44
4.3. Digit Maps ........................................... 45 5.2. Events, Signals and Packages ......................... 45
4.4. Statistics ........................................... 46 5.3. Digit Maps ........................................... 47
4.5. Examples ............................................. 49 5.4. Statistics ........................................... 48
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
4.5.1. Example Add transaction: ........................ 50 5.5. Examples ............................................. 51
4.5.2. Example response to Add transaction: ............ 50 5.5.1. Example Add transaction: ........................ 52
4.5.3. Example Modify transaction: ..................... 50 5.5.2. Example response to Add transaction: ............ 52
4.5.4. Example Subtract transaction: ................... 50 5.5.3. Example Modify transaction: ..................... 52
4.6. Transaction Response Codes ........................... 51 5.5.4. Example Subtract transaction: ................... 52
4.6.1. Transaction Response Success Codes .............. 51 5.6. Transaction Response Codes ........................... 53
4.6.2. Transaction Response Reject Codes ............... 51 5.6.1. Transaction Response Success Codes .............. 53
5. Transport ................................................. 52 5.6.2. Transaction Response Reject Codes ............... 53
5.1. Transport capabilities, and relationship to Transport 52 6. Transport ................................................. 54
6. Event packages and termination classes .................... 53 6.1. Transport capabilities, and relationship to Transport 54
6.1. Basic event packages ................................. 54 7. Event Packages and Termination Classes .................... 55
6.1.1. Generic Media Event package ..................... 54 7.1. Basic Event Packages ................................. 56
6.1.2. DTMF event package .............................. 55 7.1.1. Generic Media Event Package ..................... 56
6.1.3. MF Event package ................................ 58 7.1.2. DTMF Event Package .............................. 57
6.1.4. Trunk Event package ............................. 59 7.1.3. MF Event Package ................................ 60
6.1.5. Line Event package .............................. 60 7.1.4. Trunk Event Package ............................. 61
6.1.6. Handset emulation event package ................. 64 7.1.5. Line Event Package .............................. 62
6.1.7. RTP Event package ............................... 65 7.1.6. Handset emulation Event Package ................. 66
6.1.8. Network Access Server Event package ............. 66 7.1.7. RTP Event Package ............................... 67
6.1.9. Announcement Server Event package ............... 67 7.1.8. Network Access Server Event Package ............. 68
6.1.10. Script Event package ........................... 68 7.1.9. Announcement Server Event Package ............... 69
6.2. Basic termination classes ............................ 69 7.1.10. Script Event Package ........................... 70
6.2.1. DS0 Terminations ................................ 69 7.2. Basic Termination Classes ............................ 71
6.2.2. Analog Terminations ............................. 70 7.2.1. DS0 Terminations ................................ 71
6.2.3. RTP Audio Terminations .......................... 71 7.2.2. Analog Terminations ............................. 72
6.2.4. ATM audio terminations .......................... 75 7.2.3. RTP Audio Terminations .......................... 74
6.2.5. Network access service termination .............. 77 7.2.4. ATM audio Terminations .......................... 78
7. Acknowledgements .......................................... 81 7.2.5. Network access service Termination .............. 80
8. References ................................................ 81 8. Acknowledgements .......................................... 84
9. Authors' Addresses ........................................ 82 9. References ................................................ 84
10. Authors' Addresses ....................................... 85
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
1. Introduction 1. Introduction
This document describes the MEGACO protocol for controlling Media Gate- This document describes the MEGACO protocol for controlling Media Gate-
ways from external call control elements called Media Gateway Controll- ways from external call control elements called Media Gateway Controll-
ers. ers.
1.1. High Level Description of the Protocol 1.1. High Level Description of the Protocol
This section describes the model and main concepts upon which the MEGACO This section describes the model and main concepts upon which the MEGACO
Protocol is built. It is intended to familiarize the reader with the Protocol is built. It is intended to familiarize the reader with the
model, terminology and working concepts of the protocol. This section's model, terminology and working concepts of the protocol. This section's
contents are illustrative and do not intend to supersede information contents are illustrative and do not intend to supersede information
contained in later sections of this document. Where discrepancies may contained in later sections of this document. Where discrepancies may
exist, the later sections shall be assumed to contain the correct infor- exist, the later sections shall be assumed to contain the correct infor-
mation. mation.
1.1.1. Connection Model 1.1.1. Connection Model
The connection model for the MEGACO protocol is described using just two The connection model for the MEGACO protocol is described using just two
abstractions, Terminations and Contexts. Terminations are entities abstractions, Terminations and Contexts. Terminations (T) are entities
representing physical endpoints, such as analog loops or timeslots on a representing physical endpoints, such as analog loops or timeslots on a
TDM channel, as well as more ephemeral representations of flow termina- TDM channel, as well as more ephemeral representations of flow termina-
tions, such as RTP streams. tions, such as RTP streams.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
*======================================================* *======================================================*
| Media Gateway | | Media Gateway |
| +-----------------------------------+ | | +-----------------------------------+ |
| | Context +---+ | | | | Context +---+ | |
| | | T | | | | | | T | | |
| +---+ | +-+-+ | | | +---+ | +-+-+ | |
| | T | | | | | | | T | | | | |
| +---+ | +---+ +-+ +---+ | | | +---+ | +---+ +-+ +---+ | |
| | | T +---------+ +---------| T | | | | | | T +---------+M+---------| T | | |
| | +---+ +-+ +---+ | | | | +---+ +-+ +---+ | |
| | | | | | | | | |
| | +-+-+ | | | | +-+-+ | |
| | | T | | | | | | T | | |
| | +---+ | | | | +---+ | |
| +-----------------------------------+ | | +-----------------------------------+ |
| | | |
| +----------------------+ +---------------+ | | +----------------------+ +---------------+ |
| | Context | | Context | | | | Context | | Context | |
| | +---+ +-+ | | +---+ +-+ | | | | +---+ +-+ | | +---+ +-+ | |
| | | T +---------+ + | | | T +----+ + | | | | | T +---------+M+ | | | T +----+M+ | |
| | +---+ +-+ | | +---+ +-+ | | | | +---+ +-+ | | +---+ +-+ | |
| | | | +---------------+ | | | | | +---------------+ |
| | +-+-+ | | | | +-+-+ | |
| | | T | | | | | | T | | |
| | +---+ | | | | +---+ | |
| +----------------------+ | | +----------------------+ |
*======================================================* *======================================================*
Examples of Contexts and Terminations Within an MG Examples of Contexts and Terminations Within an MG
Contexts represent a star configuration (i.e.-a variable number of Contexts represent a star configuration (i.e.-a variable number of
interconnected nodes) of Terminations of a single media type. Audio interconnected nodes) of Terminations of a single media type. Audio
connections are modeled by viewing the Context as a mixing bridge. For connections are modeled by viewing the Context as a mixing bridge (M).
connections involving other media types and for mixed media gateways, For connections involving other media types and for mixed media gate-
the Context's behavior will be described as an extension to the proto- ways, the Context's behavior will be described as an extension to the
col. There are commands to Add Terminations to a Context, Subtract Ter- protocol. There are commands to Add Terminations to a Context, Subtract
minations from a Context, and Move Terminations between two Contexts. Terminations from a Context, and Move Terminations between two Contexts.
A Context must have at least one Termination and a Termination may A Context must have at least one Termination and a Termination may
belong to no more than one Context at a given time. A Context is belong to no more than one Context at a given time. A Context is
created by the Add of its first Termination and is destroyed by a Sub- created by the Add of its first Termination and is destroyed by a Sub-
tract of its last remaining Termination. It is possible to move a Ter- tract of its last remaining Termination. It is possible to move a Ter-
mination from one Context to another with the use of the Move command. mination from one Context to another with the use of the Move command.
It is also possible for a Termination to exist outside of a Context. It is also possible for a Termination to exist outside of a Context.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
A Media Gateway may limit the number of Terminations that it supports in A Media Gateway may limit the number of Terminations that it supports in
a given Context. For example, a limit of two might exist for very sim- a given Context. For example, a limit of two might exist for very sim-
ple gateways. A limit of three might be common for gateways that sup- ple gateways. A limit of three might be common for gateways that sup-
port a three-way calling but not multi-way calling of any larger propor- port a three-way calling but not multi-way calling of any larger propor-
tions. tions.
To illustrate the use of a Context, consider a Media Gateway that pro- To illustrate the use of a Context, consider a Media Gateway that pro-
vides media adaptation between the PSTN and a VoIP network. In this vides media adaptation between the PSTN and a VoIP network. In this
case a typical Context might contain two Terminations, one representing case a typical Context might contain two Terminations, one representing
skipping to change at page 8, line 5 skipping to change at page 8, line 5
command to relocate a Termination between Contexts. In this example, command to relocate a Termination between Contexts. In this example,
Terminations T1 and T2 belong initially to Context C1. T1 might be the Terminations T1 and T2 belong initially to Context C1. T1 might be the
line side of a residential gateway, while T2 could represent an RTP line side of a residential gateway, while T2 could represent an RTP
Stream Termination. When T1 is connected to T2 in Context C1 a new call Stream Termination. When T1 is connected to T2 in Context C1 a new call
arrives for T1 from Termination T3. T3 is placed in Context C2. After arrives for T1 from Termination T3. T3 is placed in Context C2. After
alerting is applied to T1 in Context C1 and T1 provides signaling to alerting is applied to T1 in Context C1 and T1 provides signaling to
accept the waiting call, T1 is moved from C1 to C2 through use of the accept the waiting call, T1 is moved from C1 to C2 through use of the
Move command. The active call is represented now by C2 and the call on Move command. The active call is represented now by C2 and the call on
hold is represented by C1. hold is represented by C1.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Call Waiting Scenario: Call Waiting Scenario:
Initial Call Initial Call
+-C1--------------------+ +-C1--------------------+
| +---+ +-+ +---+ | | +---+ +-+ +---+ |
| |T1 +---+ +---| T2| | | |T1 +---+M+---| T2| |
| +---+ +-+ +---+ | | +---+ +-+ +---+ |
+-----------------------+ +-----------------------+
New Call Arrives New Call Arrives
+-C1--------------------+ +-C2--------------------+ +-C1--------------------+ +-C2--------------------+
| +---+ +-+ +---+ | | +-+ +---+ | | +---+ +-+ +---+ | | +-+ +---+ |
| |T1 +---+ +---| T2| | | + +---| T3| | | |T1 +---+M+---| T2| | | +M+---| T3| |
| +---+ +-+ +---+ | | +-+ +---+ | | +---+ +-+ +---+ | | +-+ +---+ |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
Waiting Call Answered Waiting Call Answered
+-C1--------------------+ +-C2--------------------+ +-C1--------------------+ +-C2--------------------+
| +-+ +---+ | | +---+ +-+ +---+ | | +-+ +---+ | | +---+ +-+ +---+ |
| + +---| T2| | | |T1 +---+ +---| T3| | | +M+---| T2| | | |T1 +---+M+---| T3| |
| +-+ +---+ | | +---+ +-+ +---+ | | +-+ +---+ | | +---+ +-+ +---+ |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
1.1.2. Terminations 1.1.2. Terminations
A Termination representing a physical device may be permanently instan- A Termination representing a physical device may be permanently instan-
tiated and can exist outside of a Context. Terminations representing tiated and can exist outside of a Context. Terminations representing
packet flows are typically ephemeral and are created within a Context as packet flows are typically ephemeral and are created within a Context as
a byproduct of an Add command. a byproduct of an Add command.
All Terminations, ephemeral or not, are named entities and are members All Terminations, ephemeral or not, are named entities and are members
of their specific TerminationClass. Names are hierarchical. Termina- of their specific TerminationClass. Names are hierarchical. Termina-
tions are given a unique name (i.e.-the last component of the hierarchi- tion names may be "underspecified" by the MGC and subsequently given a
cal name will be unique) by the Media Gateway. Wildcards may be used in unique name (i.e.-the last component of the hierarchical name will be
the specification of a name. Section [2.1.2] describes in detail the unique) by the Media Gateway. Wildcards may be used in the specifica-
structure and properties of entity names used in the MEGACO Protocol. tion of a name. Section [2.1.2] describes in detail the structure and
properties of entity names used in the MEGACO Protocol.
1.1.3. Termination Capabilities 1.1.3. Termination Capabilities
Membership in a TerminationClass determines the Capabilities of a Termi- Membership in a TerminationClass determines the capabilities of a Termi-
nation. The TerminationClass provides the default values and allowable nation. The TerminationClass defines the default values and allowable
Internet draft MEGACO Protocol Proposal March 25, 1999
ranges for the Termination's Capabilities. Capabilities include: Internet draft MEGACO Protocol April 16, 1999
* Termination address, media parameters, security properties, etc. ranges for the Termination's capabilities. Capabilities include:
The list of these properties is described in a Profile.
<editor note: Profile is a new term, we'll see if it is useful...later> * Properties, such as Termination address, media parameters, security
parameters, etc. These are grouped into Profiles.
* Events and Signals that a Termination supports. They are grouped * Events and Signals that a Termination supports. These are grouped
in Packages. in Packages.
It is possible for a TerminationClass to coalesce its Capabilities from * Statistics that are kept for Terminations of this Class
multiple Profiles and Packages. TerminationClasses, Profiles and Pack-
ages cannot be created or modified using the commands of the Megaco pro-
tocol. This is expected to be done via, for instance, management
mechanisms. The Modify command only applies to instantiated termina-
tions. The Capabilities values of a TerminationClass are the default
values for Terminations instantiated from the TerminationClass.
The Capabilities of a Termination can be obtained using the Audit com- A TerminationClass is described by a list of Profiles, Packages and
statistics that it implements. TerminationClasses, Profiles and Packages
cannot be created or modified using the commands of the Megaco protocol,
but this document defines several commonly implemented ones.
The capabilities of a Termination can be obtained using the Audit com-
mand. mand.
1.1.4. Termination Dynamics 1.1.4. Instantiation of a Termination An MG realizes instances of a
TerminationClass. The Terminations are instantiated for each "port" on
an MG, and are instantiated by the MG when it restarts (or potentially
by some administrative provisioning means outside the scope of the Pro-
tocol). For Physical Terminations, all instances of a Termination are
instantiated by the MG when it restarts (or potentially by some adminis-
trative provisioning means). Ephemeral Terminations are instantiated by
the Add command, and destroyed by the Subtract command.
The "highest order" (first component of a hierarchical name) termination
has a full set of properties that can be altered by the MGC; they
represent default values for fully instantiated Terminations. The Pro-
file defines the initial default values assumed by the Termination upon
MG restart.
1.1.5. Termination Dynamics
As Terminations are Added or Moved it is necessary to specify state and As Terminations are Added or Moved it is necessary to specify state and
media parameters for, Events to be detected on, and Signals to be media parameters for, Events to be detected on, and Signals to be
applied to such Terminations within the Context in which they exist. It applied to such Terminations within the Context in which they exist. It
may also be necessary during the life of a Termination within a Context may also be necessary during the life of a Termination within a Context
to Modify these properties. to Modify these properties.
For Terminations representing physical entities it might also be desir- For Terminations representing physical entities it might also be desir-
able to Modify their properties as they are Subtracted from a Context. able to Modify their properties as they are Subtracted from a Context.
This may be the case if a configuration different to the one provided by This may be the case if a configuration different to the one provided by
the TerminationClass defaults is needed. Such Terminations may also the defaults is needed. Such Terminations may have their properties
have their properties Modified outside of their existence within a Con- Modified outside of their existence within a Context.
text.
The protocol assumes that it is the MG that is responsible for creating
Internet draft MEGACO Protocol April 16, 1999
the network connection to the other side of the call. The MGC directs
that it do so by, for example, creating an RTP termination, which would
have the side effect of causing the MG to create an RTP flow to the
other party. On an ATM network using SVCs, it is the MG that would use,
for example, UNI to create a bearer connection.
The Add, Subtract, Move and Modify commands may affect the following The Add, Subtract, Move and Modify commands may affect the following
sets of properties: sets of properties:
* TerminationState: A list of properties that define the state of the * TerminationState: A list of properties that define the state of the
Termination, but which are not directly linked to the description Termination, but which are not directly linked to the description
of a media flow, to an event list or to a signal list. of a media flow, to an Event list or to a Signal list.
* LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists
of properties describing the processing of the media flow in each of properties describing the processing of the media flow in each
direction. direction.
* EventsDescriptor: A list of events that should be detected on the * EventsDescriptor: A list of Events that should be detected on the
Internet draft MEGACO Protocol Proposal March 25, 1999
Termination. Termination.
* SignalDescriptor: A list of signals that should be applied on the * SignalDescriptor: A list of Signals that should be applied on the
Termination. Termination.
For example, the Add Command has the following form: For example, the Add Command has the following form:
Add(TerminationId, Add(TerminationId,
[LocalTerminationState,] [LocalTerminationState,]
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
[EventsDescriptor,] [EventsDescriptor,]
[SignalDescriptor]) [SignalDescriptor])
All parameters listed are optional except for the TerminationId. This All parameters listed are optional except for the TerminationId. This
allows each command to specify exactly what needs to be modified. Addi- allows each command to specify exactly what needs to be modified. Addi-
tionally, some parameters may not be required for certain TerminationC- tionally, some parameters may not be required for certain TerminationC-
lasses. For instance, DS0s do not use RemoteTerminationDescriptors. lasses. For instance, DS0s do not use RemoteTerminationDescriptors.
These descriptors are used only for the packet TerminationClasses. These descriptors are used only for packet TerminationClasses.
A Termination is programmed to look for specific events through the A Termination is programmed to look for specific Events through the
EventsDescriptor, which is a parameter to Add, Modify and Subtract. EventsDescriptor, which is a parameter to Add, Modify and Subtract.
When a Termination detects an event that matches the types of events it When a Termination detects an Event that matches the types of Events it
is programmed to detect, the MG generates a Notify command. is programmed to detect, the MG generates a Notify command.
The MG can generate a ServiceChange message. ServiceChange has a number The MG can generate a ServiceChange message. ServiceChange has a number
of uses: Registration of an MG with an MGC, notification of imminent of uses: Registration of an MG with an MGC, notification of imminent
downtime for one or more Terminations, notification that one or more downtime for one or more Terminations, notification that one or more
Terminations has already gone down, and notification that one or more
Terminations have been brought back into service. Internet draft MEGACO Protocol April 16, 1999
Terminations has already gone out of service, and notification that one
or more Terminations have been brought back into service.
Detailed definitions of Commands and their Responses are provided in Detailed definitions of Commands and their Responses are provided in
Section 2. Section 2.
1.1.5. Issuing Commands in Transactions 1.1.6. Issuing Commands in Transactions
The protocol has been designed to allow multiple Commands to be packed The protocol has been designed to allow multiple Commands to be packed
in single TransactionRequest. The corresponding Responses are received in single TransactionRequest. The corresponding Responses are received
in a single Transaction reply. There are two types of replies, a Tran- in a single Transaction reply. There are two types of replies, a Tran-
sactionAccept and a TransactionReject. A Transaction allows Commands to sactionAccept and a TransactionReject. A Transaction allows Commands to
share fate and guarantees ordered processing. share fate and guarantees ordered processing. Multiple Transactions
may, in turn, be packed into a single message.
Commands in a Transaction are executed sequentially according to an "all Commands in a Transaction are executed sequentially according to an "all
or nothing rule". That is, a TransactionAccept includes successful or nothing rule". That is, a TransactionAccept includes successful
Responses for ALL the Commands in the corresponding TransactionRequest. Responses for ALL the Commands in the corresponding TransactionRequest.
Internet draft MEGACO Protocol Proposal March 25, 1999
A TransactionReject is sent when one of the Commands included in the A TransactionReject is sent when one of the Commands included in the
Transaction fails. Responses for the Commands in a TransactionReject Transaction fails. Responses for the Commands in a TransactionReject
are issued as follows: are issued as follows:
* All Commands before the point of failure in the Command sequence * All Commands before the point of failure in the Command sequence
should have a Response equal to "non-executed". should have a Response equal to "non-executed".
* The failed Command should have a Response with a Reason Code. * The failed Command should have a Response with a Reason Code.
* Commands after the point of failure are not processed and, there- * Commands after the point of failure are not processed and, there-
fore, Responses are not issued for them. fore, Responses are not issued for them.
The parsing mechanism described in the coding section (section 3) speci- The parsing mechanism described in the coding section (section 3) speci-
fies how responses or reason codes are associated with individual Com- fies how responses or reason codes are associated with individual Com-
mands. mands.
When a MGC issues Commands to a MG, a Context must always be specified. When a MGC issues Commands to a MG, a Context must always be specified.
This is quite natural for Add and Subtract. For Modify Commands on a This is quite natural for Add and Subtract. For Modify Commands on a
Termination that is not in a Context, the NULL context must be speci- Termination that is not in a Context, the null Context must be speci-
fied. A Move Command clearly involves two Contexts, however only the fied, which changes the default values of properties for that Termina-
target context needs to be specified. Within a Transaction, all Com- tion. A Move Command clearly involves two Contexts, however only the
mands that apply to a Context must appear after the ContextId parameter. target Context needs to be specified (i.e. the Move has the semantics of
"Move-To"). Within a Transaction, all Commands that apply to a Context
must appear after the ContextId parameter.
The following lines illustrate (i.e., syntax is ad-hoc and actions some- The following lines illustrate (i.e., syntax is ad-hoc and actions some-
what simplified) the use of Transactions in the call-waiting example of what simplified) the use of Transactions in the call-waiting example of
section 1.1.1. The Transaction that creates the second Context, applies section 1.1.1. The Transaction that creates the second Context, applies
signals to Termination T1 (to indicate call-waiting) and detects events Signals to Termination T1 (to indicate call-waiting) and detects Events
from T1 (to swap the call) is formed as follows: from T1 (to swap the call) is formed as follows:
Internet draft MEGACO Protocol April 16, 1999
Transaction(TransactionId=12345 Transaction(TransactionId=12345
ContextId=* Add(T3) ContextId=* Add(T3)
ContextId=C1 Modify(T1, EventDescriptor, SignalDescriptor) ) ContextId=C1 Modify(T1, EventDescriptor, SignalDescriptor) )
The Commands in this Transaction are processed sequentially. First, the The Commands in this Transaction are processed sequentially. First, the
MG creates a Context to Add T3. Second, T1 is programmed to signal the MG creates a Context to Add T3. Second, T1 is programmed to Signal the
waiting call and collect the events that operate the call-waiting waiting call and collect the Events that operate the call-waiting
feature. feature.
The next Transaction shows the Commands issued by the MGC to swap the The next Transaction shows the Commands issued by the MGC to swap the
Terminations. Terminations.
Transaction(TransactionId=12346 Transaction(TransactionId=12346
ContextId=C2 Move(T1) Modify(T3, TerminationState) ContextId=C2 Move(T1) Modify(T3, TerminationState)
ContextId=C1 Modify(T2, TerminationState) ) ContextId=C1 Modify(T2, TerminationState) )
Again, the Commands in this Transaction are processed sequentially. Again, the Commands in this Transaction are processed sequentially.
Internet draft MEGACO Protocol Proposal March 25, 1999
First, the MG moves T1 from C1 into C2. Then it modifies the Mode of T3 First, the MG moves T1 from C1 into C2. Then it modifies the Mode of T3
to Sendrecv. Finally, T2 in C1 is set to Receive Mode. to Sendrecv. Finally, T2 in C1 is set to Receive Mode.
1.1.6. Sample Command Flow 1.1.7. Sample Command Flow
This section presents an illustration of the use of the protocol Com- This section presents an illustration of the use of the protocol Com-
mands to establish a communication between two Residential Gateways over mands to establish a communication between two Residential Gateways over
an IP trunking network, both MGs are under the control of the same MGC. an IP trunking network, both MGs are under the control of the same MGC.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
|Step | User | ResMG | MGC | ResMGr | User | |Step | User | ResMG | MGC | ResMGr | User |
|_____|___________|_____________|________________|_____________|___________| |_____|___________|_____________|________________|_____________|___________|
| 0| | <------CTX=null,Modify(T1) | | | 0| | <------CTX=null,Modify(T1) | |
| | | Resp-------------> | | | | | | Resp-------------> | | |
| | | (Ok,ready, looking for Off-hook) | | | | | (Ok,ready, looking for Off-hook) | |
| 1| Off-hook | Notify----------------> | | | | 1| Off-hook | Notify----------------> | | |
| | | | (off-hook recorded) | | | | | | (off-hook recorded) | |
| | | <--------------Resp(Ok)| | | | | | <--------------Resp(Ok)| | |
| 2|Acc Digits | | | | | | 2|Acc Digits | | | | |
skipping to change at page 14, line 5 skipping to change at page 14, line 5
| | | | | | | | | | | | | |
| 13| | | <------------- Notify | Off-hook | | 13| | | <------------- Notify | Off-hook |
| 14| | | Resp(Ok)----------> | | | 14| | | Resp(Ok)----------> | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| 15| | <------CTX=C1 Modify(T1,TerminalState=Sendrcv | | 15| | <------CTX=C1 Modify(T1,TerminalState=Sendrcv |
| | | | | SignalList) | | | | | | | SignalList) | |
| 16| | CTX=C1 ---------> | | | | 16| | CTX=C1 ---------> | | |
| | | Resp(Ok) | | | | | | | Resp(Ok) | | | |
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
CTX = ContextID CTX = ContextID
Step 0: Step 0:
The MGC issues a Modify Command to request that T1 detect an Off- The MGC issues a Modify Command to request that T1 detect an Off-
hook and proceed with digit collection hook and proceed with digit collection
Step 1: Step 1:
The Off-hook is detected, the Notify Command is issued and the The Off-hook is detected, the Notify Command is issued and the
Off-hook recorded for billing purposes. Off-hook recorded for billing purposes.
Step 2: Step 2:
The termination collects and accumulates digits according to an The Termination collects and accumulates digits according to an
appropriate digit map. appropriate digit map.
Step 3: Step 3:
The collected digits are sent to the MGC in a Notify Command. The collected digits are sent to the MGC in a Notify Command.
Step 4: Step 4:
The MGC acknowledges the digit string. The MGC acknowledges the digit string.
Step 5: Step 5:
After determining that the digit string is valid to initiate a After determining that the digit string is valid to initiate a
call, the MGC uses the Add Command to create a Context that call, the MGC uses the Add Command to create a Context that
includes T1 and a yet unnamed ephemeral packet Termination (RTP/*). includes T1 and a yet unnamed ephemeral packet Termination (RTP/*).
The RTP Termination receives only a LocalTerminationDescriptor that The RTP Termination receives only a LocalTerminationDescriptor that
specifies, for instance, a choice of Codecs. specifies, for instance, a choice of codecs.
Step 6: Step 6:
The reply to the Add Command includes a named Context (C1) and a The reply to the Add Command includes a named Context (C1) and a
named RTP Termination (RTP/Id) with its LocalTerminationDescriptor named RTP Termination (RTP/Id) with its LocalTerminationDescriptor
including supported Codecs and the receiving RTP port. including supported Codecs and the receiving RTP port.
Step 7: Step 7:
The MGC can now instruct the remote Residential MG to Add the ter- The MGC can now instruct the remote Residential MG to Add the Ter-
mination that corresponds to the dialed string (e.g., T1r) and a mination that corresponds to the dialed string (e.g., T1r) and a
corresponding RTP Termination in a Context. The information corresponding RTP Termination in a Context. The information
returned in T1's LocalTerminationDescriptor is passed to the remote returned in T1's LocalTerminationDescriptor is passed to the remote
Residential MG in the RemoteTerminationDescriptor. The LocalTer- Residential MG in the RemoteTerminationDescriptor. The LocalTer-
minationDescriptor specifies the Codecs for T1r. minationDescriptor specifies the Codecs for T1r.
Step 8: Step 8:
The reply to the Add Command includes a named Context (C1r) and a The reply to the Add Command includes a named Context (C1r) and a
named RTP Termination (RTP/Idr) with its LocalTerminationDescriptor named RTP Termination (RTP/Idr) with its LocalTerminationDescriptor
including supported Codecs and the receiving RTP port. including supported Codecs and the receiving RTP port.
Step 9: Step 9:
The MGC can now request that Ringing be applied on T1r. The Modify The MGC can now request that Ringing be applied on T1r. The Modify
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Command is used for this. Looking for Off-hook is simultaneously Command is used for this. Looking for Off-hook is simultaneously
programmed in T1r. programmed in T1r.
Step 10: Step 10:
The Response indicating that Ringing is applied is sent to the MGC. The Response indicating that Ringing is applied is sent to the MGC.
Step 11: Step 11:
Two Modify commands are issued in this Transaction. The first Two Modify commands are issued in this Transaction. The first
requests that Ring-back be applied to T1. The second provides the requests that Ring-back be applied to T1. The second provides the
skipping to change at page 15, line 54 skipping to change at page 15, line 54
where a specific ContextID is not provided. One is the case of modifi- where a specific ContextID is not provided. One is the case of modifi-
cation of a Termination outside of a Context. The other is where the cation of a Termination outside of a Context. The other is where the
controller requests the gateway to create a new Context. Each of these controller requests the gateway to create a new Context. Each of these
two cases has a distinguished value for ContextID two cases has a distinguished value for ContextID
An Action consists of a series of Commands (Add, Subtract, Modify, Move, An Action consists of a series of Commands (Add, Subtract, Modify, Move,
etc.). These Commands have very similar parameters, which may include: etc.). These Commands have very similar parameters, which may include:
* TerminationState: A list of properties that define the state of the * TerminationState: A list of properties that define the state of the
Termination, but which are not directly linked to the description Termination, but which are not directly linked to the description
of a media flow, to an event list, or to a signal list. This of a media flow, to an Event list, or to a Signal list. This
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
includes a description of the media handling at the Termination includes a description of the media handling at the Termination
(e.g., the Mode parameter that indicates loopback, COT, etc.) and a (e.g., the Mode parameter that indicates loopback, COT, etc.) and a
description of the handling of accumulated events that are pending description of the handling of accumulated Events that are pending
for processing (i.e., "quarantined events"). for processing (i.e., "buffered events").
* LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists
of properties describing the processing of the media flow in each of properties describing the processing of the media flow in each
direction. These are expressed in the form of SDPdescriptors[ref]. direction. These are expressed in the form of SDPdescriptors[ref].
* EventsDescriptor: A list of Events that should be detected on the * EventsDescriptor: A list of Events that should be detected on the
Termination. These Events must be supported by the Package(s) of Termination. These Events must be supported by the Package(s) of
the TerminationClass. The EventDescriptor can be augmented by a the TerminationClass. The EventDescriptor can be augmented by a
DigitMap. DigitMap.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
tionDescriptor, RemoteTerminationDescriptor, or a Statistics summary. tionDescriptor, RemoteTerminationDescriptor, or a Statistics summary.
2.1. Names and Common Parameters 2.1. Names and Common Parameters
2.1.1. Context Identifiers 2.1.1. Context Identifiers
Contexts are identified by a ContextID, which is assigned by the Media Contexts are identified by a ContextID, which is assigned by the Media
Gateway and is unique within the scope of the Media Gateway. The proto- Gateway and is unique within the scope of the Media Gateway. The proto-
col makes reference to two distinguished values: col makes reference to two distinguished values:
* The "null" context, which is used to refer to a Termination outside * The null Context, which is used to refer to a Termination outside
of a Context. When used with a Modify Command, such a reference of a Context. When used with a Modify Command, such a reference
changes the default values for the Termination. changes the default values for the Termination.
* The "unspecified" Context, which is used to request that the MG * The "unspecified" Context, which is used to request that the MG
create a new Context. The actual ContextID must be returned to the create a new Context. The actual ContextID must be returned to the
MGC for subsequent use. MGC for subsequent use.
2.1.2. Termination Names 2.1.2. Termination Names
Names for Terminations are hierarchical. A separation character delim- Names for Terminations (called a "TerminationID") are hierarchical. A
its the components of a name from one another. An example name in a separation character delimits the components of a name from one another.
Termination class that implements a channelized T3 is "com1/3/17". This An example name in a Termination Class that implements a channelized T3
name refers to a T3 called "com1", the "3" specifies the 3rd DS1 in the is "com1/3/17". This name refers to a T3 called "com1", the "3"
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
T3. The "17" specifies the 17th DS0 (timeslot) in the DS1. specifies a specific DS1 in the T3. The "17" specifies a specific DS0
in the DS1.
Names in Commands may use wildcards. Two wildcard constructs are pro- There is a special Termination called "Root". Root refers to the MG
vided: "all" and "choose". The "all" construct allows a Command to itself.
specify all possible values of a name component. One can, for example,
TerminationIDs in Commands may use wildcards. Two wildcard constructs
are provided: "all" and "choose". The "all" construct allows a Command
to specify all possible values of a component. One can, for example,
use "all" to refer to all DS1s of a T3 (com1/*). use "all" to refer to all DS1s of a T3 (com1/*).
When an ephemeral Termination is to be created, the name is given with When an Ephemeral Termination is to be created, the TerminationID may
the last component specified as "choose". The MG must create a fully given with the last component specified as "choose". The MG would
instantiated Termination and supply a unique name which must be returned create a fully instantiated Termination and supply a unique name which
to the MGC and be used for subsequent Transactions. must be returned to the MGC and be used for subsequent Transactions.
The MGC may supply a unique TerminationID, in which case the MG is
obliged to use that name. MGs MAY refuse a request to choose a name, in
which case they must return an appropriate error code
2.1.3. Specifying Properties 2.1.3. Specifying Properties
Commands may include descriptors. Each descriptor has a set of legal Commands may include descriptors. Each descriptor has a set of legal
properties that may be included, which is part of the definition of the properties that may be included, which is part of the definition of the
Termination class (properties legal for TerminationState, LocalTermina- Termination Class (properties legal for TerminationState, LocalTermina-
tionDescriptor and RemoteTerminationDescriptor), or package (properties tionDescriptor and RemoteTerminationDescriptor), or Package (properties
legal for EventDescriptor or SignalDescriptor). In a descriptor, each legal for EventDescriptor or SignalDescriptor). In a descriptor, each
of the properties may be fully specified, under-specified, or unspeci- of the properties may be fully specified, under-specified, or unspeci-
fied. fied.
* Fully specified properties have a single, unambiguous value that * Fully specified properties have a single, unambiguous value that
the MGC instruct the MG to use for the specified parameter the MGC instruct the MG to use for the specified parameter
* Under-specified properties have a list of potential values. The MG * Under-specified properties have a list of potential values. The MG
chooses one value from the offered list, and returns the value it chooses one value from the offered list, and returns the value it
chose to the MGC. A common example is choice of codec. The MGC chose to the MGC. A common example is choice of codec. The MGC
may allow the MG to choose from G.729a, G.723 or G.711. The MG's may allow the MG to choose from G.729a, G.723 or G.711. The MG's
choice may be limited based on availability of DSP resources at the choice may be limited based on availability of DSP resources at the
time the request was made. The order in which the MGC presents time the request was made. The order in which the MGC presents
choices to the MG represents the MGCs order of preference for the choices to the MG represents the MGCs order of preference for the
values offered, which the MG is encouraged, but not obligated to values offered, which the MG is encouraged, but not obligated to
respect. respect.
* Unspecified properties (legal properties which do not occur in the * Unspecified properties (legal properties which do not occur in the
descriptor) result in the MG retaining the previous value for that descriptor) result in the MG retaining the previous value for that
parameter. parameter. Each property has a default value, which is the value
assumed by the property when it is not part of a context, or when
the Termination is added to a Context but not assigned a specific
value when added. Default values can be changed by the MGC.
Editor's note: We need to have the syntax able to express mutually- Internet draft MEGACO Protocol April 16, 1999
exclusive options. In other words, "I can do GSM-FR if I don't do any
G.729 at the same time" this is very useful for limited DSP-only dev-
ices, and is a requirement for H.245 semantics.
2.1.4. Termination State Properties 2.1.4. Termination State Properties
TerminationState groups a list of properties that define the state of TerminationState groups a list of properties that define the state of
the Termination, but are not directly linked to a media flow, to an the Termination, but are not directly linked to a media flow, to an
Event list or to a Signal list. These properties are:
Internet draft MEGACO Protocol Proposal March 25, 1999
event list or to a signal list. These properties are:
* TerminationMode * TerminationMode
* QuarantineProcessing * EventBufferProcessing
* QuarantineNotification * EventBufferNotification
The TerminationMode parameter indicates the relation between the Termi- The TerminationMode parameter indicates the relation between the Termi-
nation and the "star" connection of the context. The mode are "send nation and the "star" connection of the Context. The mode are "send
only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv),
"inactive" (inactive), "outofservice", "loopback" and "continuity test" "inactive" (inactive), "outofservice" and "test" (test).
(conttest).
The handling of the media received on the Termination is determined by The handling of the media received on the Termination is determined by
the TerminationMode parameter value: the TerminationMode parameter value:
* Termination whose mode is "send", "conference" or "send/receive" * Termination whose mode is "send", or "send/receive" receive the
receive the signals mixed in the context, according to media signals mixed in the Context, according to media specific rules -
specific rules - audio Terminations for example, will receive the audio Terminations for example, will receive the sum of the audio
sum of the audio flows coming from all other Terminations, exclud- flows coming from all other Terminations, excluding those coming
ing those coming from this specific Termination. from this specific Termination.
* The "loopback" and "continuity test" modes are used during mainte-
nance and continuity test operations. There are two flavors of con-
tinuity test, one specified by ITU and one used in the US, also
referred to as "four wire" and "two wire". In the first case, the
test is a loopback test. The originating switch or MG will send a
tone (the go tone) on the bearer circuit and expect the terminating
switch or MG to loopback the circuit. If the originating entity
sees the same tone returned (the return tone), the COT has passed.
If not, the COT has failed. In the second case, the go and return
tones are different. The originating entity sends a certain go
tone. The terminating entity detects the go tone, it asserts a dif-
ferent return tone in the backwards direction. When the originating
entity detects the return tone, the COT is passed. If the originat-
ing entity never detects the return tone, the COT has failed.
Editor's Note: There is debate over whether the protocol can, or should,
specify all forms of testing in the mode. If it does so, a more exhaus-
tive list must be provided. If that is not appropriate, it may be
preferable to define only one mode, "test", and then define events and
signals for specific tests. Clearly the initiation of any test is MGC-
driven, this needs to be spelled out (flows explaining for SCN and
MEGACO originated/transit/terminated tests)]
The optional QuarantineProcessing and QuarantineNotification descriptors
specifies the handling of "quarantined" events, i.e. events that have
Internet draft MEGACO Protocol Proposal March 25, 1999 * The "test" mode is used during maintenance and continuity test
operations. There are several defined Packages that implement vari-
ous forms of tests that can be applied to a Termination.
The optional EventBufferProcessing and EventBufferNotification descrip-
tors specifies the handling of "buffered" Events, i.e. Events that have
been detected by the MG before the arrival of an EventsDescriptor, but been detected by the MG before the arrival of an EventsDescriptor, but
have not yet been notified to the MGC. have not yet been notified to the MGC.
* QuarantineProcessing specifies whether the quarantined events * EventBufferProcessing specifies whether the buffered Events should
should be processed or discarded (the default is to process them.) be processed or discarded (the default is to process them.)
* QuarantineNotification specifies whether the MG is expected to gen- * EventBufferNotification specifies whether the MG is expected to
erate at most one notification (step by step), or multiple notifi- generate at most one notification (step by step), or multiple
cations (loop), in response to this request (the default is exactly notifications (loop), in response to this request (the default is
one.) at most one.)
2.1.5. Termination Descriptors 2.1.5. Termination Descriptors
The LocalTerminationDescriptor and RemoteTerminationDescriptor parame- The LocalTerminationDescriptor and RemoteTerminationDescriptor parame-
ters describe the processing of the media flow in each of the direc- ters describe the processing of the media flow in each of the direc-
tions. The actual properties of each descriptor depend of the Termina- tions. The actual properties of each descriptor depend on the Profiles
tion class. Examples of Termination classes are RTP, Analog, DS0. For
an RTP Termination, for example, some of the properties might be: Internet draft MEGACO Protocol April 16, 1999
specified for Termination Class. Examples of Termination Classes are
RTP, Analog, DS0. For an RTP Termination, for example, some of the pro-
perties might be:
* IP address, * IP address,
* UDP ports (RTP and RTCP), * UDP ports (RTP and RTCP),
* Encoding Method, * Encoding Method,
* Packetization period, * Packetization period,
The LocalTerminationDescriptor and RemoteTerminationDescriptor are The LocalTerminationDescriptor and RemoteTerminationDescriptor are
described in the form of an SDP descriptor which is part of the defini- described in the form of an SDP descriptor which is part of the defini-
tion of the Termination class. These sets of properties can be enhanced tion of a Profile. These sets of properties can be enhanced by vendor
by vendor specific optional or mandatory extensions. Properties in the specific optional or mandatory extensions. Properties in the LocalTer-
LocalTerminationDescriptor and the RemoteTerminationDescriptor may be minationDescriptor and the RemoteTerminationDescriptor may be fully
fully specified, under-specified or (by omission) unspecified as specified, under-specified or (by omission) unspecified as described
described above. above.
Editor Note: Using SDP supposes resolution of a few questions. We
have to make sure that we can associate a unique SDP profile for
each Termination class. We also have to register additional pro-
perties to make sure that we cover all the media types that we
need, and that we can support all the current variations of H.245.
The simultaneous and mutually-exclusive capabilities in H.245 have
no way of being described in SDP, as it is linear. Support of
H.245 is mandatory.
2.1.6. Events, Signals and Packages 2.1.6. Events, Signals and Packages
The MGC may ask to be notified about certain events occurring on an Ter- The MGC may ask to be notified about certain Events occurring on a Ter-
mination, e.g. off-hook events, and a MGC may request certain signals to mination, e.g. off-hook Events, and a MGC may request certain Signals to
be applied to a Termination, e.g. dial-tone.
Internet draft MEGACO Protocol Proposal March 25, 1999
be applied to an Termination, e.g. dial-tone.
Events and signals are grouped in Packages within which they share the Events and Signals are grouped in Packages within which they share the
same namespace which we refer to as event names. Packages are groupings same namespace which we refer to as Event names. Packages are groupings
of the events and that are related. For instance, one package may sup- of the Events and that are related. For instance, one Package may sup-
port a certain group of events and signals for Simple analog access port a certain group of Events and Signals for Simple analog access
lines, and another package may support another group of events and sig- lines, and another Package may support another group of Events and Sig-
nals for video lines. One or more packages may exist for a given Termi- nals for video lines. One or more Packages may applicable for a given
nation class, and part of the description of the Termination class con- Termination Class, and part of the description of the Termination Class
sists of a list of supported packages. consists of a list of supported Packages.
Event names are composed of two logical parts, a package name and an Event names are composed of two logical parts, a Package name and an
event name. Examples of package names are DTMF, MF, Trunk or Line. Exam- Event name. Examples of Package names are DTMF, MF, Trunk or Line. Exam-
ples of event names are off hook, flash hook or "0" (the digit zero). ples of Event names are off hook, flash hook or "0" (the digit zero).
This document defines a basic set of package names and event names. This document defines a basic set of Package names and Event names.
Additional package names and event names can be registered with the Additional Package names and Event names can be registered with the
IANA. A package definition shall define the name of the package, and the IANA. A Package definition shall define the name of the Package, and the
definition of each event belonging to the package. The event definition definition of each Event belonging to the Package. The Event definition
shall include the precise name of the event (i.e., the code used in the shall include the precise name of the Event (i.e., the code used in the
MEGACO protocol), a plain text definition of the event, and, went MEGACO protocol), a plain text definition of the Event, and, went
appropriate, the precise definition of the corresponding signals, for appropriate, the precise definition of the corresponding Signals, for
example the exact frequencies of audio signal such as dial tones or DTMF example the exact frequencies of audio signal such as dial tones or DTMF
tones. tones.
Internet draft MEGACO Protocol April 16, 1999
Signals are divided into different types depending on their behavior: Signals are divided into different types depending on their behavior:
* On/off (OO) * On/off (OO)
Once applied, these signals last forever until they are turned off. Once applied, these Signals last forever until they are turned off.
This may happen either as the result of an event or a new SignalRe- This may happen either as the result of an Event or a new SignalRe-
quests (see later). quests (see later).
* Time-out (TO) * Time-out (TO)
Once applied, these signals last until they are either turned off Once applied, these Signals last until they are either turned off
(by an event or SignalRequests) or a signal specific period of time (by an Event or SignalRequests) or a Signal specific period of time
has elapsed. Depending on package specifications, a signal that has elapsed. Depending on Package specifications, a Signal that
times out may generate an "operation complete" event. times out may generate an "operation complete" Event.
* Brief (BR) * Brief (BR)
The duration of these signals is so short, that they stop on their The duration of these Signals is so short, that they stop on their
own. If an event occurs the signal will not stop, however if a new own. If an Event occurs the Signal will not stop, however if a new
SignalRequests is applied, the signal will stop. SignalRequests is applied, the Signal will stop.
Editor's Note: this point should be debated. One could make a case that
events such as strings of DTMF digits should in fact be allowed to com-
plete.)
TO signals are normally used to alert the Terminations' users, to signal
Internet draft MEGACO Protocol Proposal March 25, 1999
TO Signals are normally used to alert the Terminations' users, to signal
them that they are expected to perform a specific action, such as hang them that they are expected to perform a specific action, such as hang
down the phone (ringing). Transmission of these signals should typically down the phone (ringing). Transmission of these Signals should typically
be interrupted as soon as the first of the requested events has been be interrupted as soon as the first of the requested Events has been
produced. produced.
2.1.7. SignalDescriptors 2.1.7. SignalDescriptors
A SignalDescriptor is a parameter that contains the set of signals that A SignalDescriptor is a parameter that contains the set of Signals that
the MG is asked to apply to the Termination, such as, for example ring- the MG is asked to apply to the Termination, such as, for example ring-
ing, or continuity tones. Signals are identified by their name, which is ing, or continuity tones. Signals are identified by their name, which is
an event name, (and thus part of a package)and may be qualified by pro- an Event name, (and thus part of a Package)and may be qualified by pro-
perties. perties.
If a signal has already been attached to this Termination, the previous If a Signal has already been attached to this Termination, the previous
signal is removed, and the specified one is attached. No events which Signal is removed, and the specified one is attached. No Events which
would have occurred on the previous signal will be generated subsequent would have occurred on the previous Signal will be generated subsequent
to a command that modifies the signal descriptor, although the MGC may to a command that modifies the Signal descriptor, although the MGC may
not have received an event from the previous signal prior to sending the not have received an Event from the previous Signal prior to sending the
command, and in fact the MG may have detected such an event, but may not command, and in fact the MG may have detected such an Event, but may not
have notified the MGC of it when it receives the new command. The have notified the MGC of it when it receives the new command. The
behavior of the MG in such a circumstance is not defined. It may send behavior of the MG in such a circumstance is not defined. It may send
the notification, or it may flush it. the notification, or it may flush it.
Editors note: we should think through this. What if you expected an
event after a brief signal, but never get it? Is that always okay?
Should we define behavior (notify or flush?). Note that the MGC always
has to handle either case. Possibly we define that a notify is always
sent, but with a "superceded" qualifier to let the MGC know that it was
replaced. Also, what about the case of Terminations that can handle
playback of more then one signal at a time?
2.1.8. EventDescriptors 2.1.8. EventDescriptors
The EventDescriptor parameter contains a RequestIdentifier and a list of The EventDescriptor parameter contains a RequestIdentifier and a list of
events that the MG is requested to detect and report. Such events Events that the MG is requested to detect and report. Such Events
include, for example, fax tones, continuity tones, or on-hook transi- include, for example, fax tones, continuity tones, or on-hook transi-
tion. The RequestIdentifier is used to correlate this request with the tion. The RequestIdentifier is used to correlate this request with the
notifications that it may trigger.
To each event is associated a notification action, an optional set of Internet draft MEGACO Protocol April 16, 1999
embedded events and signal descriptors, and an optional Termination
management action. The notification actions are:
* Notify the event immediately, together with the accumulated list of notifications that it may trigger.
observed events,
* Accumulate the event in an event buffer, but don't notify yet, To each Event is associated a notification action and an optional set of
embedded Events and Signal descriptors. The notification actions are:
Internet draft MEGACO Protocol Proposal March 25, 1999 * Notify the Event immediately, together with the accumulated list of
observed Events,
* Accumulate the Event in an Event buffer, but don't notify yet,
* Accumulate according to a specified Digit Map, * Accumulate according to a specified Digit Map,
* Treat the event according to a specific script, * Treat the Event according to a specific script,
* Ignore the event. (Events that are not specified in the descriptor * Ignore the Event. (Events that are not specified in the descriptor
are, by default, ignored.) are, by default, ignored.)
The embedded signal descriptor, if present, is used as a replacement for The embedded Signal descriptor, if present, is used as a replacement for
the current signal descriptor. It is possible, for example, to specify the current Signal descriptor. It is possible, for example, to specify
that the dial-tone signal be generated when an off-hook event is 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, or that the dial-tone Signal be stopped when a digit is
detected. If no embedded signal descriptor is specified, the production detected. If no embedded Signal descriptor is specified, the production
of signals continues as specified in the command. of Signals continues as specified in the command.
Editor's note: Embedded events are defined in lieu of a more robust
scripting mechanism. If and when such a mechanism is defined, this
mechanism may be deprecated or removed [backward compatibility??].
The embedded events descriptor, if present, is used as a replacement for The embedded Events descriptor, if present, is used as a replacement for
the current event descriptor. It is possible, for example, to specify the current Event descriptor. It is possible, for example, to specify
that DTMF digit collection starts as soon as an off-hook event is that DTMF digit collection starts as soon as an off-hook Event is
detected. detected.
MEGACO Protocol implementations must be able to support at least one MEGACO Protocol implementations must be able to support at least one
level of embedding. An embedded events descriptor that respects this level of embedding. An embedded Events descriptor that respects this
limitation shall not contain another Embedded events descriptor. limitation shall not contain another Embedded Events descriptor.
Editor's note: Swap Termination is defined in lieu of a more robust
scripting mechanism. If and when such a mechanism is defined, this
mechanism may be deprecated or removed (backwards compatibility??).
Also, we need a way for the MG to notify (exactly) the MGC of the state
change
Only one Termination management action is defined, the Swap Termination
action. It can be used when a context contains more than one active Ter-
mination, in addition to the Termination on which the triggering event
is detected. The Swap Termination assumes that the Terminations are
assigned an order in the context. The action modifies the Termination
Mode parameter of the Terminations in the following fashion:
* The mode of the Termination on which the event is detected remains
unchanged.
* The Termination mode of the other currently active Terminations is
set to "inactive."
* The termination mode of the "next" active termination is set to
"send-receive."
Internet draft MEGACO Protocol Proposal March 25, 1999
This action can be used to implement call waiting, and possibly other
feature scenarios, without incurring a round-trip to the MGC when just
changing which termination is active. The EventsDescriptor can map an
event (usually hook flash, but could be some other event) to a local
function swap audio, which selects the "next" termination in a round
robin fashion. If there is only one termination, this action is effec-
tively a no-op.
2.1.9. Digit Maps 2.1.9. Digit Maps
The MGC can ask the MG to collect digits dialed by the user. This facil- The MGC can ask the MG to collect digits dialed by the user. This facil-
ity is intended to be used with residential gateways to collect the ity is intended to be used with residential gateways to collect the
numbers that a user dials; it may also be used with trunking gateways numbers that a user dials; it may also be used with trunking gateways
and access gateways alike, to collect the access codes, credit card and access gateways alike, to collect the access codes, credit card
numbers and other numbers requested by call control services. numbers and other numbers requested by call control services.
An alternative procedure is for the MG to notify the MGC of the dialed An alternative procedure is for the MG to notify the MGC of the dialed
digits, as soon as they are dialed. However, such a procedure generates digits, as soon as they are dialed. However, such a procedure generates
a large number of interactions. It is preferable to accumulate the a large number of interactions. It is preferable to accumulate the
dialed numbers in a buffer, and to transmit them in a single message. dialed numbers in a buffer, and to transmit them in a single message.
The problem with this accumulation approach, however, is that it is hard The problem with this accumulation approach, however, is that it is hard
for the gateway to predict how many digits it needs to accumulate before for the gateway to predict how many digits it needs to accumulate before
Internet draft MEGACO Protocol April 16, 1999
transmission. For example, using the phone on our desk, we can dial the transmission. For example, using the phone on our desk, we can dial the
following numbers: following numbers:
_______________________________________________________ _______________________________________________________
| 0 | Local operator | | 0 | Local operator |
| 00 | Long distance operator | | 00 | Long distance operator |
| xxxx | Local extension number | | xxxx | Local extension number |
| 8xxxxxxx | Local number | | 8xxxxxxx | Local number |
| #xxxxxxx | Shortcut to local number at| | #xxxxxxx | Shortcut to local number at|
| | other corporate sites | | | other corporate sites |
| *xx | Star services | | *xx | Star services |
| 91xxxxxxxxxx | Long distance number | | 91xxxxxxxxxx | Long distance number |
| 9011 + up to 15 digits| International number | | 9011 + up to 15 digits| International number |
|________________________|_____________________________| |________________________|_____________________________|
The solution to this problem is to load the MG with a digit map that The solution to this problem is to load the MG with a digit map that
correspond to the dial plan. correspond to the dial plan.
A digit map is defined by a name and a value. The name is "visible" A digit map is defined by a name and a value. The name is "visible"
within a scope, which can be the gateway itself, a hierarchical group of within a scope, which can be the gateway itself, a hierarchical group of
terminations, or a specific termination. Digit maps are provisioned Terminations, or a specific Termination. Digit maps are provisioned
through standard termination management operations such as Add, Modify, through standard Termination management operations such as Add, Modify,
Subtract or Move. The scope of the digit map is determined by the name Subtract or Move. The scope of the digit map is determined by the name
of the termination to which the command is applied: of the Termination to which the command is applied:
Internet draft MEGACO Protocol Proposal March 25, 1999
* If the command is applied to the "all" wildcarded termination, the * If the command is applied to the "all" wildcarded Termination, the
digit map is visible within the scope of the MG, digit map is visible within the scope of the MG,
* If the command is applied to a hierarchical name such as "Com1/3", * If the command is applied to a hierarchical name such as "Com1/3",
the digit map becomes visible within all terminations whose name the digit map becomes visible within all Terminations whose name
begins with the specified prefix. begins with the specified prefix.
The DigitMapDescriptor contains a set of Digit Maps names and values to The DigitMapDescriptor contains a set of Digit Maps names and values to
be assigned: be assigned:
* A new digit map is created by specifying a name that is not yet * A new digit map is created by specifying a name that is not yet
defined at this level of the naming hierarchy. The value must be defined at this level of the naming hierarchy. The value must be
present. present.
* A digit map value is updated by supplying a new value for a name * A digit map value is updated by supplying a new value for a name
that is already defined at this level of the naming hierarchy. that is already defined at this level of the naming hierarchy.
Terminations using the map in an EventDescriptor when it is modi-
fied continue to use the old value. Subsequent EventDescriptors
mentioning the DigitMap use the new value.
* A digit map is deleted by supplying an empty value for a name that * A digit map is deleted by supplying an empty value for a name that
is already defined at this level of the naming hierarchy. A wild- is already defined at this level of the naming hierarchy. A
card naming convention can be used to delete all the digit maps
associated with a specific termination. Internet draft MEGACO Protocol April 16, 1999
wildcard naming convention can be used to delete all the digit maps
associated with a specific Termination.
The MGC can determine defined digit maps with the Audit command. The MGC can determine defined digit maps with the Audit command.
The collection of digits according to a digit map may be protected by an The collection of digits according to a digit map may be protected by an
"interdigit timer", which can take two values: "interdigit timer", which can take two values:
- If the gateway can determine that at least one more digit is - If the gateway can determine that at least one more digit is
requested for the digit string to match any of the allowed patterns requested for the digit string to match any of the allowed patterns
in the digit map, then the timer value should be set to a long in the digit map, then the timer value should be set to a long
duration, such as 16 seconds. duration, such as 16 seconds.
- If the digit map specifies that a variable number of additional - If the digit map specifies that a variable number of additional
digits may be needed (the "." indication at the end of a string), digits may be needed (the "." indication at the end of a string),
then the timer value should be set to a medium duration, such as 8 then the timer value should be set to a medium duration, such as 8
seconds. seconds.
The "long interdigit timer" and the "short interdigit timer" are parame- The "long interdigit timer" and the "short interdigit timer" are parame-
ters associated with a digit map. ters associated with a digit map.
The digit map mechanism is only used to reduce the number of messages
between the MG and the MGC. It does not interpret or translate dialed
digits. The MGC is free to not employ digit maps, and to request an
Event notification per digit.
2.1.10. Statistics 2.1.10. Statistics
The MG may maintain statistics that describe the status of the termina- The MG may maintain statistics that describe the status of the Termina-
tion. The precise properties of the statistics depends on the class of tion. The precise properties of the statistics depends on the Class of
the termination. the Termination.
In the RTP class, the properties might include: In the RTP class, the properties might include:
Internet draft MEGACO Protocol Proposal March 25, 1999
* Number of packets sent: * Number of packets sent:
* Number of octets sent: * Number of octets sent:
* Number of packets received: * Number of packets received:
* Number of octets received: * Number of octets received:
* Number of packets lost: * Number of packets lost:
* Interarrival jitter: * Interarrival jitter:
Internet draft MEGACO Protocol April 16, 1999
2.2. Termination Management Commands 2.2. Termination Management Commands
2.2.1. Add 2.2.1. Add
The Add commands adds a Termination to a Context. The Add commands adds a Termination to a Context.
[TerminationId,] [TerminationId,]
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
<--- Add(TerminationId, <--- Add(TerminationId,
[TerminationState,] [TerminationState,]
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
[EventsDescriptor,] [EventsDescriptor,]
[SignalDescriptor,] [SignalDescriptor,]
[DigitMapDescriptor]) [DigitMapDescriptor])
TerminationId is the identifier of the termination that is being added TerminationId is the name of the Termination that is being added to the
to the context. The TerminationId may be under-specified by using the Context. The TerminationId may be under-specified by using the "choose"
"choose" wildcard convention. This convention must be used for packet wildcard convention. This convention must be used for packet Termina-
terminations. If the TerminationId is under-specified, the actual iden- tions. If the TerminationId is under-specified, the actual identifier
tifier must be assigned by the MG and its complete value returned in the must be assigned by the MG and its complete value returned in the
response. response.
The LocalTerminationState properties can be fully specified or unspeci- The TerminationState properties can be fully specified or unspecified by
fied by the MGC. The MG used the specified value when it is present, the the MGC. The MG uses the specified value when it is present. The pro-
default value for the class of termination otherwise. perty is unmodified if it is not mentioned
The LocalTerminationDescriptor properties can be either fully specified, The LocalTerminationDescriptor properties can be either fully specified,
under-specified or unspecified by the MGC. The MGC may under-specify a under-specified or unspecified by the MGC. The MGC may under-specify a
parameter by providing a loose specification, such as a list of allowed parameter by providing a loose specification, such as a list of allowed
encoding methods or a range of packetization periods. When the value encoding methods or a range of packetization periods. When the value
are under-specified, the MG returns a fully qualified LocalTermination- are under-specified, the MG returns a fully qualified LocalTermination-
Descriptor. When a value is unspecified, the MG uses the default value Descriptor. When a value is unspecified, the MG does not change the
specified for that class of termination. value of a property. Since properties not in a Context have default
values, unspecified properties in an Add will have default values.
Internet draft MEGACO Protocol Proposal March 25, 1999
The RemoteTerminationDescriptor is the Termination descriptor for the The RemoteTerminationDescriptor is the descriptor for the remote side of
remote side of a Termination, for example on the other side of the IP a Termination, for example on the other side of the IP network. It
network. It includes the same fields as in the LocalTerminationDescrip- includes the same fields as in the LocalTerminationDescriptor, i.e. the
tor, i.e. the fields that describe a session according to the SDP stan- fields that describe a session according to the SDP standard. This
dard. This descriptor may be omitted when the information for the remote descriptor may be omitted when the information for the remote end is not
end is not known yet. This information may be provided later via a known yet. This information may be provided later via a Modify command.
ModifyTermination call.
Under-specified properties in RemoteTerminationDescriptor is possible Under-specified properties in RemoteTerminationDescriptor is possible
where the remote side has offered a choice, but the MG may have resource where the remote side has offered a choice, but the MG may have resource
restrictions which prevent the MGC from being able to make the choice. restrictions which prevent the MGC from being able to make the choice.
Internet draft MEGACO Protocol April 16, 1999
When the value of any properties in the descriptor are under-specified, When the value of any properties in the descriptor are under-specified,
the MG returns a fully qualified RemoteTerminationDescriptor. When a the MG returns a fully qualified RemoteTerminationDescriptor. When a
value is unspecified, the MG uses the default value specified for that value is unspecified, the MG does not change the value as described
class of termination. above.
Physical terminations typically would not have a RemoteTermination- Physical Terminations typically would not have a RemoteTermination-
Descriptor, but the termination class defines whether it does or does Descriptor, but the Termination Class defines whether it does or does
not in all cases not in all cases
After receiving an Add command that did not include a RemoteTermination- After receiving an Add command that did not include a RemoteTermination-
Descriptor, a MG is in an ambiguous situation. Because it has received a Descriptor, a MG is in an ambiguous situation. Because it has received a
LocalTerminationDescriptor parameter, it can potentially receive pack- LocalTerminationDescriptor parameter, it can potentially receive pack-
ets. Because it has not yet received the RemoteTerminationDescriptor of ets. Because it has not yet received the RemoteTerminationDescriptor of
the other MG, it does not know whether the packets that it receives have the other MG, it does not know whether the packets that it receives have
been authorized by the MGC. It must thus navigate between two risks, been authorized by the MGC. It must thus navigate between two risks,
i.e. clipping some important announcements or listening to potentially i.e. clipping some important announcements or listening to potentially
unintelligible, or unauthorized data. The behavior of the MG is deter- unintelligible, or unauthorized data. The behavior of the MG is deter-
mined by the value of the Termination Mode element of the Termination- mined by the value of the Termination Mode element of the Termination-
State parameter: State parameter:
* If the mode was set to ReceiveOnly, the MG should accept the voice * If the mode was set to ReceiveOnly, the MG should accept the voice
signals and transmit them through the termination. signals and transmit them through the Termination.
* If the mode was set to Inactive, Loopback, Continuity Test, the MG * If the mode was set to Inactive, Loopback, Continuity Test, the MG
should ignore the voice signals. should ignore the voice signals.
Note that the mode values SendReceive and SendOnly don't make sense in Note that the mode values SendReceive and SendOnly don't make sense in
this situation. They should be treated as errors, and the command should this situation. They should be treated as errors, and the command should
be rejected. be rejected.
The EventsDescriptor parameter, if present, provides the list of events The EventsDescriptor parameter, if present, provides the list of Events
that should be detected on the termination. that should be detected on the Termination.
The SignalDescriptor parameter, if present, provides the list of signals The SignalDescriptor parameter, if present, provides the list of Signals
that should be produced on the termination. that should be produced on the Termination.
The command may also include a DigitMapDescriptor. Each parameter The command may also include a DigitMapDescriptor. Each parameter
describes the name and the value of a digit map in the Context of the
Internet draft MEGACO Protocol Proposal March 25, 1999 Termination.
describes the name and the value of a digit map in the context of the
termination.
2.2.2. Modify 2.2.2. Modify
The Modify command modifies the properties of a Termination. The Modify command modifies the properties of a Termination.
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
<--- Modify(TerminationId, <--- Modify(TerminationId,
[TerminationState,] [TerminationState,]
Internet draft MEGACO Protocol April 16, 1999
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
[EventsDescriptor,] [EventsDescriptor,]
[SignalDescriptor,] [SignalDescriptor,]
[DigitMapDescriptor]) [DigitMapDescriptor])
TerminationId is the identifier of the termination whose properties are TerminationId is the name of the Termination whose properties are being
being modified. The TerminationId may not be under-specified. modified. The TerminationId may not be under-specified.
The Modify command takes place within the context to which the termina- The Modify command takes place within the Context to which the Termina-
tion belongs, or within the "all" context when modifications are to be tion belongs, or within the "null" Context when modifications are to be
made to the termination regardless of context. made to the default values for the Termination.
The TerminationState properties can be fully specified or unspecified by The TerminationState properties can be fully specified or unspecified by
the MGC. The MG uses the specified value when it is present, the previ- the MGC. The MG uses the specified value when it is present, the previ-
ously specified value otherwise. ous value otherwise.
The LocalTerminationDescriptor properties can be either fully specified, The LocalTerminationDescriptor properties can be either fully specified,
under-specified or unspecified by the MGC. The MGC may under-specify a under-specified or unspecified by the MGC. The MGC may under-specify a
parameter by providing a loose specification, such as a list of allowed parameter by providing a loose specification, such as a list of allowed
encoding methods or a range of packetization periods. When the value encoding methods or a range of packetization periods. When the value
are under-specified, the MG returns a fully qualified LocalTermination- are under-specified, the MG returns a fully qualified LocalTermination-
Descriptor. When a value is unspecified, the MG keeps the value that Descriptor. When a value is unspecified, the MG retains the previous
resulted from the previous ADD or MODIFY command. value.
The RemoteTerminationDescriptor properties can be either fully speci- The RemoteTerminationDescriptor properties can be either fully speci-
fied, under-specified, or left unspecified by the MGC. When a value is fied, under-specified, or left unspecified by the MGC. When a value is
unspecified, the MG keeps the value that resulted from the previous ADD unspecified, the MG keeps the previous value. A value is under-
or MODIFY command. A value is under-specified, the MG performs a selec- specified, the MG performs a selection and returns a RemoteTermination-
tion and returns a RemoteTerminationDescriptor that documents the Descriptor that documents the choices made.
choices made.
The EventsDescriptor parameter, if present, provides the list of events
that should be detected on the termination.
Internet draft MEGACO Protocol Proposal March 25, 1999 The EventsDescriptor parameter, if present, provides the list of Events
that should be detected on the Termination.
The SignalDescriptor parameter, of present, provides the list of signals The SignalDescriptor parameter, of present, provides the list of signals
that should be produced on the termination. that should be produced on the Termination.
The command may also include a DigitMapDescriptor. Each parameter The command may also include a DigitMapDescriptor. Each parameter
describes the name and the value of a digit map in the context of the describes the name and the value of a digit map.
termination.
Modify of a termination outside a context changes the default values for Modify of a Termination in the null Context changes the default values
TerminationState, LocalTerminationDescriptor, RemoteTerminationDescrip- for TerminationState, LocalTerminationDescriptor, RemoteTermination-
tor, EventsDescriptor, and SignalDescriptor on that termination. Modify Descriptor, EventsDescriptor, and SignalDescriptor on that Termination.
of a wildcarded termination ID outside of a context changes all Modify of a wildcarded termination ID in the null Context changes all
instances of the termination covered by the wildcard specification. instances of the Termination covered by the wildcard specification.
Internet draft MEGACO Protocol April 16, 1999
Modify of a TerminationID where only a subset of the hierarchy is named Modify of a TerminationID where only a subset of the hierarchy is named
(such as "com1/3" where com1 represents a channelized T3 as described (such as "com1/3" where com1 represents a channelized T3 as described
above), changes properties assigned to the logical unit covered by the above), changes properties assigned to the logical unit covered by the
name specified. In the example, changing "com1/3"'s "linecode = B8ZS" name specified. In the example, changing "com1/3"'s "linecode = B8ZS"
would alter the line coding of the 3rd DS1 in the T3 to B8ZS. Simi- would alter the line coding of one of the DS1s in the T3 to B8ZS. Simi-
larly, changing the linecode of "com1/*" would change the line coding larly, changing the linecode of "com1/*" would change the line coding
for all DS1s in the T3. for all DS1s in the T3.
Modify can also be used to program the MG to Notify the MGC at particu- Modify can also be used to program the MG to Notify the MGC at particu-
lar intervals if no other communication is occurring between the MGC and lar intervals if no other communication is occurring between the MGC and
the MG. This has the effect of providing a heartbeat message from the the MG. This has the effect of providing a heartbeat message from the
MG to the MGC. MG to the MGC.
2.2.3. Subtract 2.2.3. Subtract
The Subtract commands disconnects a termination from a Context and The Subtract commands disconnects a Termination from a Context and
returns statistics on the termination. returns statistics on it.
Statistics | Statistics |
*[TerminationId, *[TerminationId,
Statistics] Statistics]
<---- Subtract(TerminationId, <---- Subtract(TerminationId,
[TerminationState,] --include quarantine, not mode? [TerminationState,]
[EventsDescriptor,] [EventsDescriptor,]
[SignalDescriptor,] [SignalDescriptor,]
[DigitMapDescriptor]) [DigitMapDescriptor])
TerminationId is the identifier of the termination whose properties are TerminationId is the name of the Termination whose properties are being
being modified. The TerminationId is either a fully specified value, or modified. The TerminationId is either a fully specified value, or a
a wildcard value indicating that all the terminations of a given context wildcard value indicating that all the terminations of a given Context
shall be removed. shall be removed.
When all terminations have been removed from a specified context, that When all Terminations have been removed from a specified Context, that
Context is deleted by the MG.
Internet draft MEGACO Protocol Proposal March 25, 1999
context is deleted by the MG.
Ephemeral terminations are deleted when they are removed from their con- Ephemeral Terminations are deleted when they are removed from their Con-
text. The Subtract command, when applied to an ephemeral termination, text. The Subtract command, when applied to an Ephemeral Termination,
shall not have any other parameter than the TerminationId. shall not have any other parameter than the TerminationId.
The LocalTerminationDescriptor and RemoteTerminationDescriptor of a per- The LocalTerminationDescriptor and RemoteTerminationDescriptor of a per-
manent termination are reset to their default value when the termination manent termination are reset to their default value when the termination
is removed from its context. is removed from its Context.
When applied to a permanent termination, the Subtract command may When applied to a Physical Termination, the Subtract command may include
include TerminationState, EventsDescriptor, SignalDescriptor and Digit- TerminationState, EventsDescriptor, SignalDescriptor and DigitMap-
MapDescriptor parameters. These parameters are processed as defined in Descriptor parameters. These parameters are processed as defined in the
the Modify command.
The command returns the statistics that were observed on the termina- Internet draft MEGACO Protocol April 16, 1999
tion. When a wildcard is used, the command returns a termination iden-
tifier and statistics for each of the terminations whose name matched Modify command assuming a "null" Context, that is, they change the
default values of the Termination.
The command returns the statistics that were observed on the Termina-
tion. When a wildcard is used, the command returns a Termination iden-
tifier and statistics for each of the Terminations whose name matched
the wildcard. the wildcard.
2.2.4. Move 2.2.4. Move
The Move command moves a Termination to another Context. The termination The Move command moves a Termination to another Context. The Termination
is removed from its old context and is added to the new context as an is removed from its old Context and is added to the new Context as an
atomic operation. While this action appears similar to the packaging of atomic operation. While this action appears similar to the packaging of
a subtract and an add command, it does not have the side effect of a subtract and an add command, it does not have the side effect of
deleting an ephemeral termination that the subtract command would cause. deleting an Ephemeral Termination that the subtract command would cause.
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor] [RemoteTerminationDescriptor]
<-- Move(TerminationId, <-- Move(TerminationId,
[TerminationState,] [TerminationState,]
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
[EventsDescriptor,] [EventsDescriptor,]
[SignalDescriptor,] [SignalDescriptor,]
[DigitMapDescriptor]) [DigitMapDescriptor])
The TerminationId is the fully specified name of a Termination that is The TerminationId is the fully specified name of a Termination that is
being moved into the context specified for the transaction. The termi- being moved into the Context specified for the transaction. The termi-
nation is subtracted from its previous context. If it was the last ter- nation is subtracted from its previous Context. If it was the last Ter-
mination in this previous context, that context is deleted. A context mination in this previous Context, that Context is deleted. A Context
with only one termination is permitted. with only one Termination is permitted.
The TerminationState, LocalTerminationDescriptor, RemoteTermination- The TerminationState, LocalTerminationDescriptor, RemoteTermination-
Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor
parameters are processed as in the Modify command. Management Commands parameters are processed as in the Modify command. Management Commands
Internet draft MEGACO Protocol Proposal March 25, 1999
2.2.5. Audit 2.2.5. Audit
The Audit request returns properties associated with terminations: The Audit request returns properties associated with Terminations:
Internet draft MEGACO Protocol April 16, 1999
[TerminationId,] [TerminationId,]
[TerminationState,] [TerminationState,]
[LocalTerminationDescriptor,] [LocalTerminationDescriptor,]
[RemoteTerminationDescriptor,] [RemoteTerminationDescriptor,]
[EventsDescriptor,] [EventsDescriptor,]
[SignalDescriptor,] [SignalDescriptor,]
[DigitMapDescriptor,] [DigitMapDescriptor,]
[Capabilities] [Capabilities]
[Statistics] [Statistics]
<-- Audit (TerminationId, <-- Audit (TerminationId,
RequestedInfo) RequestedInfo)
The TerminationId identifies the termination that is being audited. The The TerminationId is the name of the termination that is being audited.
wildcard convention shall not be used. The command shall be applied The wildcard convention may be used. The command shall be applied either
either in the null context, for terminations that are not part of an in the null Context, for Terminations that are not part of an active
active context, or in the specific context of the termination(s). Context, or in the specific Context of the Termination(s).
The (possibly empty) RequestedInfo parameter describes the information The (possibly empty) RequestedInfo parameter describes the information
that is requested for the TerminationId specified. The following termi- that is requested for the TerminationId specified. The following Termi-
nation info can be audited with this command: nation info can be audited with this command:
TerminationState, LocalTerminationDescriptor, RemoteTermination- TerminationState, LocalTerminationDescriptor, RemoteTermination-
Descriptor, EventsDescriptor, SignalDescriptor, DigitMapDescriptor, Descriptor, EventsDescriptor, SignalDescriptor, ObservedEvents
Statistics and Capabilities. DigitMapDescriptor, Statistics and Capabilities.
The TerminationState, LocalTerminationDescriptor, RemoteTermination- The TerminationState, LocalTerminationDescriptor, RemoteTermination-
Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor Descriptor, EventsDescriptor, SignalDescriptor, ObservedEvents and
values are the values currently used by the termination. DigitMapDescriptor values are the values currently used by the Termina-
tion. ObservedEvents is as defined in Notify.
The Capabilities parameter returns values such as compression algo- The Capabilities parameter returns values such as compression algo-
rithms, packetization period, connection networks that the MG is ready rithms, packetization period, connection networks that the MG is ready
to support for that termination. In addition, the option can also be to support for that Termination. In addition, the option can also be
used to encode the event packages that the termination supports, and the used to return the Event Packages that the Termination supports, and the
list of TerminationState parameter values that the MG is ready to sup- list of TerminationState parameter values that the MG is ready to sup-
port for that termination. port for that Termination.
The Statistics parameter returns the current state of the termination The Statistics parameter returns the current state of the Termination
statistics that would be generated on a Subtract. This option provides statistics that would be generated on a Subtract. This option provides
mid-call statistics. mid-call statistics.
If the RequestedInfo parameter is empty, Audit returns the TerminationID If the RequestedInfo parameter is empty, Audit returns the TerminationID
only. Combining this with using null and unspecified for ContextID and only. Combining this with using null and unspecified for ContextID and
wildcarding TerminationID, the Audit command can return a wide variety wildcarding TerminationID, the Audit command can return a wide variety
Internet draft MEGACO Protocol Proposal March 25, 1999
of information: of information:
_____________________________________________________________________ Internet draft MEGACO Protocol April 16, 1999
_________________________________________________________________________
| ContextID TerminationID Returns | | ContextID TerminationID Returns |
|____________________________________________________________________| |_______________________________________________________________________|
| Specific all List of terminations in a Context | | Specific all List of terminations in a Context |
| Specific wildcard List of terminations in a Context, | | Specific wildcard List of terminations in a Context, |
| whose name matches the wildcard | | whose name matches the wildcard |
| Null root name Audit of MG (base state & events) | |Null Root name Audit of MG (base state & Events) |
| Null all List of all terminations in the MG | |Null all List of all Terminations in the MG |
| Null all/ List of all "top level" terminations | |Null all/ List of all "highest order" Terminations |
| Null wildcard List of all terminations whose | |Null wildcard List of all Terminations whose |
| name matches the wildcard. | | name matches the wildcard. |
| unspecified root name Audit of MG (null context) | |unspecified Root name Audit of MG (null Context) |
| unspecified all List of all terminations in the MG | |unspecified all List of all Terminations in the MG |
| and the context[s] to which they are | | and the Context[s] to which they are |
| associated (maybe null) | | associated (maybe null) |
| unspecified all/ List of all "top level" terminations,| |unspecified all/ List of all "highest order" Terminations,|
| in the context to which they are | | in the Context to which they are |
| associated (maybe null) | | associated (maybe null) |
| unspecified wildcard List of all terminations whose | |unspecified wildcard List of all Terminations whose |
| name matches the wildcard, in the | | name matches the wildcard, in the |
| context[s] to which they are | | Context[s] to which they are |
| associated (maybe null) | | associated (maybe null) |
|____________________________________________________________________| |_______________________________________________________________________|
Editor's note: We need to audit the state of digit collection. This can
Be accomplished by allowing an audit of the "ObservedEvents" parameter,
that would return the list of events accumulated so far.
The MGC can effect a "Are you alive" poll by using the Audit command on The MGC can effect a "Are you alive" poll by using the Audit command on
the null context with the root name as the TerminationID and an empty the null Context with the Root name as the TerminationID and an empty
RequestedInfo. This will result in a short response from the MG. RequestedInfo. This will result in a short response from the MG.
2.3. MG-Issued Commands 2.3. MG-Issued Commands
2.3.1. Notify 2.3.1. Notify
Notify (TerminationId, Notify (TerminationId,
ObservedEvents) ObservedEvents)
TerminationId is the name for the termination in the MG which is issuing TerminationId is the name for the Termination in the MG which is issuing
the Notify command, as defined in section 2.1.1. The identifier must be the Notify command, as defined in section 2.1.2. The identifier must be
a fully qualified termination identifier, including the domain name of a fully qualified termination identifier. The local part of the name
the MG. The MG must keep the name of the MGC that requested the Notifi- must not use the wildcard convention.
cation, suitably updated by failover procedures. The local part of the
Internet draft MEGACO Protocol Proposal March 25, 1999
name must not use the wildcard convention.
ObservedEvents is a parameter that contains a RequestIdentifier and a ObservedEvents is a parameter that contains a RequestIdentifier and a
list of events that the MG detected in the order they have been list of events that the MG detected in the order they have been
detected. The RequestIdentifier repeats the RequestIdentifier parameter detected. The RequestIdentifier repeats the RequestIdentifier parameter
of the EventDescriptor that triggered this notification. It is used to of the EventDescriptor that triggered this notification. It is used to
correlate this notification with the request that triggered it. correlate this notification with the request that triggered it.
The events in the list must be reported in the order in which they were Internet draft MEGACO Protocol April 16, 1999
detected. The list may only contain the identification of events that
The Events in the list must be reported in the order in which they were
detected. The list may only contain the identification of Events that
were requested in the RequestedEvents parameter of the triggering were requested in the RequestedEvents parameter of the triggering
EventsDescriptor. It must contain the events that were either accumu- EventsDescriptor. It must contain the Events that were either accumu-
lated (but not notified) or treated according to digit map (but no match lated (but not notified) or treated according to digit map (but no match
yet), and the final event that triggered the detection or provided a yet), and the final Event that triggered the detection or provided a
final match in the digit map. final match in the digit map.
Each element in the list must contain the name of the event, and may Each element in the list must contain the name of the Event, and may
also contains properties associated with the event and a notation of the also contains properties associated with the Event and a notation of the
time at which the event was detected. The MG MUST NOT send an unsoli- time at which the Event was detected. The MG MUST NOT send an unsoli-
cited notify. cited notify.
There is an Event defined for all MGs that can be programmed with an There is an Event defined for all MGs that can be programmed with an
interval. This event can be used for a "heart beat" notify message from interval. This Event can be used for a "heart beat" notify message from
MG to MGC. Use of this event is optional by the MGC. Any message sent MG to MGC. Use of this Event is optional by the MGC. Any message sent
by the MG to the MGC restarts the timer for the event. by the MG to the MGC restarts the timer for the Event.
2.3.2. ServiceChange 2.3.2. ServiceChange
The ServiceChange command is used by the MG to signal that a termina- The ServiceChange command is used by the MG to signal that a Termina-
tion, or a group of termination, or the entire gateway, is about to be tion, or a group of Terminations, or the entire gateway, is about to be
taken out of service, or has been brought back in to service. taken out of service, or has been brought back in to service.
[MGCIdentity] [MGCIdentity]
<------- ServiceChange ( TerminationId, <------- ServiceChange ( TerminationId,
ServiceChangeMethod, ServiceChangeMethod,
ServiceChangeReason, ServiceChangeReason,
[ServiceChangeDelay]) [ServiceChangeDelay])
The TerminationId identifies the terminations that are taken in or out The TerminationId identifies the Terminations that are taken in or out
of service. The "all" wildcard convention may be used to apply the com- of service. The "all" wildcard convention may be used to apply the com-
mand to a group of terminations, such as for example all terminations mand to a group of Terminations, such as for example all Terminations
that are attached to a specified interface, or even all terminations that are attached to a specified interface, or even all Terminations
that are attached to a given MG. The "choose" wildcard convention shall that are attached to a given MG. The "choose" wildcard convention shall
not be used. Hierarchical names can be used to specify that an element not be used. Hierarchical names can be used to specify that an element
of a MG, such as for example a digital multiplex, is being brought out of a MG, such as for example a digital multiplex, is being brought out
of service. The root keyword indicates the gateway itself is restart- of service. The Root keyword indicates the gateway itself is restart-
ing. ing.
Internet draft MEGACO Protocol Proposal March 25, 1999
The ServiceChangeMethod parameter specifies the type of ServiceChange. The ServiceChangeMethod parameter specifies the type of ServiceChange.
Three values have been defined: Three values have been defined:
* A "graceful" ServiceChange method indicates that the specified ter- * A "graceful" ServiceChange method indicates that the specified Ter-
minations will Be taken out of service after the specified delay. minations will Be taken out of service after the specified delay.
The established connections are not yet affected, but the MGC The established connections are not yet affected, but the MGC
should refrain from establishing new connections, and should try to should refrain from establishing new connections, and should try to
gracefully tear down the existing connections.
* A "forced" ServiceChange method indicates that the specified termi- Internet draft MEGACO Protocol April 16, 1999
nations were taken abruptly out of service. The established connec-
tions, if any, are lost.
Editor's note: A decision must be made as to whether the MGC must Sub- gracefully tear down the existing connections. If is sent with the
tract the Terminations from the Context to get statistics, or the Servi- Root TerminationID, this message indicates the MG itself will be
ceChange command automatically sends statistics, or the Audit command going out of service.
can be used to get statistics.
* A "forced" ServiceChange method indicates that the specified Termi-
nations were taken abruptly out of service. The established connec-
tions, if any, are lost, although the Contexts are maintained. The
MGC should Subtract the Terminations which could return available
statistics. If is sent with the Root TerminationID, this message
indicates the MG itself is out of service.
* A "Restart" method indicates that service will be restored on the * A "Restart" method indicates that service will be restored on the
terminations after the specified ServiceChangeDelay The termina- Terminations after the specified ServiceChangeDelay The Termina-
tions are not currently attached to any context. tions are not currently attached to any Context. If sent with the
Root TerminationID, the MG is announcing its availability to the
MGC.
ServiceChangeReason supplies the reason why the termination is being * A "Disconnected" method, always applied with the Root Termina-
tionID, indicates that the MG lost communication with the MGC, but
it was subsequently restored. Since MG state may have changed, the
MGC may wish to use the Audit command to resynchronize its state
with the MG's.
ServiceChangeReason supplies the reason why the Termination is being
taken out of service or brought back into service. taken out of service or brought back into service.
The optional ServiceChangeDelay parameter is expressed as a number of The optional ServiceChangeDelay parameter is expressed as a number of
seconds. If the number is absent, the delay value should be considered seconds. If the number is absent, the delay value should be considered
null. In the case of the "graceful" method, a null delay indicates that null. In the case of the "graceful" method, a null delay indicates that
the MGC should simply wait for the natural termination of the existing the MGC should simply wait for the natural termination of the existing
connections, without establishing new connections. The ServiceChangeDe- connections, without establishing new connections. The ServiceChangeDe-
lay is always considered null in the case of the "forced" method. lay is always considered null in the case of the "forced" method.
The MGC may return an MGCIdentity parameter that describes the MGC that The MGC may return an MGCIdentity parameter that describes the MGC that
should preferably be contacted by the MG. In this case the MG must should preferably be contacted by the MG. In this case the MG must
reissue the ServiceChange command to the new MGCIdentity reissue the ServiceChange command to the new MGCIdentity
The ServiceChange command specifying the root keyword for the Termina- The ServiceChange command specifying the Root keyword for the Termina-
tionId is the registration command by which an MG announces its tionId is the registration command by which an MG announces its
existence to the MGC. The MG is expected to be provisioned with the existence to the MGC. The MG is expected to be provisioned with the
name of one primary and some number of alternate MGCs. The Servi- name of one primary and some number of alternate MGCs. The Servi-
ceChange method shall be "forced". Acknowledgement of the ServiceChange ceChange method shall be "forced". Acknowledgement of the ServiceChange
completes the registration process. completes the registration process.
If an MG knows that a Termination is about to go out of service, it can If an MG knows that a Termination is about to go out of service, it can
issue a ServiceChange with ServiceChangeMethod set to "graceful", and issue a ServiceChange with ServiceChangeMethod set to "graceful", and
specify a ServiceChangeDelay. If an MG has just detected that a Termina- specify a ServiceChangeDelay. If an MG has just detected that a Termina-
tion or a set of Terminations has just gone out of service, it issues a tion or a set of Terminations has just gone out of service, it issues a
ServiceChange with ServiceChangeMethod set to "forced". [Editor's Note:
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
what if the Termination(s) have just gone down, and are still out of ServiceChange with ServiceChangeMethod set to "forced".
service? don't we need to indicate that? and then the MG would issue a
new ServiceChange when they are back in service]
An MGC may inform an MG that it should send subsequent commands to An MGC may inform an MG that it should send subsequent commands to
another MGC by returning the identity of a new MGC when responding to another MGC by returning the identity of a new MGC when responding to
ServiceChange. The MG may need to reissue ServiceChange to the new MGC. ServiceChange. The MG may need to reissue ServiceChange to the new MGC.
2.4. Error Codes 2.4. The following table lists the defined commands, and the available
input parameters. An "X" denotes the parameter is legal for the command
__________________________________________________________________
__________________________________________________________________
| Add Sub Mdfy Move Audt Ntfy SvcChng|
| TermID X X X X X X X |
| TermState X X X X |
| LocalTermDesc X X X X |
| RemoteTermDesc X X X X |
| EventsDesc X X X X |
| SignalDesc X X X X |
| DigitMapDescr X X X X |
| RequestedInfo X |
| ObservedEvents X |
| SvcChngMethod X |
| SvcChngReason X |
| SvcChngDelay X |
|_________________________________________________________________|
3. MG-MGC Control Associations
An MG is under control of (one or more) MGCs. 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 an MG, it has
been designed to support the following model, which has impacts on how
protocol mechanisms are used in such a case.
3.1. Multiple MGCs per MG
There are several circumstances where it is desired that an MG be con-
trolled by more than one MGC. One is the case where different MGCs
have varying abilities, for example, one MGC may be capable of SS7
interwork, another may only be capable of H.323 interwork. A physical
MG may need some of it's trunks controlled by SS7, while others are con-
trolled by H.323.
The model supported by the protocol is statically allocated partitioning
of Terminations. In this model, a physical MG can be thought of as
Internet draft MEGACO Protocol April 16, 1999
multiple virtual MGs, each with a non-intersecting set of 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 implementation of the
MEGACOP 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
instantiated per flow, and thus sharing the Termination is straightfor-
ward. 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 it's 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.
3.2. Cold Start
An 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 it's primary
MGC. If the MGC accepts the MG, it will send a Transaction Accept, with
the MGCIdenty set to itself. If the MG recieves an an MGCIdentity not
equal to the MGC it contacted, it sends a ServiceChange to the MGC
specified in the MGCIdentity. It continues this process until it gets a
controlling MGC to accept its registration, or it fails to get a reply.
Internet draft MEGACO Protocol April 16, 1999
3.3. 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.
3.4. Failover
3.4.1. Failure of an MG
If an 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.
Pairs of MGs that are capable of redundant failover of one of the MGs
are accommodated by allowing the MGC to send duplicate messages to both
MGs. Only the Working MG must accept or reject transactions. Upon
failover, the Protect MG sends a ServiceChange command with a "Failover"
method and a "Failed MG" reason. The MGC then uses the Protect MG as
the active MG, and only it must accept/reject transactions. When the
error condition is repaired, the Working MG can send a "ServiceChange"
with a "Restart" method.
3.4.2. Failure of an MGC
If the MG notices 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 sets the
"ControllingMGC" property of the root Termination to its new MGC. As a
side effect, the MG should send a ServiceChange message 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 failover, the handover should be transparent to
Operations on the gateway. Commands in progress continue, transaction
replies are sent to the new MGC, and the MG should expect outstanding
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, "ControllingMGC"
would be replaced with the previous value. In such a case, the MG shall
Internet draft MEGACO Protocol April 16, 1999
behave as if the value was changed, and send a ServiceChange message, as
above.
Pairs of MGCs that are capable of redundant failover can notify the con-
trolled MGs of the failover by the above mechanism.
3.5. Error Codes
All MEGACO Protocol commands are acknowledged. The acknowledgment car- All MEGACO Protocol commands are acknowledged. The acknowledgment car-
ries a return code, which indicates the status of the command. The ries a return code, which indicates the status of the command. The
return code is value for which three ranges have been defined: return code is value for which three ranges have been defined:
* successful completion, * successful completion,
* transient error, * transient error,
* permanent error. * permanent error.
3. Security Considerations 4. Security Considerations
If unauthorized entities could use the MEGACO protocol, they would be If unauthorized entities could use the MEGACO protocol, they would be
able to set-up unauthorized calls, or to interfere with authorized able to set-up unauthorized calls, or to interfere with authorized
calls. The primary security mechanism employed by the protocol is IPSEC calls. The primary security mechanism employed by the protocol is IPSEC
[RFC2401]. Support of the AH header [RFC2402] affords authentication [RFC2401]. Support of the AH header [RFC2402] affords authentication
and integrity protection on messages passed between the MG and the MGC. and integrity protection on messages passed between the MG and the MGC.
Support of the ESP header [RFC2406] can provide confidentiality of mes- Support of the ESP header [RFC2406] can provide confidentiality of mes-
sages if desired. sages if desired.
Implementation of IPSEC requires that the AH and ESP headers be inserted Implementation of IPSEC requires that the AH and ESP headers be inserted
skipping to change at page 35, line 4 skipping to change at page 36, line 53
Integrity Check Value (ICV). In IPSEC, the ICV is calculated over 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 entire IP packet including the IP header. This prevents spoofing of the
IP addresses. To retain the same functionality, the ICV calculation IP addresses. To retain the same functionality, the ICV calculation
should be performed across the entire MEGACOP message prepended by a should be performed across the entire MEGACOP message prepended by a
synthesized IP header consisting of a 32 bit source IP address, a 32 bit synthesized IP header consisting of a 32 bit source IP address, a 32 bit
destination address and an 16 bit UDP port in the MSBs of a 32 bit word. destination address and an 16 bit UDP port in the MSBs of a 32 bit word.
The Authentication Data is assumed to be zero as in [RFC2402]. The The Authentication Data is assumed to be zero as in [RFC2402]. The
"Next Header" and "RESERVED" fields MUST be set to "zero". "Next Header" and "RESERVED" fields MUST be set to "zero".
The ICV calculation is thus performed over a structure that would look The ICV calculation is thus performed over a structure that would look
Internet draft MEGACO Protocol Proposal March 25, 1999
like: like:
Internet draft MEGACO Protocol April 16, 1999
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address | | Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address | | Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | RESERVED | | UDP Port | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED | | Next Header | Payload Len | RESERVED |
skipping to change at page 36, line 5 skipping to change at page 37, line 52
When employing the AH header, either in IPSEC or AH-within-MEGACO, all When employing the AH header, either in IPSEC or AH-within-MEGACO, all
implementations of the protocol MUST implement section 5 of [RFC2402] implementations of the protocol MUST implement section 5 of [RFC2402]
which defines a minimum set of algorithms for integrity checking using which defines a minimum set of algorithms for integrity checking using
manual keys. MECACOP implementations SHOULD implement IKE [RFC2409] to manual keys. MECACOP implementations SHOULD implement IKE [RFC2409] to
permit more robust keying options. MEGACOP implementations employing permit more robust keying options. MEGACOP implementations employing
IKE SHOULD implement RSA signatures and authentication with RSA public IKE SHOULD implement RSA signatures and authentication with RSA public
key encryption. MECACOP implementations employing the ESP header key encryption. MECACOP implementations employing the ESP header
[RFC2406] MUST implement section 6 of [RFC2406] which defines a minimum [RFC2406] MUST implement section 6 of [RFC2406] which defines a minimum
set of algorithms for integrity checking and encryption. set of algorithms for integrity checking and encryption.
Internet draft MEGACO Protocol Proposal March 25, 1999 NOTE: The AH-within-MEGACO scheme is defined as interim. The next
NOTE: The AH-within-MEGACO scheme is defined as interim. The next ver- Internet draft MEGACO Protocol April 16, 1999
sion of this protocol is likely to deprecate it (backwards compatibil-
ity?). version of this protocol is likely to deprecate it (backwards compati-
bility?).
Adequate protection of the connections must be achieved if the MG and Adequate protection of the connections must be achieved if the MG and
the MGC only accept messages for which authentication services of the AH the MGC only accept messages for which authentication services of the AH
header have been configured. Employing the ESP header for encryption header have been configured. Employing the ESP header for encryption
service must provide additional protection against eavesdropping, thus service must provide additional protection against eavesdropping, thus
forbidding third parties from monitoring the connections set up by a forbidding third parties from monitoring the connections set up by a
given termination given Termination
The encryption service should also be requested if the session descrip- The encryption service should also be requested if the session descrip-
tions are used to carry session keys, as defined in SDP. tions are used to carry session keys, as defined in SDP.
These procedures do not necessarily protect against denial of service These procedures do not necessarily protect against denial of service
attacks by misbehaving MGs or misbehaving MGCs. However, they will pro- attacks by misbehaving MGs or misbehaving MGCs. However, they will pro-
vide an identification of these misbehaving entities, which should then vide an identification of these misbehaving entities, which should then
be deprived of their authorization through maintenance procedures. be deprived of their authorization through maintenance procedures.
3.1. Protection of Media Connections Also note that the use of NAT (Network Address Translation) interferes
with the operation IPSEC and IPSEC-like mechanisms, as they modify IP
addresses and port numbers, and thus invalidate the ICV calculations.
It is possible to use IPSEC between the point at which NAT is applied
and the outside party.
4.1. Protection of Media Connections
The protocol allows the MGC to provide MGs with "session keys" that can The protocol allows the MGC to provide MGs with "session keys" that can
be used to encrypt the audio messages, protecting against eavesdropping. be used to encrypt the audio messages, protecting against eavesdropping.
A specific problem of packet networks is "uncontrolled barge-in." This A specific problem of packet networks is "uncontrolled barge-in." This
attack can be performed by directing media packets to the IP address and 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 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 packets must be decompressed and the signals must be played on the "line
side". side".
skipping to change at page 36, line 51 skipping to change at page 39, line 5
ment and it can be fooled by source spoofing: ment and it can be fooled by source spoofing:
* To enable the address-based protection, the MGC must obtain the * To enable the address-based protection, the MGC must obtain the
remote session description of the egress MG and pass it to the remote session description of the egress MG and pass it to the
ingress MG. This requires at least one network roundtrip, and ingress MG. This requires at least one network roundtrip, and
leaves us with a dilemma: either allow the call to proceed without leaves us with a dilemma: either allow the call to proceed without
waiting for the round trip to complete, and risk for example, waiting for the round trip to complete, and risk for example,
"clipping" a remote announcement, or wait for the full roundtrip "clipping" a remote announcement, or wait for the full roundtrip
and settle for slower call-set-up procedures. and settle for slower call-set-up procedures.
Internet draft MEGACO Protocol April 16, 1999
* Source spoofing is only effective if the attacker can obtain valid * Source spoofing is only effective if the attacker can obtain valid
pairs of source destination addresses and ports, for example by pairs of source destination addresses and ports, for example by
listening to a fraction of the traffic. To fight source spoofing, listening to a fraction of the traffic. To fight source spoofing,
one could try to control all access points to the network. But one could try to control all access points to the network. But
Internet draft MEGACO Protocol Proposal March 25, 1999
this is in practice very hard to achieve. this is in practice very hard to achieve.
An alternative to checking the source address is to encrypt and authen- 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 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 set-up procedure. This will not slow down the call set-up, and provides
strong protection against address spoofing. strong protection against address spoofing.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
4. Syntax 5. Syntax
Editor's Note: In this edition of the document, a decision has not Editor's Note: In this edition of the document, a decision has not
been made on the encoding of the protocol. The following EBNF been made on the encoding of the protocol. The following EBNF
description is therefore somewhat awkward. Productions with the word description is therefore somewhat awkward. Productions with the word
"Token" are not defined. In an ASCII encoding, they would typically be "Token" are not defined. In an ASCII encoding, they would typically be
some kind of keyword and a separator. In a binary encoding, they would some kind of keyword and a separator. In a binary encoding, they would
be a code. The productions use the terms "digit", as in 9DIGIT, which be a code. The productions use the terms "digit", as in 9DIGIT, which
would be understood as a 9 character numeric string in ASCII, or a 32 bit would be understood as a 9 character numeric string in ASCII, or a 32 bit
number in binary, although there may be small differences in coding number in binary, although there may be small differences in coding
when the decision is actually made. The syntax leaves out separators and when the decision is actually made. The syntax leaves out separators and
skipping to change at page 38, line 52 skipping to change at page 40, line 52
errorCode = OCTET STRING(3) ;could be extended errorCode = OCTET STRING(3) ;could be extended
errorText = OCTET STRING errorText = OCTET STRING
transactionId = INTEGER32 transactionId = INTEGER32
SystemId = domainName [":" portNumber] SystemId = domainName [":" portNumber]
domainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821 domainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821
portNumber = INTEGER16 ;should this be 5digit, 16 bit? portNumber = INTEGER16 ;should this be 5digit, 16 bit?
version = megacopToken Version Profile version = megacopToken Version Profile
Version = OCTET STRING Version = OCTET STRING
Profile = OCTET STRING ;need exlpanation Profile = OCTET STRING ;need explanation
Action = ctxToken contextId 1*command Action = ctxToken contextId 1*command
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
contextId = nullToken / unspecifiedToken / INTEGER32 contextId = nullToken / unspecifiedToken / INTEGER32
command = commandName terminationId parameters command = commandName terminationId parameters
commandName = (addToken / commandName = (addToken /
subtractToken / subtractToken /
modifyToken / modifyToken /
moveToken / moveToken /
auditToken / auditToken /
skipping to change at page 39, line 46 skipping to change at page 41, line 46
[RIToken RequestedInfo ] [RIToken RequestedInfo ]
[RMToken ServiceChangeMethod ] [RMToken ServiceChangeMethod ]
[RDToken ServiceChangeDelay ] [RDToken ServiceChangeDelay ]
[OEToken ObservedEvents ] [OEToken ObservedEvents ]
[STToken Statistics ] [STToken Statistics ]
[CpToken Capabilities ] [CpToken Capabilities ]
[MiToken MGCIdentity ] [MiToken MGCIdentity ]
*[extensionParameterToken parameterValue] ]) ;fix *[extensionParameterToken parameterValue] ]) ;fix
TerminationState = stateParameter ;leftover production for bracketing TerminationState = stateParameter ;leftover production for bracketing
stateParameter = ([modeToken TerminationMode] stateParameter = ([modeToken TerminationMode]
[quarantineHandlingToken QuarantineHandling ]) ;fix there are 2 of them [bufferedEventHandlingToken BufferedEventHandling ])
;fix, there are 2 of them
TerminationMode = sendonlyToken / recvonlyToken / sendrecvToken / TerminationMode = sendonlyToken / recvonlyToken / sendrecvToken /
inactiveToken / loopbackToken / conttestToken / OutOfService inactiveToken / loopbackToken / conttestToken / OutOfService
QuarantineHandling = loopControl / processControl / ;fix BufferedEventHandling = loopControl / processControl / ;fix
(loopControl processControl ) (loopControl processControl )
loopControl = stepToken / loopToken loopControl = stepToken / loopToken
processControl = processToken / discardToken processControl = processToken / discardToken
LocalTerminationDescriptor = TerminationDescriptor Internet draft MEGACO Protocol April 16, 1999
Internet draft MEGACO Protocol Proposal March 25, 1999
LocalTerminationDescriptor = TerminationDescriptor
RemoteTerminationDescriptor = TerminationDescriptor RemoteTerminationDescriptor = TerminationDescriptor
eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange) eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange)
packageName = 1*(SuitableCharacters) packageName = 1*(SuitableCharacters)
eventId = 1*(SuitableCharacters) ;could be an Integer32 eventId = 1*(SuitableCharacters) ;could be an Integer32
EventsDescriptor = [requestedEvent 0*(requestedEvent)] EventsDescriptor = [requestedEvent 0*(requestedEvent)]
requestedEvent = eventName [0*(eventParameters)] [requestedActions] requestedEvent = eventName [0*(eventParameters)] [requestedActions]
eventParameters = *(parameterName parameterValue) eventParameters = *(parameterName parameterValue)
requestId = INTEGER32 requestId = INTEGER32
skipping to change at page 40, line 54 skipping to change at page 43, line 4
DigitStringElement = DigitPosition ["."] DigitStringElement = DigitPosition ["."]
DigitPosition = DigitMapLetter / DigitMapRange DigitPosition = DigitMapLetter / DigitMapRange
DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / MFSig / "T" DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / MFSig / "T"
MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" / MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" /
DigitMapRange = "x" / "[" DigitLetters "]" DigitMapRange = "x" / "[" DigitLetters "]"
DigitLetter = *((DIGIT "-" DIGIT ) / DigitMapLetter) DigitLetter = *((DIGIT "-" DIGIT ) / DigitMapLetter)
RequestedInfo = [infoCode 0*(infoCode)] RequestedInfo = [infoCode 0*(infoCode)]
infoCode = TerminationStateToken / LocalTermDescToken / RemoteTermDescToken / infoCode = TerminationStateToken / LocalTermDescToken / RemoteTermDescToken /
EventDeccToken / SignalDescToken / EventDeccToken / SignalDescToken /
DigMapToken / StatsToken / CapsToken /
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
ServiceChangeMethod = GracefulToken / ForcedToken / ServiceChangeToken DigMapToken / StatsToken / ObsrvdEvntsToken CapsToken /
ServiceChangeMethod = GracefulToken / ForcedToken / RestartToken / FailoverToken
ServiceChangeDelay = INTEGER32 ServiceChangeDelay = INTEGER32
ObservedEvents = (requestId [ observedEvent *(observedEvent) ]) ObservedEvents = (requestId [ observedEvent *(observedEvent) ])
observedEvent = [ TimeNotation ] SignalRequest observedEvent = [ TimeNotation ] SignalRequest
TimeNotation= INTEGER64; 64 bits NTP time stamp ? TimeNotation= INTEGER64; 64 bits NTP time stamp ?
Statistics = [StatisticsParameter 0*( StatisticsParameter ) ] Statistics = [StatisticsParameter 0*( StatisticsParameter ) ]
StatisticsParameter = ( PktsSentToken packetsSent ) StatisticsParameter = ( PktsSentToken packetsSent )
/ ( OctetsSentToken octetsSent ) / ( OctetsSentToken octetsSent )
/ ( PktsRecvdToken packetsReceived ) / ( PktsRecvdToken packetsReceived )
skipping to change at page 42, line 5 skipping to change at page 44, line 5
"!" / "'" / "|" / "=" / "#" / "?" / "/" / "!" / "'" / "|" / "=" / "#" / "?" / "/" /
"." / "$" / "*" / ";" / "@" / "[" / "]" / "." / "$" / "*" / ";" / "@" / "[" / "]" /
"^" / "`" / "{" / "}" / "~" "^" / "`" / "{" / "}" / "~"
quotedString = DQUOTE visibleString quotedString = DQUOTE visibleString
0*(quoteEscape visibleString) DQUOTE 0*(quoteEscape visibleString) DQUOTE
quoteEscape = DQUOTE DQUOTE quoteEscape = DQUOTE DQUOTE
visibleString = (%x00-21 / %x23-FF) visibleString = (%x00-21 / %x23-FF)
TerminationDescriptor = ;Undecided, could be SDP as in RFC 2327 TerminationDescriptor = ;Undecided, could be SDP as in RFC 2327
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
**************************************************************
* Editor's Note: All text following this point has not *
* been reviewed by the design team. It is presented *
* unedited to aid the reader in understanding the *
* protocol. Implications on encoding or other unresolved *
* issues should be disregarded *
**************************************************************
4.1. Termination Names 5.1. Termination Names
Each command contains a unique termination name. The following rules for Each command contains a unique Termination name. The following rules for
construction and interpretation of the termination names MUST be sup- construction and interpretation of the Termination names MUST be sup-
ported: ported:
1) The individual terms of the naming path MUST be separated by a sin- 1) The individual terms of the naming path MUST be separated by a sin-
gle slash ("/", ASCII 2F hex). gle slash ("/", ASCII 2F hex).
2) The individual terms are character strings composed of letters, 2) The individual terms are character strings composed of letters,
digits or other printable characters, with the exception of charac- digits or other printable characters, with the exception of charac-
ters used as delimiters ("/", "@"), characters used for wildcarding ters used as delimiters ("/", "@"), characters used for wildcarding
("*", "$") and white spaces. ("*", "$") and white spaces.
3) Wild-carding is represented either by an asterisk ("*") or a dollar 3) Wild-carding is represented either by an asterisk ("*") or a dollar
sign ("$") for the terms of the naming path which are to be wild- sign ("$") for the terms of the naming path which are to be wild-
carded. Thus, if the full naming path looks like carded. Thus, if the full naming path looks like
term1/term2/term3 term1/term2/term3
then the termination name looks like this depending on which terms then the Termination name looks like this depending on which terms
are wild- carded: are wild- carded:
*/term2/term3 if term1 is wild-carded */term2/term3 if term1 is wild-carded
term1/*/term3 if term2 is wild-carded term1/*/term3 if term2 is wild-carded
term1/term2/* if term3 is wild-carded term1/term2/* if term3 is wild-carded
term1/*/* if term2 and term3 are wild-carded, term1/*/* if term2 and term3 are wild-carded,
etc. etc.
In each of these examples a dollar sign could have appeared instead In each of these examples a dollar sign could have appeared instead
of an asterisk. of an asterisk.
4) A term represented by an asterisk is to be interpreted as: "use ALL 4) A term represented by an asterisk is to be interpreted as: "use ALL
values of this term known within the scope of the Media Gateway". values of this term known within the scope of the Media Gateway".
A term represented by a dollar sign is to be interpreted as: "use A term represented by a dollar sign is to be interpreted as: "use
ANY ONE value of this term known within the scope of the Media ANY ONE value of this term known within the scope of the Media
Gateway". The description of a specific command may add further Gateway". The description of a specific command may add further
Internet draft MEGACO Protocol Proposal March 25, 1999
criteria for selection within the general rules given here. criteria for selection within the general rules given here.
Internet draft MEGACO Protocol April 16, 1999
Examples of TerminationId: Examples of TerminationId:
/MG7.network.com/com1/channel1 ; fully qualified termination name /MG7.network.com/com1/channel1 ; fully qualified Termination name
; one channel on device "com1" ; one channel on device "com1"
; channels on device "com1" ; channels on device "com1"
; all devices on MG ; all devices on MG
; on all devices on MG ; on all devices on MG
When an ephemeral termination is to be created, the termination class of When an Ephemeral Termination is to be created, the desired termination
the Desired termination type is specified as the first component of the type is specified as the first component of the name with "/$" con-
name with "/$" concatenated on the class name. For example, "RTP/$" catenated on the name. For example, "RTP/$" would request a new Termi-
would request a new Termination from the RTP termination class nation from the RTP Termination Class.
4.2. Events, Signals and Packages 5.2. Events, Signals and Packages
Event names are case insensitive and are composed of two logical parts, Event names are case insensitive and are composed of two logical parts,
a package name and an event name. Both names are strings of letters, a Package name and an Event name. Both names are strings of letters,
hyphens and digits, with the restriction that hyphens shall never be the hyphens and digits, with the restriction that hyphens shall never be the
first or last characters in a name. Package or event names are not case first or last characters in a name. Package or Event names are not case
sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered
equal. equal.
In textual representations, the package name, when present, is separated In textual representations, the Package name, when present, is separated
from the event name by a slash ("/"). The package name is in fact from the Event name by a slash ("/"). The Package name is in fact
optional. Each termination-type has a default package associated with optional. Each termination-type has a default Package associated with
it, and if the package name is excluded from the event name, the default it, and if the Package name is excluded from the Event name, the default
package name for that termination-type is assumed. For example, for an Package name for that termination-type is assumed. For example, for an
analog access line, the following two event names are equal: analog access line, the following two Event names are equal:
l/dl dial-tone in the line package for an analog access line. l/dl dial-tone in the line Package for an analog access line.
dl dial-tone in the line package (default) for an analog access line. dl dial-tone in the line Package (default) for an analog access line.
This document defines a basic set of package names and event names. This document defines a basic set of Package names and Event names.
Additional package names and event names can be registered with the Additional Package names and Event names can be registered with the
IANA. A package definition shall define the name of the package, and the IANA. A Package definition shall define the name of the Package, and the
definition of each event belonging to the package. The event definition definition of each Event belonging to the Package. The Event definition
shall include the precise name of the event (i.e., the code used in the shall include the precise name of the Event (i.e., the code used in the
MEGACO protocol), a plain text definition of the event, and, went MEGACO protocol), a plain text definition of the Event, and, went
appropriate, the precise definition of the corresponding signals, for appropriate, the precise definition of the corresponding signals, for
example the exact frequencies of audio signal such as dial tones or DTMF
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
example the exact frequencies of audio signal such as dial tones or DTMF
tones. tones.
In addition, implementers can gain experience by using experimental In addition, implementers can gain experience by using experimental
packages. The names of experimental packages must start with the two Packages. The names of experimental Packages must start with the two
characters "x-"; the IANA shall not register package names that start characters "x-"; the IANA shall not register Package names that start
with these characters. with these characters.
Digits, or letters, are supported in many packages, notably "DTMF", "MF" Digits, or letters, are supported in many Packages, notably "DTMF", "MF"
and "pulse". Digits and letters are defined by the rules "Digit" and and "pulse". Digits and letters are defined by the rules "Digit" and
"Letter" in the definition of digit maps. This definition refers to the "Letter" in the definition of digit maps. This definition refers to the
digits (0 to 9), to the asterisk or star ("*") and orthotrope, number or digits (0 to 9), to the asterisk or star ("*") and orthotrope, number or
pound sign ("#"), and to the letters "A", "B", "C" and "D", as well as pound sign ("#"), and to the letters "A", "B", "C" and "D", as well as
the timer indication "T". These letters can be combined in "digit the timer indication "T". These letters can be combined in "digit
string" that represent the keys that a user punched on a dial. In addi- string" that represent the keys that a user punched on a dial. In addi-
tion, the letter "X" can be used to represent all digits, and the sign tion, the letter "X" can be used to represent all digits, and the sign
"$" can be used in wildcard notations. The need to easily express the "$" can be used in wildcard notations. The need to easily express the
digit strings has a consequence on the form of event names: digit strings has a consequence on the form of Event names:
An event name that does not denote a digit should always contain at An Event name that does not denote a digit should always contain at
least one character that is neither a digit, nor one of the letters least one character that is neither a digit, nor one of the letters
A, B, C, D, T or X. (Such names should not contain the special A, B, C, D, T or X. (Such names should not contain the special
signs "*", "#", "/" or "$".) signs "*", "#", "/" or "$".)
An MGC may often have to ask a MG to detect a group of events. Two con- An MGC may often have to ask a MG to detect a group of Events. Two con-
ventions can be used to denote such groups: ventions can be used to denote such groups:
* The wildcard convention can be used to detect any event belonging * The wildcard convention can be used to detect any Event belonging
to a package, or a given event in many packages, or event any event to a Package, or a given Event in many Packages, or Event any Event
in any package supported by the MG. in any Package supported by the MG.
* The regular expression Range notation can be used to detect a range * The regular expression Range notation can be used to detect a range
of digits. of digits.
The star sign (*) can be used as a wildcard instead of a package name, The star sign (*) can be used as a wildcard instead of a Package name,
and the dollar sign ("$") or the keyword "all" can be used as a wildcard and the dollar sign ("$") or the keyword "all" can be used as a wildcard
instead of an event name: instead of an Event name:
A name such as "foo/all" denotes all events in package "foo" A name such as "foo/all" denotes all Events in Package "foo"
A name such as "*/bar" denotes the event "bar" in any package sup- A name such as "*/bar" denotes the Event "bar" in any Package sup-
ported by the MG ported by the MG
The names "*" or "*/all" denote all events supported by the MG. The names "*" or "*/all" denote all Events supported by the MG.
The MGC can ask an MG to detect a set of digits or letters either by The MGC can ask an MG to detect a set of digits or letters either by
individually describing those letters, or by using the "range" notation individually describing those letters, or by using the "range" notation
defined in the syntax of digit strings. For example, the MGC can: defined in the syntax of digit strings. For example, the MGC can:
Use the letter "x" to denote "any letter or digit." Use the letter "x" to denote "any letter or digit."
Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound
sign. sign.
Events and signals are described in packages. The package description Events and Signals are described in Packages. The Package description
must provide, for each events, the following information: must provide, for each Event, the following information:
* The description of the event and its purpose, which should mean the * The description of the Event and its purpose, which should mean the
actual signal that is generated by the client (i.e., xx ms FSK actual Signal that is generated by the client (i.e., xx ms FSK
tone) as well as the resulting user observed result (i.e., MW light tone) as well as the resulting user observed result (i.e., MW light
on/off). on/off).
* The detailed characteristics of the event, such as for example fre- * The detailed characteristics of the Event, such as for example fre-
quencies and amplitude of audio signals, modulations and repeti- quencies and amplitude of audio signals, modulations and repeti-
tions, tions,
* The typical and maximum duration of the event. * The typical and maximum duration of the Event.
Package descriptions should describe, for all signals, their type (OO, Package descriptions should describe, for all Signals, their type (OO,
TO, BR). They should also describe the maximum duration of the TO sig- TO, BR). They should also describe the maximum duration of the TO Sig-
nals. nals.
4.3. Digit Maps 5.3. Digit Maps
A digit map is expressed using a syntax derived from the Unix system A digit map is expressed using a syntax derived from the Unix system
command, egrep. For example, the dial plan described above in section 2 command, egrep. For example, the dial plan described above in section 2
results in the following digit map: results in the following digit map:
(0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) (0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
The "DigitMapValue" rule of protocol syntax describes a format that con- The "DigitMapValue" rule of protocol syntax describes a format that con-
tains three parameters: tains three parameters:
skipping to change at page 46, line 5 skipping to change at page 48, line 5
The timer parameters are optional. When they are not specified, default The timer parameters are optional. When they are not specified, default
values are assumed. Suggested default values are 16 seconds for the values are assumed. Suggested default values are 16 seconds for the
long timer, 8 seconds for the medium timer. long timer, 8 seconds for the medium timer.
A DigitMap, according to this syntax, is defined either by a "string" or 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- by a list of strings. Each string in the list is an alternative number-
ing scheme. Each element in the string is composed of a set of string ing scheme. Each element in the string is composed of a set of string
elements, each of which can optionally be followed by a repetition char- elements, each of which can optionally be followed by a repetition char-
acter. The possible elements are: acter. The possible elements are:
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
* A digit, * A digit,
* The special characters "#" and "*" (number sign and star sign), * The special characters "#" and "*" (number sign and star sign),
* The letters A, B, C or D, * The letters A, B, C or D,
* The symbols "K0", "K1", "K2", "S0", "S1", "S2" and "S3", which may * The symbols "K0", "K1", "K2", "S0", "S1", "S2" and "S3", which may
be used in MF signalling, be used in MF signalling,
skipping to change at page 46, line 27 skipping to change at page 48, line 27
matched by a single occurence of any letter in the range, matched by a single occurence of any letter in the range,
* The character "x", that would be matched by any digit between 0 and * The character "x", that would be matched by any digit between 0 and
9. 9.
Each element may be followed by the repetition symbol "." (dot), to Each element may be followed by the repetition symbol "." (dot), to
denote a variable number of occurences of the position. denote a variable number of occurences of the position.
A MG that detects digits, letters or timers must: A MG that detects digits, letters or timers must:
1) Add the event parameter code as a token to the end of an internal 1) Add the Event parameter code as a token to the end of an internal
state variable called the "current dial string" state variable called the "current dial string"
2) Apply the current dial string to the digit map table, attempting a 2) Apply the current dial string to the digit map table, attempting a
match to each regular expression in the Digit Map in lexical order match to each regular expression in the Digit Map in lexical order
3) If the result is under-qualified (partially matches at least one 3) If the result is under-qualified (partially matches at least one
entry in the digit map), do nothing further. entry in the digit map), do nothing further.
If the result matches, or is over-qualified (i.e. no further digits If the result matches, or is over-qualified (i.e. no further digits
could possibly produce a match), notify the currently accumulated events could possibly produce a match), notify the currently accumulated Events
to the MGC, in the order in which they occurred. to the MGC, in the order in which they occurred.
When an MG is unable to store a digit map, it shall return an error to When an MG is unable to store a digit map, it shall return an error to
the MGC. MGs must be able to store at least n*2 + 8 Digit Maps where n the MGC.
is the number of terminations the MG can support.
4.4. Statistics 5.4. Statistics
The MG may maintain statistics that describe the status of the termina- The MG may maintain statistics that describe the status of the Termina-
tion. The precise properties of the statistics depends on the class of tion. The precise properties of the statistics depends on the Class of
the termination. the Termination.
In the RTP class, the some the properties are: In the RTP Class, the some the properties are:
Number of packets sent: Number of packets sent:
The total number of RTP data packets transmitted by the sender The total number of RTP data packets transmitted by the sender
since starting transmission on this connection. The count is not since starting transmission on this connection. The count is not
reset if the sender changes its synchronization source identifier
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
reset if the sender changes its synchronization source identifier
(SSRC, as defined in RTP), for example as a result of a Modify com- (SSRC, as defined in RTP), for example as a result of a Modify com-
mand. The value is zero if the connection was set in "receive only" mand. The value is zero if the connection was set in "receive only"
mode. mode.
Number of octets sent: Number of octets sent:
The total number of payload octets (i.e., not including header or The total number of payload octets (i.e., not including header or
padding) transmitted in RTP data packets by the sender since start- padding) transmitted in RTP data packets by the sender since start-
ing transmission on this connection. The count is not reset if the ing transmission on this connection. The count is not reset if the
sender changes its SSRC identifier, for example as a result of a sender changes its SSRC identifier, for example as a result of a
Modify command. The value is zero if the connection was set in Modify command. The value is zero if the connection was set in
skipping to change at page 48, line 4 skipping to change at page 49, line 54
received. The count includes packets received from different SSRC, received. The count includes packets received from different SSRC,
if the sender used several values. The value is zero if the connec- if the sender used several values. The value is zero if the connec-
tion was set in "send only" mode. This property is omitted if the tion was set in "send only" mode. This property is omitted if the
connection was set in "data" mode. connection was set in "data" mode.
Interarrival jitter: Interarrival jitter:
An estimate of the statistical variance of the RTP data packet An estimate of the statistical variance of the RTP data packet
interarrival time measured in milliseconds and expressed as an interarrival time measured in milliseconds and expressed as an
unsigned integer. The interarrival jitter J is defined to be the unsigned integer. The interarrival jitter J is defined to be the
mean deviation (smoothed absolute value) of the difference D in mean deviation (smoothed absolute value) of the difference D in
packet spacing at the receiver compared to the sender for a pair of
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
packet spacing at the receiver compared to the sender for a pair of
packets. Detailed computation algorithms are found in RFC 1889. The packets. Detailed computation algorithms are found in RFC 1889. The
count includes packets received from different SSRC, if the sender count includes packets received from different SSRC, if the sender
used several values. The value is zero if the connection was set in used several values. The value is zero if the connection was set in
"send only" mode. This property is omitted if the connection was "send only" mode. This property is omitted if the connection was
set in "data" mode. set in "data" mode.
Average transmission delay: Average transmission delay:
An estimate of the network latency, expressed in milliseconds. This An estimate of the network latency, expressed in milliseconds. This
is the average value of the difference between the NTP timestamp is the average value of the difference between the NTP timestamp
indicated by the senders of the RTCP messages and the NTP timestamp indicated by the senders of the RTCP messages and the NTP timestamp
skipping to change at page 49, line 4 skipping to change at page 50, line 54
The total number of payload octets received in ATM cells. The total number of payload octets received in ATM cells.
Number of packets lost: Number of packets lost:
Should be determined as the number of cells lost, or set to zero if Should be determined as the number of cells lost, or set to zero if
the adaptation layer does not enable the MG to assess losses. the adaptation layer does not enable the MG to assess losses.
Interarrival jitter: Interarrival jitter:
Should be understood as the interarrival jitter between ATM cells. Should be understood as the interarrival jitter between ATM cells.
Average transmission delay: Average transmission delay:
The MG may not be able to assess this property over an ATM network.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
The MG may not be able to assess this property over an ATM network.
It could simply report a null value. It could simply report a null value.
When the termination is of type TDM or analog, the meaning of these pro- When the Termination is of type TDM or analog, the meaning of these pro-
perties is defined as follow: perties is defined as follow:
Number of packets sent: Number of packets sent:
Not significant. Not significant.
Number of octets sent: Number of octets sent:
The total number of payload octets transmitted over the local con- The total number of payload octets transmitted over the local con-
nection. nection.
Number of packets received: Number of packets received:
skipping to change at page 49, line 35 skipping to change at page 51, line 34
Number of packets lost: Number of packets lost:
Not significant. A value of zero is assumed. Not significant. A value of zero is assumed.
Interarrival jitter: Interarrival jitter:
Not significant. A value of zero is assumed. Not significant. A value of zero is assumed.
Average transmission delay: Average transmission delay:
Not significant. A value of zero is assumed. Not significant. A value of zero is assumed.
4.5. Examples 5.5. Examples
The following examples use, for practical reasons, a text representation The following examples use, for practical reasons, a text representation
of the MEGACO protocol. This representation assumes the following token of the MEGACO protocol. This representation assumes the following token
definitions: definitions:
__________________________________________________ __________________________________________________
| TRAN | transToken | | TRAN | transToken |
| ACPT | acceptToken | | ACPT | acceptToken |
| MEGACO | megacopToken | | MEGACO | megacopToken |
| CTX | ctxToken | | CTX | ctxToken |
| ADD | addToken | | ADD | addToken |
| SUBTRACT| subtractToken | | SUBTRACT| subtractToken |
| MODIFY | modifyToken | | MODIFY | modifyToken |
| TS | TSToken (TerminationState) | | TS | TSToken (TerminationState) |
| LT | LTToken (LocalTerminationDescriptor) | | LT | LTToken (LocalTerminationDescriptor) |
| RT | RTToken (RemoteTerminationDescriptor)| | RT | RTToken (RemoteTerminationDescriptor)|
|_________|_______________________________________| |_________|_______________________________________|
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
4.5.1. Example Add transaction: 5.5.1. Example Add transaction:
TRAN 12345678 MGC1.network.com:12345 MEGACOP 1.0 TRAN 12345678 MGC1.network.com:12345 MEGACOP 1.0
CTX= -1 CTX= -1
ADD= circuitgroup1/5 ADD= circuitgroup1/5
LS= {m=recvonly LS= {m=recvonly
} }
ADD= RTP/ANY ADD= RTP/ANY
LS= {m=sendrecv LS= {m=sendrecv
} }
LT= {v=0 LT= {v=0
c=IN IP4 100.100.100.089 c=IN IP4 100.100.100.089
m=audio ANY RTP/AVP 0 m=audio ANY RTP/AVP 0
} }
RT= {v=0 RT= {v=0
c=IN IP4 200.200.200.133 c=IN IP4 200.200.200.133
m=audio 4321 RTP/AVP 0 m=audio 4321 RTP/AVP 0
} }
4.5.2. Example response to Add transaction: 5.5.2. Example response to Add transaction:
ACPT 12345678 MG1.network.com:12345 MEGACOP 1.0 ACPT 12345678 MG1.network.com:12345 MEGACOP 1.0
CTX= 12344321 CTX= 12344321
ADD= circuitgroup1/5 ADD= circuitgroup1/5
ADD= RTP/7777 ADD= RTP/7777
LT= {v=0 LT= {v=0
c=IN IP4 100.100.100.089 c=IN IP4 100.100.100.089
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
} }
4.5.3. Example Modify transaction: 5.5.3. Example Modify transaction:
TRAN 12345672 MGC1.network.com:12345 MEGACOP 1.0 TRAN 12345672 MGC1.network.com:12345 MEGACOP 1.0
CTX= 12344321 CTX= 12344321
MODIFY= circuitgroup1/5 MODIFY= circuitgroup1/5
LS= {m=sendrecv LS= {m=sendrecv
} }
4.5.4. Example Subtract transaction: 5.5.4. Example Subtract transaction:
TRAN 12345673 MGC1.network.com:12345 MEGACOP 1.0 TRAN 12345673 MGC1.network.com:12345 MEGACOP 1.0
CTX= 12344321 CTX= 12344321
SUBTRACT= circuitgroup1/5 SUBTRACT= circuitgroup1/5
SUBTRACT= RTP/7777 SUBTRACT= RTP/7777
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
4.6. Transaction Response Codes 5.6. Transaction Response Codes
All MegacoP transactions return a transaction response code which ack- All MegacoP transactions return a transaction response code which ack-
nowledges the command(s) sent and returns a code indicating the success nowledges the command(s) sent and returns a code indicating the success
or failure of the command. or failure of the command.
The transaction response code is an integer number, the first digit of The transaction response code is an integer number, the first digit of
which indicates the class of the Response Code. which indicates the class of the Response Code.
2xx: Success -- the transaction was successfully received, understood, and 2xx: Success -- the transaction was successfully received, understood, and
all commands were executed; all commands were executed;
skipping to change at page 51, line 30 skipping to change at page 53, line 30
5xx: Execution reject -- the transaction received could not be executed; 5xx: Execution reject -- the transaction received could not be executed;
MEGACOP Transaction Response Codes are extensible. MEGACOP applica- MEGACOP Transaction Response Codes are extensible. MEGACOP applica-
tions are not required to understand the meaning of all registered tions are not required to understand the meaning of all registered
response codes, though such understanding is obviously desirable. How- response codes, though such understanding is obviously desirable. How-
ever, applications MUST understand the class of any response code, as ever, applications MUST understand the class of any response code, as
indicated by the first digit, and treat any unrecognized response code indicated by the first digit, and treat any unrecognized response code
as being equivalent to the x00 response code of that class. as being equivalent to the x00 response code of that class.
4.6.1. Transaction Response Success Codes 5.6.1. Transaction Response Success Codes
Success = "200" ; The requested transaction was executed nor- Success = "200" ; The requested transaction was executed nor-
mally mally
4.6.2. Transaction Response Reject Codes 5.6.2. Transaction Response Reject Codes
Protocol-Reject = "400" ; Bad Request Protocol-Reject = "400" ; Bad Request
Protocol-Reject = "400" ; Bad Request Protocol-Reject = "400" ; Bad Request
/ "401" ; Unauthorized / "401" ; Unauthorized
/ "411" ; Length Required / "411" ; Length Required
/ "415" ; Incorrect identifier / "415" ; Incorrect identifier
/ "416" ; The transaction refers to an unknown ContextId / "416" ; The transaction refers to an unknown ContextId
/ "418" ; Unsupported or unknown package / "418" ; Unsupported or unknown Package
/ "422" ; No such event or signal / "422" ; No such Event or signal
/ "423" ; Unknown action or illegal combination of actions / "423" ; Unknown action or illegal combination of actions
/ "425" ; Unknown TerminationID / "425" ; Unknown TerminationID
/ "427" ; Missing RemoteTerminationDescriptor / "427" ; Missing RemoteTerminationDescriptor
/ "484" ; Action Incomplete / "484" ; Action Incomplete
/ "485" ; Action Ambiguous / "485" ; Action Ambiguous
Execution-Reject = "500" ; Internal Gateway Error Execution-Reject = "500" ; Internal Gateway Error
/ "501" ; Not Implemented / "501" ; Not Implemented
/ "502" ; Not ready. / "502" ; Not ready.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
/ "503" ; Service Unavailable / "503" ; Service Unavailable
/ "504" ; Gateway Time-out / "504" ; Gateway Time-out
/ "505" ; MEGACOP Version not supported / "505" ; MEGACOP Version not supported
/ "509" ; Resource Conflict / "509" ; Resource Conflict
/ "510" ; Insufficient resources / "510" ; Insufficient resources
/ "512" ; Gateway unequipped to detect requested event / "512" ; Gateway unequipped to detect requested Event
/ "513" ; Gateway unequipped to generate requested signals / "513" ; Gateway unequipped to generate requested Signals
/ "514" ; Gateway cannot send the specified announcement / "514" ; Gateway cannot send the specified announcement
/ "515" ; Unsupported Media Type / "515" ; Unsupported Media Type
/ "517" ; Unsupported or invalid mode / "517" ; Unsupported or invalid mode
/ "519" ; Gateway does not have a digit map / "519" ; Gateway does not have a digit map
/ "520" ; Termination is "ServiceChangeing" / "520" ; Termination is "ServiceChangeing"
/ "526" ; Insufficient bandwidth / "526" ; Insufficient bandwidth
/ "581" ; Does Not Exist / "581" ; Does Not Exist
5. Transport 6. Transport
The transport mechanism for MEGACOP has not been chosen. It is likely The transport mechanism for MEGACOP has not been chosen. It is likely
that TCP will be an option. If the SIGTRAN transport mechanism is suit- that TCP will be an option. If the SIGTRAN transport mechanism is suit-
able for MEGACO, that may be specified. It may be necessary to specify able for MEGACO, that may be specified. It may be necessary to specify
a transport protocol in this specification. Either the SIGTRAN mechan- a transport protocol in this specification. Either the SIGTRAN mechan-
ism or a MEGACO specified mechanism will be optional on the MG and ism or a MEGACO specified mechanism will be optional on the MG and
required on the MGC. required on the MGC.
5.1. Transport capabilities, and relationship to Transport Layer 6.1. Transport capabilities, and relationship to Transport Layer
Requirements for transport of the MEGACO protocol include: Requirements for transport of the MEGACO protocol include:
1) Reliable delivery of commands/responses. 1) Reliable delivery of commands/responses.
2) Ordered delivery of commands/responses to a particular "control 2) Ordered delivery of commands/responses to a particular "control
stream", this implies ordered delivery of commands to/from a par- stream", this implies ordered delivery of commands to/from a par-
ticular Termination or Context, but not necessarily ordered ticular Termination or Context, but not necessarily ordered
across Terminations or Contexts. across Terminations or Contexts.
skipping to change at page 53, line 5 skipping to change at page 55, line 5
4) Rapid detection of failure in a control stream. 4) Rapid detection of failure in a control stream.
5) Ability to achieve very high fanout from MGC to MGs. 5) Ability to achieve very high fanout from MGC to MGs.
6) Ability to handle multiple MGCs controlling individual MGs in a 6) Ability to handle multiple MGCs controlling individual MGs in a
distributed system and vice versa. However this must be optional distributed system and vice versa. However this must be optional
so that smaller/simpler systems can be efficiently implemented. so that smaller/simpler systems can be efficiently implemented.
7) Ability for the application to initiate flushing of messages 7) Ability for the application to initiate flushing of messages
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
successfully sent through the transport, for example to back off successfully sent through the transport, for example to back off
for failover handling. for failover handling.
Since transport needs are the same in all application states and Since transport needs are the same in all application states and
independent of what particular commands are being sent, it is logical to independent of what particular commands are being sent, it is logical to
think of the reliable transport as a separate layer, as shown below. think of the reliable transport as a separate layer, as shown below.
However, there is no accepted IETF protocol which focuses on the needs However, there is no accepted IETF protocol which focuses on the needs
of real time control as is needed by the MEGACO protocol. Therefore, the of real time control as is needed by the MEGACO protocol. Therefore, the
mechanisms to provide the required characteristics of the reliable tran- mechanisms to provide the required characteristics of the reliable tran-
skipping to change at page 53, line 34 skipping to change at page 55, line 34
------------------------------------------------- -------------------------------------------------
UDP UDP
------------------------------------------------- -------------------------------------------------
IP IP
------------------------------------------------- -------------------------------------------------
Ethernet, ATM, SONET, ... Ethernet, ATM, SONET, ...
Any message goes between one MG and one MGC. This has implications on Any message goes between one MG and one MGC. This has implications on
MG or MGC "farms". MG or MGC "farms".
6. Event packages and termination classes 7. Event Packages and Termination Classes
Termination classes are defined by: Termination Classes are defined by:
* A plain text description of the purpose of the termination class, * A plain text description of the purpose of the Termination Class,
* An SDP profile describing which SDP attributes are used in the the * An SDP profile describing which SDP attributes are used in the the
Local and Remote termination descriptions, Local and Remote Termination descriptors,
* A default value for the Local and Remote termination descriptions, * A default value for the Local and Remote Termination descriptions,
* The definition of statistics that can be collected on the termina- * The definition of statistics that can be collected on the Termina-
tion, tion,
* A list of events and signals that are defined for the termination, * A list of Events and Signals that are defined for the Termination,
The events and signals are grouped in "event packages", some of which The Events and Signals are grouped in "Event Packages", some of which
may apply to different termination classes. The list of events and sig- may apply to different Termination Classes. The list of Events and Sig-
nals applicable for a termination class must thus be defined by the list nals applicable for a Termination Class must thus be defined by the list
of applicable event packages. of applicable Event Packages.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
In this section, we will describe the most common event packages, and In this section, we will describe the most common Event Packages, and
then the most common termination classes. More packages and classes can then the most common Termination Classes. More Packages and Classes can
be defined in additional documents. be defined in additional documents.
6.1. Basic event packages 7.1. Basic Event Packages
The list of basic event packages includes the following: The list of basic Event Packages includes the following:
_________________________________________ _________________________________________
| Package | name | | Package | name |
|______________________________|_________| |______________________________|_________|
| Generic Media Package | G | | Generic Media Package | G |
| DTMF package | D | | DTMF Package | D |
| MF Package | M | | MF Package | M |
| Trunk Package | T | | Trunk Package | T |
| Line Package | L | | Line Package | L |
| Handset Package | H | | Handset Package | H |
| RTP Package | R | | RTP Package | R |
| Network Access Server Package| N | | Network Access Server Package| N |
| Announcement Server Package | A | | Announcement Server Package | A |
| Script Package | Script| | Script Package | Script|
|______________________________|_________| |______________________________|_________|
In the tables of events for each package, there are five columns: In the tables of Events for each Package, there are five columns:
Symbol: the unique symbol used for the event Symbol: the unique symbol used for the Event
Definition: a short description of the event Definition: a short description of the Event
R: an x appears in this column is the event can be Requested by R: an x appears in this column is the Event can be Requested by
the call agent. the call agent.
S: if nothing appears in this column for an event, then the event S: if nothing appears in this column for an Event, then the Event
cannot be signaled on command by the call agent. Otherwise, cannot be signaled on command by the call agent. Otherwise,
the following symbols identify the type of event: the following symbols identify the type of Event:
OO On/Off signal. The signal is turned on until commanded OO On/Off Signal. The Signal is turned on until commanded
by the call agent to turn it off, and vice versa. by the call agent to turn it off, and vice versa.
TO Timeout signal. The signal lasts for a given duration TO Timeout Signal. The Signal lasts for a given duration
unless it is superseded by a new signal. unless it is superseded by a new Signal.
BR Brief signal. The event has a short, known duration. BR Brief Signal. The Event has a short, known duration.
Duration: specifies the duration of TO signals. Duration: specifies the duration of TO Signals.
6.1.1. Generic Media Event package 7.1.1. Generic Media Event Package
Package Name: G Package Name: G
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
The generic media package group the events and signals that can be The generic media Package group the Events and Signals that can be
observed on several types of terminations, such as trunking gateways, observed on several types of Terminations, such as trunking gateways,
access gateways or residential gateways. access gateways or residential gateways.
_____________________________________________________________________ ______________________________________________________________________
| Symbol | Definition | R | S Duration | | Symbol | Definition | R | S Duration |
|__________|____________________________|_____|______________________| |__________|_____________________________|_____|______________________|
| mt | Modem detected | x | | | mt | Modem detected | x | |
| ft | Fax tone detected | x | | | fn | CalliNg Fax tone detected | x | |
| fd | CalleD Fax tone detected | x | |
| ld | Long duration connection | x | | | ld | Long duration connection | x | |
| pat(###) | Pattern ### detected | x | OO | | pat(###) | Pattern ### detected | x | OO |
| rt | Ringback tone | | TO | | rt | Ringback tone | | TO |
| rbk(###) | ring back on connection | | TO 180 seconds | | rbk(###) | ring back on connection | | TO 180 seconds |
| cf | Confirm tone | | BR | | cf | Confirm tone | | BR |
| cg | Network Congestion tone | | TO | | cg | Network Congestion tone | | TO |
| it | Intercept tone | | OO | | it | Intercept tone | | OO |
| pt | Preemption tone | | OO | | pt | Preemption tone | | OO |
| of | report failure | x | | | of | report failure | x | |
|__________|____________________________|_____|______________________| |__________|_____________________________|_____|______________________|
The signals are defined as follow: The Signals are defined as follow:
The pattern definition can be used for specific algorithms such as The pattern definition can be used for specific algorithms such as
answering machine detection, tone detection, and the like. answering machine detection, tone detection, and the like.
Ring back tone (rt) Ring back tone (rt)
an Audible Ring Tone, a combination of two AC tones with frequen- an Audible Ring Tone, a combination of two AC tones with frequen-
cies of 440 and 480 Hertz and levels of -19 dBm each, to give a cies of 440 and 480 Hertz and levels of -19 dBm each, to give a
combined level of -16 dBm. The cadence for Audible Ring Tone is 2 combined level of -16 dBm. The cadence for Audible Ring Tone is 2
seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR: seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR:
SIGNALING, Section 17.2.5. SIGNALING, Section 17.2.5.
Ring back on connection Ring back on connection
A ring back tone, applied to the connection whose identifier is A ring back tone, applied to the connection whose identifier is
passed as a property. passed as a property.
The "long duration connection" is detected when a connection has been The "long duration connection" is detected when a connection has been
established for more than 1 hour. established for more than 1 hour.
6.1.2. DTMF event package 7.1.2. DTMF Event Package
Package name: D Package name: D
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
_______________________________________________________________ _______________________________________________________________
| Symbol | Definition | R | S Duration | | Symbol | Definition | R | S Duration |
|________|___________________________|_____|___________________| |________|___________________________|_____|___________________|
| 0 | DTMF 0 | x | BR | | 0 | DTMF 0 | x | BR |
| 1 | DTMF 1 | x | BR | | 1 | DTMF 1 | x | BR |
| 2 | DTMF 2 | x | BR | | 2 | DTMF 2 | x | BR |
| 3 | DTMF 3 | x | BR | | 3 | DTMF 3 | x | BR |
| 4 | DTMF 4 | x | BR | | 4 | DTMF 4 | x | BR |
| 5 | DTMF 5 | x | BR | | 5 | DTMF 5 | x | BR |
skipping to change at page 56, line 34 skipping to change at page 58, line 34
| C | DTMF C | x | BR | | C | DTMF C | x | BR |
| D | DTMF D | x | BR | | D | DTMF D | x | BR |
| L | long duration indicator | x | 2 seconds| | L | long duration indicator | x | 2 seconds|
| X | Wildcard, match | x | | | X | Wildcard, match | x | |
| | any digit 0-9 | | | | | any digit 0-9 | | |
| T | Interdigit timer | x | 4 seconds| | T | Interdigit timer | x | 4 seconds|
| of | report failure | x | | | of | report failure | x | |
|________|___________________________|_____|___________________| |________|___________________________|_____|___________________|
The "interdigit timer" occurs when a long delay is observed after the The "interdigit timer" occurs when a long delay is observed after the
end of a digit detection. The event can only be observed if the termi- end of a digit detection. The Event can only be observed if the Termi-
nation is trying to acquire digits. Note that the definition of this nation is trying to acquire digits. Note that the definition of this
timer requires further study. In fact, the timer should take two dif- timer requires further study. In fact, the timer should take two dif-
ferent values, depending of the digit map and the digit string: ferent values, depending of the digit map and the digit string:
- If the gateway can determine that at least one more digit is - If the gateway can determine that at least one more digit is
requested for the digit string to match any of the allowed patterns requested for the digit string to match any of the allowed patterns
in the digit map, then the timer value should be set to a long in the digit map, then the timer value should be set to a long
duration, such as 16 seconds. duration, such as 16 seconds.
- If the digit map specifies that a variable number of additional - If the digit map specifies that a variable number of additional
digits may be needed (the "." indication at the end of a string), digits may be needed (the "." indication at the end of a string),
then the timer value should be set to a medium duration, such as 8 then the timer value should be set to a medium duration, such as 8
seconds. seconds.
- In some rare cases, such as optional additional digits, the timer - In some rare cases, such as optional additional digits, the timer
should be set to a short duration, 4 seconds. The current digit should be set to a short duration, 4 seconds. The current digit
map syntax does not allow for a distinction between the "medium" map syntax does not allow for a distinction between the "medium"
and "short" timer conditions, which implies that, in the current and "short" timer conditions, which implies that, in the current
version, there is no way to request a short timer. version, there is no way to request a short timer.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
The "long duration indicator" is observed when a DTMF signal is produced The "long duration indicator" is observed when a DTMF signal is produced
for a duration larger than two seconds. In this case, the gateway will for a duration larger than two seconds. In this case, the gateway will
detect two successive events: first, when the signal has been recog- detect two successive Events: first, when the Signal has been recog-
nized, the DTMF signal, and then, 2 seconds later, the long duration nized, the DTMF signal, and then, 2 seconds later, the long duration
signal. signal.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
6.1.3. MF Event package 7.1.3. MF Event Package
Package Name: M Package Name: M
________________________________________________________ ________________________________________________________
| Symbol | Definition | R | S Duration | | Symbol | Definition | R | S Duration |
|________|____________________|_____|___________________| |________|____________________|_____|___________________|
| 0 | MF 0 | x | BR | | 0 | MF 0 | x | BR |
| 1 | MF 1 | x | BR | | 1 | MF 1 | x | BR |
| 2 | MF 2 | x | BR | | 2 | MF 2 | x | BR |
| 3 | MF 3 | x | BR | | 3 | MF 3 | x | BR |
skipping to change at page 58, line 42 skipping to change at page 60, line 42
| S2 | MF S2 | x | BR | | S2 | MF S2 | x | BR |
| S3 | MF S3 | x | BR | | S3 | MF S3 | x | BR |
| wk | Wink | x | BR | | wk | Wink | x | BR |
| wko | Wink off | x | BR | | wko | Wink off | x | BR |
| is | Incoming seizure | x | OO | | is | Incoming seizure | x | OO |
| rs | Return seizure | x | OO | | rs | Return seizure | x | OO |
| us | Unseize circuit | x | OO | | us | Unseize circuit | x | OO |
| of | report failure | x | | | of | report failure | x | |
|________|____________________|_____|___________________| |________|____________________|_____|___________________|
The definition of the MF package events is as follow: The definition of the MF Package Events is as follow:
Wink Wink
A transition from unseized to seized to unseized trunk states A transition from unseized to seized to unseized trunk states
within a specified period. Typical seizure period is 100-350 within a specified period. Typical seizure period is 100-350
msec.) msec.)
Incoming seizure Incoming seizure
Incoming indication of call attempt. Incoming indication of call attempt.
Return seizure: Return seizure:
Seizure in response to outgoing seizure. Seizure in response to outgoing seizure.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Unseize circuit: Unseize circuit:
Unseizure of a circuit at the end of a call. Unseizure of a circuit at the end of a call.
Wink off: Wink off:
A signal used in operator services trunks. A transition from A Signal used in operator services trunks. A transition from
seized to unseized to seized trunk states within a specified period seized to unseized to seized trunk states within a specified period
of 100-350 ms. (To be checked) of 100-350 ms. (To be checked)
6.1.4. Trunk Event package 7.1.4. Trunk Event Package
Package Name: T Package Name: T
_____________________________________________________________________ _____________________________________________________________________
| Symbol | Definition | R | S Duration | | Symbol | Definition | R | S Duration |
|________|________________________________|_____|____________________| |________|________________________________|_____|____________________|
| co1 | Continuity tone (single tone,| x | OO | | co1 | Continuity tone (single tone,| x | OO |
| | or return tone) | | | | | or return tone) | | |
| co2 | Continuity test (go tone, | x | OO | | co2 | Continuity test (go tone, | x | OO |
| | in dual tone procedures) | | | | | in dual tone procedures) | | |
| lb | Loopback | | OO | | lb | Loopback | | OO |
| om | Old Milliwatt Tone (1000 Hz) | x | OO | | om | Old Milliwatt Tone (1000 Hz) | x | OO |
| nm | New Milliwatt Tone (1004 Hz) | x | OO | | nm | New Milliwatt Tone (1004 Hz) | x | OO |
| tl | Test Line | x | OO | | tl | Test Line | x | OO |
| zz | No circuit | x | OO | | zz | No circuit | x | OO |
| as | Answer Supervision | x | OO | | as | Answer Supervision | x | OO |
| ro | Reorder Tone | x | TO 30 seconds| | ro | Reorder Tone | x | TO 30 seconds|
| of | report failure | x | | | of | report failure | x | |
|________|________________________________|_____|____________________| |________|________________________________|_____|____________________|
The definition of the trunk package signal events is as follow: The definition of the trunk Package Signal Events is as follow:
Continuity Tone (co1): Continuity Tone (co1):
A tone at 2010 + or - 30 Hz. A tone at 2010 + or - 30 Hz.
Continuity Test (co2): Continuity Test (co2):
A tone at the 1780 + or - 30 Hz. A tone at the 1780 + or - 30 Hz.
Milliwatt Tones: Milliwatt Tones:
Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz) Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz)
Line Test: Line Test:
105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0
+ or -- 0.5dB). + or -- 0.5dB).
No circuit: No circuit:
(that annoying tri-tone, low to high) (that annoying tri-tone, low to high)
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Answer Supervision: Answer Supervision:
Reorder Tone: Reorder Tone:
Reorder tone is a combination of two AC tones with frequencies of Reorder tone is a combination of two AC tones with frequencies of
480 and 620 Hertz and levels of -24 dBm each, to give a combined 480 and 620 Hertz and levels of -24 dBm each, to give a combined
level of -21 dBm. The cadence for Station Busy Tone is 0.25 level of -21 dBm. The cadence for Station Busy Tone is 0.25
seconds on followed by 0.25 seconds off, repeating continuously. seconds on followed by 0.25 seconds off, repeating continuously.
See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.
The continuity tones are used when the call agent wants to initiate a The continuity tones are used when the call agent wants to initiate a
continuity test. There are two types of tests, single tone and dual continuity test. There are two types of tests, single tone and dual
tone. The Call agent is expected to know, through provisioning informa- tone. The Call agent is expected to know, through provisioning informa-
tion, which test should be applied to a given termination. For example, tion, which test should be applied to a given Termination. For example,
the controller that wants to initiate a single frequency test will send the controller that wants to initiate a single frequency test will send
to the gateway a command of the form: to the gateway a command of the form:
RQNT 1234 epx-t1/17@tgw2.example.net RQNT 1234 epx-t1/17@tgw2.example.net
X: AB123FE0 X: AB123FE0
S: co1 S: co1
R: co1 R: co1
If it wanted instead to initiate a dual-tone test, it would send the If it wanted instead to initiate a dual-tone test, it would send the
command: command:
skipping to change at page 60, line 43 skipping to change at page 62, line 43
S: co2 S: co2
R: co1 R: co1
The gateway would send the requested signal, and in both cases would The gateway would send the requested signal, and in both cases would
look for the return of the 2010 Hz tone (co1). When it detects that look for the return of the 2010 Hz tone (co1). When it detects that
tone, it must send the corresponding notification. tone, it must send the corresponding notification.
The tones are of type OO: the gateway must keep sending them until it The tones are of type OO: the gateway must keep sending them until it
receives a new notification request. receives a new notification request.
6.1.5. Line Event package 7.1.5. Line Event Package
Package Name: L Package Name: L
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
__________________________________________________________________________ __________________________________________________________________________
|Symbol | Definition | R | S Duration | |Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|_____________________| |_____________|______________________________|_____|_____________________|
|adsi(string) | adsi display | | BR | |adsi(string) | adsi display | | BR |
|vmwi | visual message | | TO | |vmwi | visual message | | TO |
| | waiting indicator | | | | | waiting indicator | | |
|hd | Off hook transition | x | | |hd | Off hook transition | x | |
|hu | On hook transition | x | | |hu | On hook transition | x | |
|hf | Flash hook | x | | |hf | Flash hook | x | |
skipping to change at page 62, line 5 skipping to change at page 64, line 5
A combined 350 + 440 Hz tone. A combined 350 + 440 Hz tone.
Visual Message Waiting Indicator Visual Message Waiting Indicator
The transmission of the VMWI messages must conform to the require- The transmission of the VMWI messages must conform to the require-
ments in Section 2.3.2, "On-hook Data Transmission Not Associated ments in Section 2.3.2, "On-hook Data Transmission Not Associated
with Ringing" in TR-H- 000030 and the CPE guidelines in SR-TSV- with Ringing" in TR-H- 000030 and the CPE guidelines in SR-TSV-
002476. VMWI messages must only be sent from the SPCS when the line 002476. VMWI messages must only be sent from the SPCS when the line
is idle. If new messages arrive while the line is busy, the VMWI is idle. If new messages arrive while the line is busy, the VMWI
indicator message must be delayed until the line goes back to the indicator message must be delayed until the line goes back to the
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
idle state. The CA should periodically refresh the CPE's visual idle state. The CA should periodically refresh the CPE's visual
indicator. See TR-NWT-001401 - Visual Message Waiting Indicator indicator. See TR-NWT-001401 - Visual Message Waiting Indicator
Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission
Interface. Interface.
Message waiting Indicator Message waiting Indicator
See GR-506-CORE, 17.2.3. See GR-506-CORE, 17.2.3.
Alerting Tone: Alerting Tone:
skipping to change at page 62, line 29 skipping to change at page 64, line 29
Rig splash Rig splash
Ringsplash, also known as "Reminder ring" is a burst of ringing Ringsplash, also known as "Reminder ring" is a burst of ringing
that may be applied to the physical forwarding line (when idle) to that may be applied to the physical forwarding line (when idle) to
indicate that a call has been forwarded and to remind the user that indicate that a call has been forwarded and to remind the user that
a CF subfeature is active. In the US, it is defined to be a 0.5(- a CF subfeature is active. In the US, it is defined to be a 0.5(-
0,+0.1) second burst of power ringing. See TR- TSY-000586 - Call 0,+0.1) second burst of power ringing. See TR- TSY-000586 - Call
Forwarding Subfeatures. Forwarding Subfeatures.
Call waiting tone Call waiting tone
Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting
feature is defined in TR-TSY-000571. By defining "wt" as a TO sig- feature is defined in TR-TSY-000571. By defining "wt" as a TO Sig-
nal you are really defining the feature which seems wrong to me nal you are really defining the feature which seems wrong to me
(given the spirit of MGCP), hence the definition of "wt" as a BR (given the spirit of MGCP), hence the definition of "wt" as a BR
signal in ECS, per GR-506-CORE. Also, it turns out that there is Signal in ECS, per GR-506-CORE. Also, it turns out that there is
actually four different call waiting tone patterns (see GR-506- actually four different call waiting tone patterns (see GR-506-
CORE, 14.2) so we should really have wt1, wt2, wt3, wt4, or some CORE, 14.2) so we should really have wt1, wt2, wt3, wt4, or some
parameterization. parameterization.
Recorder Warning Tone: Recorder Warning Tone:
1400 Hz of Tone of 0.5 second duration every 15 seconds. 1400 Hz of Tone of 0.5 second duration every 15 seconds.
SIT tone: SIT tone:
used for indicating a line is out of service. used for indicating a line is out of service.
Calling Card Service Tone: Calling Card Service Tone:
60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone), 60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone),
decaying exponentially with a time constant of 200 ms. decaying exponentially with a time constant of 200 ms.
Distinctive tone pattern: Distinctive tone pattern:
where ### is any number between 000 and 999, inclusive. Can be where ### is any number between 000 and 999, inclusive. Can be
used for distinctive ringing, customized dial tone, etc. used for distinctive ringing, customized dial tone, etc.
Report on completion Report on completion
The report on completion event is detected when the gateway was The report on completion Event is detected when the gateway was
asked to perform one or several signals of type TO on the termina- asked to perform one or several Signals of type TO on the Termina-
tion, and when these signals were completed without being stopped tion, and when these Signals were completed without being stopped
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
by the detection of a requested event such as off-hook transition by the detection of a requested Event such as off-hook transition
or dialed digit. The completion report may carry as property the or dialed digit. The completion report may carry as property the
name of the signal that came to the end of its live time, as in: name of the Signal that came to the end of its live time, as in:
O: L/oc(L/dl) O: L/oc(L/dl)
Ring back on connection Ring back on connection
A ring back tone, applied to the connection whose identifier is A ring back tone, applied to the connection whose identifier is
passed as a property. passed as a property.
We should note that many of these definitions vary from country to coun- We should note that many of these definitions vary from country to coun-
try. The frequencies listed above are the one in use in North America. try. The frequencies listed above are the one in use in North America.
There is a need to accommodate different tone sets in different coun- There is a need to accommodate different tone sets in different coun-
tries, and there is still an ongoing debate on the best way to meet that tries, and there is still an ongoing debate on the best way to meet that
requirement: requirement:
* One solution is to define different event packages specifying for * One solution is to define different Event Packages specifying for
example the German dial-tone as "L-DE/DL". example the German dial-tone as "L-DE/DL".
* Another solution is to use a management interface to specify on an * Another solution is to use a management interface to specify on an
end-point basis which frequency shall be associated to what tone. end-point basis which frequency shall be associated to what tone.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
6.1.6. Handset emulation event package 7.1.6. Handset emulation Event Package
Package Name: H Package Name: H
__________________________________________________________________________ __________________________________________________________________________
|Symbol | Definition | R | S Duration | |Symbol | Definition | R | S Duration |
|_____________|______________________________|_____|_____________________| |_____________|______________________________|_____|_____________________|
|adsi(string) | adsi display | x | BR | |adsi(string) | adsi display | x | BR |
|tdd | | | | |tdd | | | |
|vmwi | | | | |vmwi | | | |
|hd | Off hook transition | x | OO | |hd | Off hook transition | x | OO |
skipping to change at page 64, line 43 skipping to change at page 66, line 43
|v | Alerting Tone | x | OO | |v | Alerting Tone | x | OO |
|y | Recorder Warning Tone | x | OO | |y | Recorder Warning Tone | x | OO |
|t | SIT tone | x | | |t | SIT tone | x | |
|z | Calling Card Service Tone | x | OO | |z | Calling Card Service Tone | x | OO |
|oc | Report on completion | x | | |oc | Report on completion | x | |
|ot | Off hook warning tone | x | OO | |ot | Off hook warning tone | x | OO |
|s(###) | Distinctive tone pattern | x | BR | |s(###) | Distinctive tone pattern | x | BR |
|of | report failure | x | | |of | report failure | x | |
|_____________|______________________________|_____|_____________________| |_____________|______________________________|_____|_____________________|
The handset emulation package is an extension of the line package, to be The handset emulation Package is an extension of the line Package, to be
used when the gateway is capable of emulating a handset. The difference used when the gateway is capable of emulating a handset. The difference
with the line package is that events such as "off hook" can be signalled with the line Package is that Events such as "off hook" can be signalled
as well as detected. as well as detected.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
6.1.7. RTP Event package 7.1.7. RTP Event Package
Package Name: R Package Name: R
_________________________________________________________________ _________________________________________________________________
| Symbol | Definition | R | S Duration| | Symbol | Definition | R | S Duration|
|_________|______________________________|_____|_________________| |_________|______________________________|_____|_________________|
| UC | Used codec changed | x | | | UC | Used codec changed | x | |
| SR(###) | Sampling rate changed | x | | | SR(###) | Sampling rate changed | x | |
| JI(###) | Jitter buffer size changed | x | | | JI(###) | Jitter buffer size changed | x | |
| PL(###) | Packet loss exceeded | x | | | PL(###) | Packet loss exceeded | x | |
skipping to change at page 66, line 5 skipping to change at page 68, line 5
media gateway that the controller wants notification of any jitter media gateway that the controller wants notification of any jitter
buffer size changes. The syntax for notification from the media buffer size changes. The syntax for notification from the media
gateway to the controller is "JI(####)", where the #### is the new gateway to the controller is "JI(####)", where the #### is the new
size of the jitter buffer, in milliseconds. size of the jitter buffer, in milliseconds.
Packet Loss Exceeded: Packet Loss Exceeded:
Packet loss rate exceed the threshold of the specified decimal Packet loss rate exceed the threshold of the specified decimal
number of packets per 100,000 packets, where the packet loss number number of packets per 100,000 packets, where the packet loss number
is contained in parenthesis. For example, PL(10) indicates packets is contained in parenthesis. For example, PL(10) indicates packets
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
are being dropped at a rate of 1 in 10,000 packets. are being dropped at a rate of 1 in 10,000 packets.
Quality alert Quality alert
The packet loss rate or the combination of delay and jitter exceed The packet loss rate or the combination of delay and jitter exceed
a specified quality threshold. a specified quality threshold.
6.1.8. Network Access Server Event package 7.1.8. Network Access Server Event Package
Package Name: N Package Name: N
____________________________________________________________ ____________________________________________________________
| Symbol | Definition | R | S Duration| | Symbol | Definition | R | S Duration|
|________|__________________________|_____|_________________| |________|__________________________|_____|_________________|
| pa | Packet arrival | x | | | pa | Packet arrival | x | |
| cbk | Call back request | x | | | cbk | Call back request | x | |
| cl | Carrier lost | x | | | cl | Carrier lost | x | |
| au | Authorization succeeded| x | | | au | Authorization succeeded| x | |
| ax | Authorization denied | x | | | ax | Authorization denied | x | |
| of | Report failure | x | | | of | Report failure | x | |
|________|__________________________|_____|_________________| |________|__________________________|_____|_________________|
The packet arrival event is used to notify that at least one packet was The packet arrival Event is used to notify that at least one packet was
recently sent to an Internet address that is observed by an termination. recently sent to an Internet address that is observed by an Termination.
The event report includes the Internet address, in standard ASCII encod- The Event report includes the Internet address, in standard ASCII encod-
ing, between parenthesis: ing, between parenthesis:
O: pa(192.96.41.1) O: pa(192.96.41.1)
The call back event is used to notify that a call back has been The call back Event is used to notify that a call back has been
requested during the initial phase of a data connection. The event requested during the initial phase of a data connection. The Event
report includes the identification of the user that should be called report includes the identification of the user that should be called
back, between parenthesis: back, between parenthesis:
O: cbk(user25) O: cbk(user25)
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
6.1.9. Announcement Server Event package 7.1.9. Announcement Server Event Package
Package Name: A Package Name: A
___________________________________________________________________ ___________________________________________________________________
| Symbol | Definition | R | S Duration| | Symbol | Definition | R | S Duration|
|________________|________________________|_____|__________________| |________________|________________________|_____|__________________|
| ann(url,parms) | Play an announcement | | TO variable| | ann(url,parms) | Play an announcement | | TO variable|
| oc | Report on completion | x | | | oc | Report on completion | x | |
| of | Report failure | x | | | of | Report failure | x | |
|________________|________________________|_____|__________________| |________________|________________________|_____|__________________|
The announcement action is qualified by an URL name and by a set of ini- The announcement action is qualified by an URL name and by a set of ini-
tial properties as in for example: tial properties as in for example:
S: ann(http://scripts.example.net/all-lines-busy.au) S: ann(http://scripts.example.net/all-lines-busy.au)
The "operation complete" event must be detected when the announcement is The "operation complete" Event must be detected when the announcement is
played out. If the announcement cannot be played out, an operation played out. If the announcement cannot be played out, an operation
failure event can be returned. The failure may be explained by a com- failure Event can be returned. The failure may be explained by a com-
mentary, as in: mentary, as in:
O: A/of(file not found) O: A/of(file not found)
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
6.1.10. Script Event package 7.1.10. Script Event Package
Package Name: Script Package Name: Script
______________________________________________________________ ______________________________________________________________
| Symbol | Definition | R | S | Duration| | Symbol | Definition | R | S | Duration|
|___________|________________________|_____|______|___________| |___________|________________________|_____|______|___________|
| java(url) | Load a java script | | TO | variable| | java(url) | Load a java script | | TO | variable|
| perl(url) | Load a perl script | | TO | variable| | perl(url) | Load a perl script | | TO | variable|
| tcl(url) | Load a TCL script | | TO | variable| | tcl(url) | Load a TCL script | | TO | variable|
| xml(url) | Load an XML script | | TO | variable| | xml(url) | Load an XML script | | TO | variable|
skipping to change at page 69, line 5 skipping to change at page 71, line 5
O: script/oc(21223456794567,9738234567) O: script/oc(21223456794567,9738234567)
The failure report may also return a string, as in: The failure report may also return a string, as in:
O: script/oc(21223456794567,9738234567) O: script/oc(21223456794567,9738234567)
The definition of the script environment and the specific actions in The definition of the script environment and the specific actions in
that environment are for further study. that environment are for further study.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
6.2. Basic termination classes 7.2. Basic Termination Classes
We define the following basic termination types and profiles: We define the following basic Termination types and profiles:
* DS0 termination, * DS0 Termination,
* Analog termination, * Analog Termination,
* RTP termination, * RTP Termination,
* ATM termination, * ATM Termination,
* Network Access Termination. * Network Access Termination.
Editors' note: These are only the most basic termination types. There is Editors' note: These are only the most basic Termination types. There is
an obvious need to also define digital multiplexes (T1, E1, T3, E3) and an obvious need to also define digital multiplexes (T1, E1, T3, E3) and
the event that they support. the Events that they support.
6.2.1. DS0 Terminations 7.2.1. DS0 Terminations
DS0 terminations are digital circuits, providing a 64kbits (8bit times 8 DS0 Terminations are digital circuits, providing a 64kbits (8bit times 8
KHz) service. Such terminations are commonly used for interoffice KHz) service. Such Terminations are commonly used for interoffice
trunks. trunks.
DS0 terminations are always described in a symmetric fashion. The DS0 Terminations are always described in a symmetric fashion. The
RemoteTerminationDescriptor parameter is never used. RemoteTerminationDescriptor parameter is never used.
The LocalTerminationDescriptor may be used to specify the encoding of The LocalTerminationDescriptor may be used to specify the encoding of
the media. This parameter is described using SDP, with the following the media. This parameter is described using SDP, with the following
conventions: conventions:
* The connection data line is not used. A placeholder (c=LOCAL) can * The connection data line is not used. A placeholder (c=LOCAL) can
be used if this is required for compliance with the SDP syntax. be used if this is required for compliance with the SDP syntax.
* The "m=audio" property must specify a port number, which must * The "m=audio" property must specify a port number, which must
always be set to 0, the type of protocol, always set to the keyword always be set to 0, the type of protocol, always set to the keyword
DS0, and the type of encoding, using the same conventions used for DS0, and the type of encoding, using the same conventions used for
RTP (RTP payload numbers.) The type of encoding should normally be RTP (RTP payload numbers.) The type of encoding should normally be
set to 0 (PCM, mu law) or to 8 (PCM, A law). set to 0 (PCM, mu law) or to 8 (PCM, A law).
* The "a=echo" attribute must specify whether the gateway performs * The "a=echo" attribute must specify whether the gateway performs
echo cancellation. The property can have two values, "a:echo:on" echo cancellation. The property can have two values, "a:echo:on"
(when the echo cancellation is requested) and "a:echo:off" (when it (when the echo cancellation is requested) and "a:echo:off" (when it
is turned off.) is turned off.)
An example of specification could be: * The gain control attribute, encoded as the keyword "gc", followed
by a colon a value which can be either the keyword "auto" or a
decimal number (positive or negative) representing the number of
v=0 Internet draft MEGACO Protocol April 16, 1999
Internet draft MEGACO Protocol Proposal March 25, 1999 decibels of gain.
An example of specification could be:
v=0
c=LOCAL c=LOCAL
m=audio 0 DS0 0 m=audio 0 DS0 0
a=echo:on a=echo:on
The default configuration option is to use the mu-law encoding, and to The default configuration option is to use the mu-law encoding, with
apply echo cancellation. (We could define a variant of the DS0 class gain control set to auto, and to apply echo cancellation. (We could
which would, by default, use A-law encoding.) define a variant of the DS0 Class which would, by default, use A-law
encoding.)
Gateways are expected to be able to collect the following statistics on Gateways are expected to be able to collect the following statistics on
terminations of the DS0 class: Terminations of the DS0 Class:
Number of octets sent Number of octets sent, number of octets received
The number of octet sent is equal to the duration of the termina- The number of octet sent or received is equal to the duration of
tion, in seconds, multiplied by the sampling frequency, 8000 Hz. the Termination, in seconds, multiplied by the sampling frequency,
8000 Hz.
Terminations of the DS0 class are expected to provide the following sup- Terminations of the DS0 Class are expected to provide the following sup-
port for event packages: port for Event Packages:
_______________________________________________________________________ _______________________________________________________________________
|Package | name | support in DS0 class | |Package | name | support in DS0 Class |
|______________________|__________|___________________________________| |______________________|__________|___________________________________|
|Generic Media Package | G | Mandatory | |Generic Media Package | G | Mandatory |
|Trunk Package | T | Mandatory | |Trunk Package | T | Mandatory |
|DTMF package | D | Optional (for credit cards, etc)| |DTMF Package | D | Optional (for credit cards, etc)|
|MF Package | M | Optional (for MF trunks) | |MF Package | M | Optional (for MF trunks) |
|Announcement | A | Optional (when gateway | |Announcement | A | Optional (when gateway |
|Server Package | | can play announcement on DS0) | |Server Package | | can play announcement on DS0) |
|Script Package | Script | Optional | |Script Package | Script | Optional |
|______________________|__________|___________________________________| |______________________|__________|___________________________________|
6.2.2. Analog Terminations 7.2.2. Analog Terminations
Analog terminations are analog circuits, typically connected through an Analog terminations are analog circuits, typically connected through an
RJ11 interface. Such terminations are commonly found in residential RJ11 interface. Such Terminations are commonly found in residential
gateways. gateways.
Analog terminations are always described in a symmetric fashion. The Analog Terminations are always described in a symmetric fashion. The
RemoteTerminationDescriptor parameter is never used. RemoteTerminationDescriptor parameter is never used.
Internet draft MEGACO Protocol April 16, 1999
The LocalTerminationDescriptor may be used to specify the encoding of The LocalTerminationDescriptor may be used to specify the encoding of
the media. This parameter is described using SDP, with the following the media. This parameter is described using SDP, with the following
conventions: conventions:
* The connection data line is not used. A placeholder (c=LOCAL) can * The connection data line is not used. A placeholder (c=LOCAL) can
be used if this is required for compliance with the SDP syntax. be used if this is required for compliance with the SDP syntax.
Internet draft MEGACO Protocol Proposal March 25, 1999
* The "m=audio" property is only used for conformance with the SDP * The "m=audio" property is only used for conformance with the SDP
syntax. It is set to a conventional value, specifying a null port, syntax. It is set to a conventional value, specifying a null port,
an ANALOG type and a null type of encoding. an ANALOG type and a null type of encoding.
* The "a=echo" attribute must specify whether the gateway performs * The "a=echo" attribute must specify whether the gateway performs
echo cancellation. The property can have two values, "a:echo:on" echo cancellation. The property can have two values, "a:echo:on"
(when the echo cancellation is requested) and "a:echo:off" (when it (when the echo cancellation is requested) and "a:echo:off" (when it
is turned off.) is turned off.)
* The gain control attribute, encoded as the keyword "gc", followed
by a colon a value which can be either the keyword "auto" or a
decimal number (positive or negative) representing the number of
decibels of gain.
An example of specification could be: An example of specification could be:
v=0 v=0
c=LOCAL c=LOCAL
m=audio 0 ANALOG 0 m=audio 0 ANALOG 0
a=echo:on a=echo:on
The default configuration option is to apply echo cancellation. The default configuration option is to apply echo cancellation, and to
have gain control set to auto.
Gateways are expected to be able to collect the following statistics on Gateways are expected to be able to collect the following statistics on
terminations of the analog class: Terminations of the analog Class:
Number of octets sent Number of octets sent, number of octets received
The number of octet sent is equal to the duration of the termina- The number of octet sent or received is equal to the duration of
tion, in seconds, multiplied by the sampling frequency, 8000 Hz. the Termination, in seconds, multiplied by the sampling frequency,
8000 Hz.
Terminations of the analog class are expected to provide the following Terminations of the analog Class are expected to provide the following
support for event packages: support for Event Packages:
Internet draft MEGACO Protocol April 16, 1999
____________________________________________________________________ ____________________________________________________________________
| Package | name | support in analog class | | Package | name | support in analog Class |
|_______________________|__________|________________________________| |_______________________|__________|________________________________|
| Generic Media Package | G | Mandatory | | Generic Media Package | G | Mandatory |
| DTMF Package | D | Mandatory | | DTMF Package | D | Mandatory |
| Line Package | L | Mandatory | | Line Package | L | Mandatory |
| Handset Package | H | Optional (when gateway | | Handset Package | H | Optional (when gateway |
| | | can set outgoing calls on | | | | can set outgoing calls on |
| | | the analog termination) | | | | the analog Termination) |
| Announcement | A | Optional (when gateway | | Announcement | A | Optional (when gateway |
| Server Package | | can play announcements on the| | Server Package | | can play announcements on the|
| | | termination) | | | | Termination) |
| Script Package | Script | Optional | | Script Package | Script | Optional |
|_______________________|__________|________________________________| |_______________________|__________|________________________________|
6.2.3. RTP Audio Terminations 7.2.3. RTP Audio Terminations
RTP terminations are use to describe the local termination of packet
Internet draft MEGACO Protocol Proposal March 25, 1999
RTP Terminations are use to describe the local Termination of packet
connections established through the RTP, UDP and IP protocols. The RTP connections established through the RTP, UDP and IP protocols. The RTP
Audio termination class is applied when the RTP terminations convey an Audio Termination Class is applied when the RTP Terminations convey an
audio media. (Other termination classes may be used for other media, audio media. (Other Termination Classes may be used for other media,
such as video.) such as video.)
The encoding of the media in point to point RTP terminations is The encoding of the media in point to point RTP Terminations is
described by two sets of properties, the LocalTerminationDescriptor and described by two sets of properties, the LocalTerminationDescriptor and
the RemoteTerminationDescriptor. Both are described using SDP, with the the RemoteTerminationDescriptor. Both are described using SDP, with the
following conventions: following conventions:
* The IP address of the remote gateway (in commands) or of the local * The IP address of the remote gateway (in commands) or of the local
gateway (in responses), or multicast address of the audio confer- gateway (in responses), or multicast address of the audio confer-
ence, encoded as an SDP "connection data" parameter. This parameter ence, encoded as an SDP "connection data" parameter. This parameter
specifies the IP address that must be used to exchange RTP packets. specifies the IP address that must be used to exchange RTP packets.
* Media description field (m) specifying the audio media, the tran- * Media description field (m) specifying the audio media, the tran-
skipping to change at page 72, line 36 skipping to change at page 75, line 4
list should normally always include the code 0 (reserved for G.711, list should normally always include the code 0 (reserved for G.711,
mu law). mu law).
* Optionally, RTPMAP attributes that define the encoding of dynamic * Optionally, RTPMAP attributes that define the encoding of dynamic
audio formats, audio formats,
* Optionally, a packetization period (packet time) attribute (Ptime) * Optionally, a packetization period (packet time) attribute (Ptime)
defining the duration of the packet, defining the duration of the packet,
* Optionally, an encryption key attribute ("k"), specifying the * Optionally, an encryption key attribute ("k"), specifying the
Internet draft MEGACO Protocol April 16, 1999
encryption and the key for the RTP packets, as defined in SDP. encryption and the key for the RTP packets, as defined in SDP.
* Optionally, an attribute defining the type of connection (sendonly, * Optionally, an attribute defining the type of connection (sendonly,
recvonly, sendrecv, inactive). Note that this attribute does not recvonly, sendrecv, inactive). Note that this attribute does not
have a direct relation with the "Mode" property of the termination. have a direct relation with the "Mode" property of the Termination.
In fact, the SDP type of connection will most of the time be set to In fact, the SDP type of connection will most of the time be set to
"sendrecv", regardless of the value used for the termination. "sendrecv", regardless of the value used for the Termination.
Other values will only be used rarely, for example in the case of Other values will only be used rarely, for example in the case of
information or announcement servers that need to establish one way information or announcement servers that need to establish one way
connections. connections.
An example of specification could be: An example of specification could be:
v=0 v=0
c=IN IP4 128.96.41.1 c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96 m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000 a=rtpmap:96 G726-32/8000
Internet draft MEGACO Protocol Proposal March 25, 1999
{Editor's Note: in some cases, there is a need to specify the RTP
and RTCP port that will be used for the reverse direction, when
these ports are different from the receiving ports. One possibil-
ity is to use a second "m=audio" line, optionally followed by a
"c=" line.}
The default configuration for the LocalTerminationDescriptor is to use The default configuration for the LocalTerminationDescriptor is to use
one of the IP addresses of the gateway, to select a UDP port for RTP, one of the IP addresses of the gateway, to select a UDP port for RTP,
and to use the PCM mu-law algorithm. and to use the PCM mu-law algorithm.
Gateways are expected to be able to collect the following statistics on Gateways are expected to be able to collect the following statistics on
terminations of the RTP class: Terminations of the RTP Class:
Number of packets sent: Number of packets sent:
The total number of RTP data packets transmitted by the sender The total number of RTP data packets transmitted by the sender
since starting transmission on this connection. The count is not since starting transmission on this connection. The count is not
reset if the sender changes its synchronization source identifier reset if the sender changes its synchronization source identifier
(SSRC, as defined in RTP), for example as a result of a Modify com- (SSRC, as defined in RTP), for example as a result of a Modify com-
mand. The value is zero if the connection was set in "receive only" mand. The value is zero if the connection was set in "receive only"
mode. mode.
Number of octets sent: Number of octets sent:
skipping to change at page 73, line 42 skipping to change at page 76, line 5
sender changes its SSRC identifier, for example as a result of a sender changes its SSRC identifier, for example as a result of a
Modify command. The value is zero if the connection was set in Modify command. The value is zero if the connection was set in
"receive only" mode. "receive only" mode.
Number of packets received: Number of packets received:
The total number of RTP data packets received by the sender since The total number of RTP data packets received by the sender since
starting reception on this connection. The count includes packets starting reception on this connection. The count includes packets
received from different SSRC, if the sender used several values. received from different SSRC, if the sender used several values.
The value is zero if the connection was set in "send only" mode. The value is zero if the connection was set in "send only" mode.
Internet draft MEGACO Protocol April 16, 1999
Number of octets received: Number of octets received:
The total number of payload octets (i.e., not including header or The total number of payload octets (i.e., not including header or
padding) transmitted in RTP data packets by the sender since start- padding) transmitted in RTP data packets by the sender since start-
ing transmission on this connection. The count includes packets ing transmission on this connection. The count includes packets
received from different SSRC, if the sender used several values. received from different SSRC, if the sender used several values.
The value is zero if the connection was set in "send only" mode. The value is zero if the connection was set in "send only" mode.
Number of packets lost: Number of packets lost:
The total number of RTP data packets that have been lost since the The total number of RTP data packets that have been lost since the
beginning of reception. This number is defined to be the number of beginning of reception. This number is defined to be the number of
packets expected less the number of packets actually received, packets expected less the number of packets actually received,
where the number of packets received includes any which are late or where the number of packets received includes any which are late or
duplicates. The count includes packets received from different duplicates. The count includes packets received from different
Internet draft MEGACO Protocol Proposal March 25, 1999
SSRC, if the sender used several values. Thus packets that arrive SSRC, if the sender used several values. Thus packets that arrive
late are not counted as lost, and the loss may be negative if there late are not counted as lost, and the loss may be negative if there
are duplicates. The count includes packets received from different are duplicates. The count includes packets received from different
SSRC, if the sender used several values. The number of packets SSRC, if the sender used several values. The number of packets
expected is defined to be the extended last sequence number expected is defined to be the extended last sequence number
received, as defined next, less the initial sequence number received, as defined next, less the initial sequence number
received. The count includes packets received from different SSRC, received. The count includes packets received from different SSRC,
if the sender used several values. The value is zero if the connec- if the sender used several values. The value is zero if the connec-
tion was set in "send only" mode. This property is omitted if the tion was set in "send only" mode. This property is omitted if the
connection was set in "data" mode. connection was set in "data" mode.
skipping to change at page 74, line 42 skipping to change at page 77, line 4
is the average value of the difference between the NTP timestamp is the average value of the difference between the NTP timestamp
indicated by the senders of the RTCP messages and the NTP timestamp indicated by the senders of the RTCP messages and the NTP timestamp
of the receivers, measured when this messages are received. The of the receivers, measured when this messages are received. The
average is obtained by summing all the estimates, then dividing by average is obtained by summing all the estimates, then dividing by
the number of RTCP messages that have been received. This property the number of RTCP messages that have been received. This property
is omitted if the connection was set in "data" mode. is omitted if the connection was set in "data" mode.
When the MG's clock is not synchronized by NTP, the latency value When the MG's clock is not synchronized by NTP, the latency value
can be computed as one half of the round trip delay, as measured can be computed as one half of the round trip delay, as measured
through RTCP. through RTCP.
When the MG cannot compute the one way delay or the round trip When the MG cannot compute the one way delay or the round trip
Internet draft MEGACO Protocol April 16, 1999
delay, the property conveys a null value. delay, the property conveys a null value.
For a detailed definition of these variables, refer to RFC 1889. For a detailed definition of these variables, refer to RFC 1889.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Terminations of the RTP class are expected to provide the following sup- Terminations of the RTP Class are expected to provide the following sup-
port for event packages: port for Event Packages:
_____________________________________________________________ _____________________________________________________________
| Package | name | support in RTP class | | Package | name | support in RTP Class |
|_______________________|__________|_________________________| |_______________________|__________|_________________________|
| RTP Package | R | Mandatory | | RTP Package | R | Mandatory |
| Generic Media Package | G | Mandatory | | Generic Media Package | G | Mandatory |
| DTMF Package | D | Optional (e.g. in | | DTMF Package | D | Optional (e.g. in |
| | | IVR units) | | | | IVR units) |
| Announcement | A | Optional (when gateway| | Announcement | A | Optional (when gateway|
| Server Package | | can play announcement | | Server Package | | can play announcement |
| | | on RTP) | | | | on RTP) |
| Script Package | Script | Optional | | Script Package | Script | Optional |
|_______________________|__________|_________________________| |_______________________|__________|_________________________|
6.2.4. ATM audio terminations 7.2.4. ATM audio Terminations
(Editor's note: The following description is provisional and indi-
cative. It will have to be reworked on by ATM specialists.)
ATM terminations are use to describe the local termination of packet ATM Terminations are use to describe the local Termination of packet
connections established over ATM networks. The RTP Audio termination connections established over ATM networks. The RTP Audio Termination
class is applied when the RTP terminations convey an audio media. (Other Class is applied when the RTP Terminations convey an audio media. (Other
termination classes may be used for other media, such as video.) Termination Classes may be used for other media, such as video.)
The encoding of the media in point to point RTP terminations is The encoding of the media in point to point RTP Terminations is
described by two sets of properties, the LocalTerminationDescriptor and described by two sets of properties, the LocalTerminationDescriptor and
the RemoteTerminationDescriptor. Both are described using SDP, with the the RemoteTerminationDescriptor. Both are described using SDP, with the
following conventions: following conventions:
* The "c=" property of SDP to specifies an address in the ATM family, * The "c=" property of SDP to specifies an address in the ATM family,
the ATM addressing variant (NSAP, UNI, E.164) and the ATM address. the ATM addressing variant (NSAP, UNI, E.164) and the ATM address.
* The "m=audio" property must specify the audio encoding and, if * The "m=audio" property must specify the audio encoding and, if
needed, the VPI and VCI. needed, the VPI and VCI.
skipping to change at page 76, line 5 skipping to change at page 78, line 52
ATM coding variants, such as the type of adaptation layer and the ATM coding variants, such as the type of adaptation layer and the
error correction or loss compensation algorithms. error correction or loss compensation algorithms.
An example of SDP payload for an ATM connection could be: An example of SDP payload for an ATM connection could be:
v=0 v=0
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe
m=audio 5/1002 ATM/AVP G.711u m=audio 5/1002 ATM/AVP G.711u
a=connection_type:AAL2 a=connection_type:AAL2
Internet draft MEGACO Protocol Proposal March 25, 1999
The default configuration for the LocalTerminationDescriptor is to use The default configuration for the LocalTerminationDescriptor is to use
Internet draft MEGACO Protocol April 16, 1999
one of the ATM addresses of the gateway, to select a VPI and a VCI, and one of the ATM addresses of the gateway, to select a VPI and a VCI, and
to use the PCM mu-law algorithm. to use the PCM mu-law algorithm.
Editor's note: unclear whether we want to have exactly one ATM ter-
mination type, or several, e.g. AAL1 and AAL2.
Gateways are expected to be able to collect the following statistics on Gateways are expected to be able to collect the following statistics on
terminations of the ATM class: Terminations of the ATM Class:
Number of packets sent: Number of packets sent:
The total number of ATM cells transmitted since starting transmis- The total number of ATM cells transmitted since starting transmis-
sion on this connection. sion on this connection.
Number of octets sent: Number of octets sent:
The total number of payload octets transmitted in ATM cells. The total number of payload octets transmitted in ATM cells.
Number of packets received: Number of packets received:
The total number of ATM cells received since starting reception on The total number of ATM cells received since starting reception on
skipping to change at page 77, line 5 skipping to change at page 80, line 5
Should be determined as the number of cells lost, or set to zero if Should be determined as the number of cells lost, or set to zero if
the adaptation layer does not enable the MG to assess losses. the adaptation layer does not enable the MG to assess losses.
Interarrival jitter: Interarrival jitter:
The interarrival jitter between ATM cells. The interarrival jitter between ATM cells.
Average transmission delay: Average transmission delay:
The MG may not be able to assess this property over an ATM network. The MG may not be able to assess this property over an ATM network.
It could simply report a null value. It could simply report a null value.
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
Terminations of the ATM class are expected to provide the following sup- Terminations of the ATM Class are expected to provide the following sup-
port for event packages: port for Event Packages:
_____________________________________________________________ _____________________________________________________________
| Package | name | support in ATM class | | Package | name | support in ATM Class |
|_______________________|__________|_________________________| |_______________________|__________|_________________________|
| ATM Package | A | Mandatory | | ATM Package | A | Mandatory |
| Generic Media Package | G | Mandatory | | Generic Media Package | G | Mandatory |
| DTMF Package | D | Optional (e.g. in | | DTMF Package | D | Optional (e.g. in |
| | | IVR units) | | | | IVR units) |
| Announcement | A | Optional (when gateway| | Announcement | A | Optional (when gateway|
| Server Package | | can play announcement | | Server Package | | can play announcement |
| | | on ATM) | | | | on ATM) |
| Script Package | Script | Optional | | Script Package | Script | Optional |
|_______________________|__________|_________________________| |_______________________|__________|_________________________|
(Editor's note: the ATM event package is not yet defined.) 7.2.5. Network access service Termination
6.2.5. Network access service termination
(Editor's note: this package definition is really a place holder. (Editor's note: this Package definition is really a place holder.
It will most probably have to be extensively reworked by the WG.) It will most probably have to be extensively reworked by the WG.)
A network access service (NAS) termination describes the attachment of A network access service (NAS) Termination describes the attachment of
the context to a network access service such as a generic Internet the Context to a network access service such as a generic Internet
access or a tunnel to a private network server. access or a tunnel to a private network server.
The NAS termination is described by a single LocalTerminationDescriptor The NAS Termination is described by a single LocalTerminationDescriptor
parameter. The RemoteTerminationDescriptor parameter is not used. The parameter. The RemoteTerminationDescriptor parameter is not used. The
LocalTerminationDescriptor is described using SDP with the following LocalTerminationDescriptor is described using SDP with the following
conventions: conventions:
* Media description field (m) specifying the network access media, * Media description field (m) specifying the network access media,
identified by the code "m=nas/xxxx", where "xxxx" describes the identified by the code "m=nas/xxxx", where "xxxx" describes the
access control method that should be used for parameterizing the access control method that should be used for parameterizing the
network access, as specified below. The field may also specify the network access, as specified below. The field may also specify the
port that should be used for contacting the server, as specified in port that should be used for contacting the server, as specified in
the SDP syntax. the SDP syntax.
* Connection address property (c=) specifying the address, or the * Connection address property (c=) specifying the address, or the
domain name, of the server that implement the access control domain name, of the server that implement the access control
method. This property may also be specified at the session level. method. This property may also be specified at the session level.
* Optionally, a bearer type attribute (a=bearer:) describing the type * Optionally, a bearer type attribute (a=bearer:) describing the type
of data connection to be used, including the modem type. of data connection to be used, including the modem type.
* Optionally, a framing type attribute (a=framing:) describing the * Optionally, a framing type attribute (a=framing:) describing the
Internet draft MEGACO Protocol Proposal March 25, 1999
type of framing that will be used on the channel. type of framing that will be used on the channel.
Internet draft MEGACO Protocol April 16, 1999
* Optionally, attributes describing the called number (a=dialed:), * Optionally, attributes describing the called number (a=dialed:),
the number to which the call was delivered (a=called:) and the cal- the number to which the call was delivered (a=called:) and the cal-
ling number (a=dialing:). ling number (a=dialing:).
* Optionally, attributes describing the range of addresses that could * Optionally, attributes describing the range of addresses that could
be used by the dialup client on its LAN (a=subnet:). be used by the dialup client on its LAN (a=subnet:).
* Optionally, an encryption key, encoded as specified in the SDP * Optionally, an encryption key, encoded as specified in the SDP
protocol(k=). protocol(k=).
skipping to change at page 79, line 5 skipping to change at page 82, line 5
access the service. That key, in particular, may be used for the estab- access the service. That key, in particular, may be used for the estab-
lishment of an L2TP tunnel. lishment of an L2TP tunnel.
The bearer attribute is composed of a bearer name and an optional exten- The bearer attribute is composed of a bearer name and an optional exten-
sion. The bearer type specifies the type of modulation (modem name) or, sion. The bearer type specifies the type of modulation (modem name) or,
in the case of digital connections, the type of ISDN service (8 bits, 7 in the case of digital connections, the type of ISDN service (8 bits, 7
bits). When an extension is present, it is separated from the bearer bits). When an extension is present, it is separated from the bearer
name by a single slash (/). The valid values of the bearer attribute name by a single slash (/). The valid values of the bearer attribute
are defined in the following table: are defined in the following table:
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
____________________________________________________________________ ____________________________________________________________________
| Type of bearer description | Example of values | | Type of bearer description | Example of values |
|_________________________________|_________________________________| |_________________________________|_________________________________|
| ITU modem standard | V.32, V.34, V.90. | | ITU modem standard | V.32, V.34, V.90. |
| ITU modem standard qualified | v.90/3com, | | ITU modem standard qualified | v.90/3com, |
| by a manufacturer name | v.90/rockwell, | | by a manufacturer name | v.90/rockwell, |
| | v.90/xxx | | | v.90/xxx |
| Well known modem types | X2, K56flex | | Well known modem types | X2, K56flex |
| ISDN transparent access, 64 kbps| ISDN64 | | ISDN transparent access, 64 kbps| ISDN64 |
skipping to change at page 80, line 5 skipping to change at page 83, line 5
address" are formatted as defined for the connection address property address" are formatted as defined for the connection address property
(c=) in SDP, and where the "prefix length" is a decimal representation (c=) in SDP, and where the "prefix length" is a decimal representation
of the number of bits in the prefix. of the number of bits in the prefix.
Examples of SDP announcement for the network access service could be: Examples of SDP announcement for the network access service could be:
v=0 v=0
m=nas/radius m=nas/radius
c=IN IP4 radius.example.net c=IN IP4 radius.example.net
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
a=bearer:v.34 a=bearer:v.34
a=framing:ppp-asynch a=framing:ppp-asynch
a=dialed:18001234567 a=dialed:18001234567
a=called:12345678901 a=called:12345678901
a=dialing:12340567890 a=dialing:12340567890
v=0 v=0
m=nas/none m=nas/none
c=IN IP4 128.96.41.1 c=IN IP4 128.96.41.1
skipping to change at page 80, line 31 skipping to change at page 83, line 31
v=0 v=0
c=IN IP4 access.example.net c=IN IP4 access.example.net
m=nas/l2tp m=nas/l2tp
k=clear:some-shared-secret k=clear:some-shared-secret
a=bearer:v.32 a=bearer:v.32
a=framing:ppp-asynch a=framing:ppp-asynch
a=dialed:18001234567 a=dialed:18001234567
a=dialing:2345678901 a=dialing:2345678901
There is no default value of the properties defined for this termination There is no default value of the properties defined for this Termination
class.(Editor's note: we may have to define more specific classes, such Class.(Editor's note: we may have to define more specific Classes, such
as "Internet Access", for which the defaults would apply.) as "Internet Access", for which the defaults would apply.)
The following statistics can be collected on NAS terminations: The following statistics can be collected on NAS Terminations:
Number of packets sent: Number of packets sent:
The total number of NAS packets transmitted since starting The total number of NAS packets transmitted since starting
transmission on this connection. transmission on this connection.
Number of octets sent: Number of octets sent:
The total number of octets transmitted in NAS packets. The total number of octets transmitted in NAS packets.
Number of packets received: Number of packets received:
The total number of packets received since starting reception on The total number of packets received since starting reception on
this connection. this connection.
Number of octets received: Number of octets received:
The total number of octets received in NAS packets. The total number of octets received in NAS packets.
Terminations of the NAS class are expected to provide the following sup- Terminations of the NAS Class are expected to provide the following sup-
port for event packages: port for Event Packages:
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
______________________________________________ ______________________________________________
| Package | name | support in NAS class| | Package | name | support in NAS Class|
|____________|________|_______________________| |____________|________|_______________________|
| NAS Package| N | Mandatory | | NAS Package| N | Mandatory |
|____________|________|_______________________| |____________|________|_______________________|
7. Acknowledgements 8. Acknowledgements
The authors would like to thank the fine crews of the numerous airlines The authors would like to thank the fine crews of the numerous airlines
that carried them around the world to a succession of interesting meet- that carried them around the world to a succession of interesting meet-
ings, their family members whom they left alone during said meetings, ings, their family members whom they left alone during said meetings,
their colleagues and their staff. their colleagues and their staff.
We would also like to extend special thanks to the members of the MEGACO We would also like to extend special thanks to the members of the MEGACO
design team, Nancy-M Greene, Glen Freundlich, David Auerbach, Rex Col- design team, Nancy-M Greene, Glen Freundlich, David Auerbach, Rex Col-
dren, Dave Oran, Flemming Andreassen, Hong Liu, Michael Ramalho, Gur dren, Dave Oran, Flemming Andreassen, Hong Liu, Michael Ramalho, Gur
Kimchi, Graeme Gibbs, Brian Hill, Ike Elliott, Bob Bell, and Matt Hol- Kimchi, Graeme Gibbs, Brian Hill, Ike Elliott, Bob Bell, and Matt Hol-
dredge. dredge.
In fact, we would like to thank all the members of the MEGACO working In fact, we would like to thank all the members of the MEGACO working
group, and its chair, Tom Taylor. group, and its chair, Tom Taylor.
8. References 9. References
* Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A * Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January Transport Protocol for Real-Time Applications", RFC 1889, January
1996. 1996.
* Schulzrinne, H., "RTP Profile for Audio and Video Conferences with * Schulzrinne, H., "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, January 1996 Minimal Control", RFC 1890, January 1996
* Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC * Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC
2327, April 1998. 2327, April 1998.
skipping to change at page 82, line 5 skipping to change at page 85, line 5
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
* ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN * ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN
USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984;
modified at Helsinki, 1993) modified at Helsinki, 1993)
* ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIG- * ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIG-
NALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga- NALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-
Torremolinos, 1984; modified at Helsinki, 1993) Torremolinos, 1984; modified at Helsinki, 1993)
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
* ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA COM- * ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA COM-
MUNICATIONS SYSTEMS." MUNICATIONS SYSTEMS."
* ITU-T, Recommendation H.225, "Call Signaling Protocols and Media * ITU-T, Recommendation H.225, "Call Signaling Protocols and Media
Stream Packetization for Packet Based Multimedia Communications Stream Packetization for Packet Based Multimedia Communications
Systems." Systems."
* ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MUL- * ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MUL-
TIMEDIA COMMUNICATION." TIMEDIA COMMUNICATION."
skipping to change at page 82, line 28 skipping to change at page 85, line 28
RFC 2401, November 1998. RFC 2401, November 1998.
* Atkinson, R., "IP Authentication Header." RFC 2402, December 1998. * Atkinson, R., "IP Authentication Header." RFC 2402, December 1998.
* Atkinson, R., "IP Encapsulating Security Payload (ESP)." RFC 2406, * Atkinson, R., "IP Encapsulating Security Payload (ESP)." RFC 2406,
November 1998. November 1998.
* Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: * Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997. ABNF", RFC 2234, November 1997.
9. Authors' Addresses 10. Authors' Addresses
Fernando Cuervo, Fernando Cuervo,
Nortel Networks Nortel Networks
Ottawa, ON, Canada Ottawa, ON, Canada
EMail: cuervo@nortelnetworks.com EMail: cuervo@nortelnetworks.com
Christian Huitema Christian Huitema
Telcordia Technologies Telcordia Technologies
445 South Street 445 South Street
Morristown, NJ 07960 Morristown, NJ 07960
skipping to change at page 83, line 5 skipping to change at page 86, line 5
Brian Rosen Brian Rosen
FORE Systems FORE Systems
1000 FORE Drive 1000 FORE Drive
Warrendale, PA 15086 Warrendale, PA 15086
EMail: brosen@eng.fore.com EMail: brosen@eng.fore.com
Paul Sijben Paul Sijben
Lucent Technologies Lucent Technologies
Internet draft MEGACO Protocol Proposal March 25, 1999 Internet draft MEGACO Protocol April 16, 1999
PO box 18 PO box 18
1270 AA Huizen 1270 AA Huizen
the Netherlands the Netherlands
Phone: +31 35 687 4774 Phone: +31 35 687 4774
Email: sijben@lucent.com Email: sijben@lucent.com
Eric Zimmerer Eric Zimmerer
Level3 Communications Level3 Communications
1450 Infinite Drive 1450 Infinite Drive
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/