Internet DRAFT - draft-cuervo-megaco-mgcp-compromise
draft-cuervo-megaco-mgcp-compromise
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:26:21 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 01 Mar 1999 20:55:39 GMT
ETag: "2e6ed3-db57-36dafecb"
Accept-Ranges: bytes
Content-Length: 56151
Connection: close
Content-Type: text/plain
Internet Engineering Task Force Peter Blatherwick
INTERNET DRAFT Fernando Cuervo
<draft-cuervo-megaco-mgcp-compromise-00.txt> Nancy Greene
Category: Graeme Gibbs
Expires: August 26, 1999 Nortel Networks
A Proposal for a two-ended connection model for MGCP
Fernando Cuervo, Graeme Gibbs, Nancy Greene
February 26, 1999
<draft-cuervo-megaco-mgcp-compromise-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working docu-
ments as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The connection model in MGCP grew from a half-connection model, to, more
recently, a model that allows a second edgepoint to be specified [3]. In
this document, we have taken the connection model a step further, making
it symmetrical, identifying the difference between external connections
and an MG- connection, allowing signalling related commands to be asso-
ciated with either edgepoint, or with both edgepoints in an MG. While
the half-connection model may work best for the simple case of MGs with
an external IP connection on one side, the proposed more general connec-
tion model adapts easily when the MG is for packet to packet connec-
tions, when the MG is TDM on one side and IP on the other, as well as
when the external connections are ATM on either side of an MG.
Table of Contents
Blatherwick, Cuervo, Greene, Gibbs [Page 1]
Internet draft MEGACO Requirements 26 February 1999
1.0 Introduction
2.0 Two-ended connection model for MGCP
2.1 Edgepoints and Media Descriptors
3.0 Alias model
4.0 Transport capabilities of MGCP, and relationship to Transport Layer
5.0 Proposal for Way Forward
6.0 References
7.0 Authors' Addresses
Appendix A
A1.0 Proposed Commands
A2.0 Call flow for Tom's Case 1: DTMF line dialing into VoIP Gateway
A3.0 Call flow for a hairpin connection on an MG
A4.0 Call flows with ATM as the backbone network
A5.0 Mapping of the proposed commands to MGCP commands in [3]
A6.0 Table comparing this proposal to [1] and [3]
1.0 Introduction
The connection model in MGCP grew from a half-connection model, to, more
recently, a half-connection model that allows a second edgepoint to be
specified ([3], see appendix A in that draft). In this document, we have
taken the connection model a step further, making it symmetrical, iden-
tifying the difference between external connections and an MG-
connection, allowing signalling related commands to be associated with
either edgepoint, or with both edgepoints in an MG. While the half-
connection model may work best for the simple case of MGs with an exter-
nal IP connection on one side, the proposed more general connection
model adapts easily when the MG is for packet to packet connections,
when the MG is TDM on one side and IP on the other, as well as when the
external connections are ATM on either side of an MG. The extended con-
nection model retains support for the half-connection model in [3].
2.0 Two-ended connection model for MGCP
The two-ended connection model is used to join two Edgepoints. The ele-
ments of the model are:
* 1-an MGConnection, which explicitly establishes that two edgepoints
in an MG are connected,
* 2-the edgepoint MediaDescriptors and their corresponding External-
ConnectionIds. These describe the media streams at the edgepoints.
Blatherwick, Cuervo, Greene, Gibbs [Page 2]
Internet draft MEGACO Requirements 26 February 1999
ExternalConnectionIds identify the assignment of a MediaDescriptor
to an edgepoint, The ExternalConnectionId can only be modified when
the edgepoint is reset.
* 3-the CallId that is used to link edgepoints and their Medi-
aDescriptors, ExternalConnectionIds and MGConnections. It is possi-
ble to modify MediaDescriptors, remove or add edgepoints and MGCon-
nections without changing the CallId.
ingress MG egress MG
+----+ +----+
E1ExternalConnId | | E2ExternalConnId | |
+E1MediaDescriptor| | +E2MediaDescriptor | |
| E1 E2 | | |
V | | V | |
----------------o o - - - - - - - - -- o o------------
| | | |
+----+ +----+
^
|
MG-ConnectionId (labels the internal connection between E1 &
E2)
Figure 1: Two ended MG-connection
2.1 Edgepoints and Media Descriptors
Edgepoint:
An edgepoint is identified locally by an edgepoint identifier (i.e.,
EdgepointId) and a Network Address (as specified in the c= part of SDP).
If it is useful, the EdgepointId may be equal to its network address but
this is not necessary. In order to efficiently support a half-connection
model, an edgepoint may have one or more "aliases". This can be inter-
preted as the edgepoint having multiple points of presence in multiple
networks. (This addresses the issue that has been raised with an RTP
port being "artificial").
Media Descriptor:
The media capabilities of an edgepoint are described by a MediaDescrip-
tor. This descriptor may change with every new connection and may also
have some predetermined characteristics. These characteristics may, how-
ever, be altered upon realization of a connection. For instance u-Law,
Blatherwick, Cuervo, Greene, Gibbs [Page 3]
Internet draft MEGACO Requirements 26 February 1999
G.711 and echo cancellation can be the base characteristics of a TDM
edgepoint. When the edgepoint is used in a connection, its definition is
enhanced by a MediaDescriptor that contains (for instance):
* bandwidth
* TOS bits
* c= type information about the other end of the connection (c= is
SDP terminology)
* one or more m= for the definition of the media streams that it
handles (m= is SDP terminology).
Notice that all pieces of this information are eventually optional,
since whether it is needed or not depends on the edgepoint type or pro-
visioning.
The values of several of these fields are defined in the SDP standard
[5]. For some of the fields, it may state exactly one value, or it may
provide a loose specification, such as a list of allowed encoding
methods, or a range of packetization periods.
If the edgepoint has one or more aliases, then the media description is
added for each alias. The media adaptation that takes place in the MG is
derived from the MediaDescriptors for the edgepoint and the aliases.
The use of aliases implements the half-connection model presented in
MGCP. In this case, the edgepoint and the aliases share the same Exter-
nalConnectionId.
For the more general model with two edgepoints, each edgepoint in the
connection is described by a MediaDescriptor.
An MG-ConnectionId is issued to uniquely identify a connection between
two edgepoints in the MG. Again, any media transformation to be done in
the MG is derived from the MediaDescriptors configured for each
edgepoint.
3.0 Alias model
The purpose of the alias model is to realise a "half call connection
model". It applies when a connectionless network is used between media
gateways. For instance, the alias gives to an edgepoint (e.g., DS0s at
E1 and Ea) an address that is significant to the network between the
ingress and egress MGs. Once the addressing information (i.e., the
alias) is complemented by media descriptors, the edgepoint is capable of
Blatherwick, Cuervo, Greene, Gibbs [Page 4]
Internet draft MEGACO Requirements 26 February 1999
performing bi-directional media adaptation. The directionality of the
end-to-end flow is controlled by the "mode" of each one of the external
connections involved in the call.
---send E1 alias (e.g. MG IP address, port, media descriptor)-- >
< --receive Ea alias (e.g., remote MG IP address, port,..) ---
ingress MG egress MG
+----+ +----+
E1ExternalConnId | | | | EaExternalConnId
+E1MediaDescriptor | | | | +EaMediaDescriptor
| E1 | | Ea
V | | | |
----------------o o - - - - - - - - - - o o------------
| | IP network | |
+----+ +----+
e.g.,TDM network e.g., TDM network
Figure 2: Edgepoints as aliases
4.0 Transport capabilities of MGCP, and relationship to Transport Layer
Requirements for transport of gateway control and edgepoint-related sig-
nalling (eg. Channel Associated Signalling / Edgepoint Associated Sig-
nalling) include:
* 1-Reliable delivery of command messaging.
* 2-Ordered delivery of command messaging pertaining to a particular
control stream. Assuming the connection/resource model described
here, this implies ordered delivery of commands to/from a particu-
lar edgepoint, but not necessarily ordered across edgepoints. This
means that the application interface provided by the transport
allows for differentiation between these control streams.
* 3-Limited maximum time to deliver commands.
* 4-Rapid detection of failure in a control stream.
* 5-Ability to achieve very high fanout from MGC to MGs.
* 6-Ability to handle multiple MGCs controlling individual MGs in a
distributed system. However this must be optional so that
smaller/simpler systems can be efficiently implemented.
* 7-Ability for the application to initiate flushing of messages
Blatherwick, Cuervo, Greene, Gibbs [Page 5]
Internet draft MEGACO Requirements 26 February 1999
not
successfully sent through the transport, for example to back off
for failover handling.
ISSUE: re requirement 6, do we need to support multiple MGCs controlling
individual edgepoints within an MG.
Since transport needs are the same in all application states and
independent of what particular commands are being sent, it seems logical
to think of Megaco transport as a separate layer, as shown below.
Application layer:
Gateway control | Edgepoint-related signalling
-------------------------------------------------
Reliable transport
-------------------------------------------------
UDP
-------------------------------------------------
IP
-------------------------------------------------
Ethernet, ATM, SONET, ...
Note that in order to correctly track state transitions and handle fail-
overs, it is expected that the application level would make use of com-
mand responses as indicated in the command section. For example if a
command is successfully passed to the far end through transport, but
fails to complete due to resource limitations, this information would
still be passed back to the sender. This is a separate issue from tran-
sport.
ISSUE: It is not clear however, if transport should be implemented as a
separate protocol to Megaco, or if it should be directly included.
There is currently no accepted IETF protocol which focuses on the needs
of real time control as is needed by Megaco. Sigtran has similar needs
as well.
4.1 Application Layer Assumptions
Application layer is concerned only with command/response interactions
between MGC and MG. Commands have corresponding responses to allow
tracking of command execution at the application level. This is not
tied to the underlying reliability mechanisms, to separate these con-
cerns.
Blatherwick, Cuervo, Greene, Gibbs [Page 6]
Internet draft MEGACO Requirements 26 February 1999
The command embedding described here allows for individual commands to
be sent or for commands to be embedded in an arbitrary way. In this
way, commands that need to be sent together because of, for instance,
fate sharing and ordering get the assurance of traveling on a single
transport unit.
The application level is responsible for deciding whether to initiate
failover handling if it receives notification of transport failure.
(Failover handling is a separate topic.)
The application should be able to skip messages that are not processed.
For instance, using the commands proposed in Appendix A, ApplySignal
commands that do not get processed within an application required time
might be flushed as a side effect of DeleteMGConnection or an Edgepoin-
tReset, or directly by SignallingConfig command.
ISSUE: It is unclear if command/transaction numbering would be required
at the application level under these assumptions, since the transport
layer would handle sequencing and separation of command streams to dif-
ferent edgepoints.
4.2 Transport interface
Interface to the transport protocol would include the following command
semantics:
* Open channel (stream identifier, UDP address/port)
* Close channel (stream identifier)
* Send (stream identifier, message)
* Flush (stream identifier).
Note under the current connection proposal in Appendix A, stream iden-
tifier would be SigConnectionId.
A mechanism is also assumed to indicate failure of a control stream,
likely based on a callback.
ISSUE: Need to be able to configure timeouts, window size, etc. Should
this be per channel? What specific parameters can be configured depends
on details of underlying protocol.
ISSUE: Interface is not really a protocol issue, but needs to be dis-
cussed somewhere to ensure everything hangs together.
Blatherwick, Cuervo, Greene, Gibbs [Page 7]
Internet draft MEGACO Requirements 26 February 1999
4.3 Reliable Transport protocol
Simplest possible reliable transport protocol needs to be defined to
accommodate requirements set out above. This can be similar to the pro-
posal contained in [3], but should be expanded somewhat for improved
efficiency.
Properties of the reliable transport protocol are as follows:
* Aggressive retransmit policy, interval initially very close to RTT
(fairly well known in an engineered network).
* Very limited retransmit attempts (say order of 3 - 5 tries).
* Retransmits exponentially back off to avoid undue congestion. Max-
imum duration of retransmit behaviour is therefore strictly lim-
ited.
* Re-ordering internal to the reliable UDP protocol handler, over a
small window.
* No adaptive behaviour.
* Parameters could be set by the MGC (or through SNMP?)
* Above parameters should be balanced so that maximum time before
giving up (retransmits failed, link assumed broken) is around 1 - 2
sec. The impatient human in the loop will give up at around that
time anyway.
ISSUE: A specific proposal for reliable transport over UDP is required.
5.0 Proposal for Way Forward
The intent of this document is to reduce the current debates of one
Megaco protocol proposal versus another, and begin the process of
compromising towards mutually agreeable solutions.
As such, the draft attempts to focus on issues and separation of con-
cerns, offering compromise positions between existing proposals. Our
separation of concerns is based on logical decomposition of the problem
space, topics which have been hotly debated on the list, and some which
clearly need to be. The draft is work in progress, it does not cover
all aspects of the protocol. Some of them may need debate, others can be
taken from existing proposals. Therefore it leaving some areas open, to
be filled in as agreeable solutions become apparent. Of course, these
Blatherwick, Cuervo, Greene, Gibbs [Page 8]
Internet draft MEGACO Requirements 26 February 1999
positions will not initially make everyone happy, but we hope to move
this debate to issues and to meeting known requirements.
5.1 Why a new version of MGCP?
The main issues we have changed with MGCP in its present state [3] are:
* 1) it uses a half connection model in its CreateConnection command.
The half connection model is appropriate when the transport network
is IP, but for other transports, such as ATM, it is necessary to
allow separate attributes on a second edgepoint in order to control
it independently. [3] does allow a second edgepoint, but does not
allow separate attributes to be assigned to that edgepoint.
* 2) MGCP derives a lot of power from its ability to embed commands.
We propose a more powerful method for this embedding, that allows
simpler basic commands which can be combined more easily to build
more complex commands.
* 3) The way of telling an edgepoint to handle signalling has been
improved. Methods such as scripts, digit maps, etc., are supported.
In addition there is a capability to indicate signalling backhaul
and a corresponding mechanism to allow the application to request
ordered treatment of commands on a per edgepoint basis.
* 4) An improved definition of the transport capabilities of MGCP,
and their relationship to Transport Layer.
5.2 Role of appendix A
The appendix of this document provides a message set and call flows for
TDM to IP, TDM to TDM (hairpin), and for TDM to ATM. The TDM to IP call
flow shows that the messages retain the simplicity found in [3] for the
same call flow. The other call flows show the flexibility and strengths
of the 2-edgepoint connection model for ATM. Embedded commands are used
to ensure that commands are executed together or not at all. This con-
cept is also used in [3], and [4].
It is proposed to use the alias concept as a way of consolidating the
two connection models for MGCP (in [1] and [3]). As well, the message
set proposed here provides new names and simplification of command
structure for many of the messages found in [3].
The appendix ends with a table that compares command names and concepts
in this proposal to those in [1], and [3].
Blatherwick, Cuervo, Greene, Gibbs [Page 9]
Internet draft MEGACO Requirements 26 February 1999
6.0 References
[1] MDCP: http://www.ietf.org/internet-drafts/draft-sijben-megaco-mdcp-
01.txt
[2] Nortel's 2-ended connection model for MGCP:
http://www.ietf.org/internet- drafts/draft-cuervo-megaco-mgcp-00.txt
(this document)
[3] Bellcore/Cisco's MGCP: http://www.ietf.org/internet-drafts/draft-
huitema- megaco-mgcp-v0r1-0x.txt
[4] http://www.ietf.org/internet-drafts/draft-huitema-megaco-mgcp-
firewall- 00.txt
[5] Session Description Protocol
7.0 Authors' Addresses
Peter Blatherwick
Nortel Networks
Ottawa, ON, Canada
Email: blather@nortelnetworks.com
Fernando Cuervo
Nortel Networks
Ottawa, ON, Canada
EMail: cuervo@nortelnetworks.com
Graeme Gibbs
Nortel Networks
England
Email: gibbs@nortelnetworks.com
Nancy Greene
Nortel Networks
Ottawa, ON, Canada
Email: ngreene@nortelnetworks.com
Appendix A - proposed commands, and call flows
A1.0 Proposed Commands
Blatherwick, Cuervo, Greene, Gibbs [Page 10]
Internet draft MEGACO Requirements 26 February 1999
A1.1 MediaAdaptationConfig:
ExtConnectionId,
MediaDescriptor,
[ListOf: Alias, AliasMediaDescriptor]
<--- MediaAdaptationConfig (CallId,
EdgepointId,
ExtConnMode,
MediaDescriptor
[ListOf: Alias,
RemoteMediaDescriptor])
description of the command:
The objective of the command is to indicate to the MG that the media
flows entering or leaving the MG need media adaptation. The media adap-
tation is resolved by the MG from the edgepoint MediaDescriptor and the
alias and remote MediaDescriptors. The alias is an IP or transport
address. As a result of the difference in the MediaDescriptors, the MG
creates a fully formed media unit for the alias address type (i.e., an
IP packet or an ATM PDU).
CallId is an identifier assigned by the MGC
EdgepointId is a string of local significance to the MGC-MG, i.e.,
"BlueEP". It denotes an interface.
Alias is a network address.
MediaDescriptors are extended SDP-type descriptors.
ExtConnectionId is an MG assigned identifier that indicates a reset in
the Media Adaptation Configuration of an edgepoint.
A1.2 ModifyExtConnMode:
<--- ModifyExtConnMode(ExternalConnectionId,
ExtConnMode)
description of the command:
The objective of this command is to modify the mode of an external con-
nection, it can take values such as loopback, send, receive, sndrecv.
Blatherwick, Cuervo, Greene, Gibbs [Page 11]
Internet draft MEGACO Requirements 26 February 1999
A1.3 SignallingConfig:
[sigConnectionId]
<--- SignallingConfig(RequestId,
EdgepointId,
CallAgentId,
[SignallingDescriptor,]
[embeddedApplySignal] )
description of the command:
The objective of the command is to indicate to the MG that the CAS (or
Edgepoint AS or Facility Associated Signalling) of an edgepoint is to be
handled by a CallAgentId (i.e., the id of an MGC or a process within the
MGC). The SignallingDescriptor is a way to describe the signallling (it
could be a digit map or a pointer to a script, etc.). The embedded apply
signal is used to generate a signal on the edgepoint upon loading the
SignallingDescriptor. RequestId is used to correlate this request with
the notifications that it triggers.
Example of signalling descriptor: may include, signalling type: Q.931,
digit map, script-pointer(URL?), signals, events, state machine, tran-
sport: MDCP, Megaco, Sigtran, etc.
SigConnectionId is a handle that allows the transport to identify com-
mands that require relative ordering. It is not assumed that this exists
or is used in all cases.
A1.4 ApplySignal:
<--- ApplySignal ([SigConnectionId,]
EdgepointId,
CallAgentId,
SignalDescriptor)
description of the command:
Once an edgepoint is provisioned with a Signalling descriptor, the
designated CallAgent can ask the edgepoint to apply signals (i.e., ring-
ing). The signal descriptor is constrained by the SignallingDescriptor,
which acts as a filter as defined in section A1.3. If available, the
SigConnectionId is used by the application to indicate partial ordering
to the reliable transport layer.
Blatherwick, Cuervo, Greene, Gibbs [Page 12]
Internet draft MEGACO Requirements 26 February 1999
A1.5 NotifyEvent:
<--- NotifyEvent ([SigConnectionId,]
RequestId,
EdgepointId,
CallAgentId,
EventDescriptor)
description of the command:
once an edgepoint is provisioned with a Signalling descriptor, the
designated edgepoint can generate events (i.e., off-hook) that its
loaded SignallingDescriptor allows it to observe. If available, the
SigConnectionId is used by the application to indicate partial ordering
to the reliable transport layer.
A1.6 CreateMGConnection:
MGConnectionId,
ExtConnection1Id,
ExtConnection2Id,
[SpecificEdgepoint1Id,
[embeddedMediaAdaptationConfigResp],
[embeddedSignallingConfigResp] ],
[SpecificEdgepoint2Id,
[embeddedMediaAdaptationConfigResp],
[embeddedSignallingConfigResp] ]
<--- CreateMGConnection(CallId,
Edgepoint1Id,
ExtConn1Mode,
[embeddedMediaAdaptationConfig,]
[embeddedSignallingConfig,]
[embeddedApplySignal,]
Edgepoint2Id,
ExtConn2Mode,
[embeddedMediaAdaptationConfig,]
[embeddedSignallingConfig,]
[embeddedApplySignal] )
description of the command:
This command is only used to set direct connections between edgepoints
that provide external connections. The external connection mode refers
to loopbacks, directionality, etc. that can be applied at different
points in the call to the edgepoints involved. Embedded media and
Blatherwick, Cuervo, Greene, Gibbs [Page 13]
Internet draft MEGACO Requirements 26 February 1999
signalling configurations are allowed for each edgepoint. Note that you
don't use this command for IP core networks, the MediaAdaptationConfig
is used in this case.
ExtConnectionId remains unchanged between resets or outages of the
edgepoint. It is also used to check synchronism between the controller
and the MG.
A1.7 ModifyMGConnection:
<--- ModifyMGConnection(MGConnectionId,
Embedded ModifyExtConnMode,
[Embedded ModifyExtConnMode])
description of the command:
changes only the modes of one or both of the external connections that
are related to an MGConnection. EdgepointMode: Internal Loopback,
External Loopback, Bothway Loopback, OutofService, Ready, Send, Receive,
Sendrecv
A1.8 DeleteMGConnection:
<--- DeleteMGConnection(CallId,
[MGConnectionId,]
[embedded EdgepointReset,
[embedded EdgepointReset] ] )
description of the command:
Removes an MGConnection, notice that the external connections do not get
removed unless the embedded EdgepointResets are provided for each
edgepoint involved in the MGConnection, therefore, a delete connection
does not undo the media adaptations, these need to be removed separately
or by embedded edgepoint resets.
A1.9 EdgepointReset:
Blatherwick, Cuervo, Greene, Gibbs [Page 14]
Internet draft MEGACO Requirements 26 February 1999
ExtConnectionId,
[ListOf: MGConnectionId]
<--- EdgepointReset(CallId,
[EdgepointId],
[embedded SignallingConfg,]
[ListOf: Alias)])
description of the command:
EdgepointReset undoes the work of the MediaAdaptationConf. With
MediaAdaptationConf an edgepoint may be assigned an edgepoint Medi-
aDescriptor and alias Mediadescriptors. The EdgepointReset, when only
parametrized by a CallId, removes all edgepoints' media adaptations,
external connections and MG- connections related to a call.
When the EdgepointId is provided, it deletes media adaptations, external
configurations and MG-connections that belong to the EdgepointId. When a
list of aliases is passed only the aliases' media adaptations are
removed, the external connection id remains active.
A1.10 Issue:
A command that deletes a call and all connection ids associated with
that call is need.
A2.0 Call flow for Tom's Case 1: DTMF line dialing into VoIP Gateway
Blatherwick, Cuervo, Greene, Gibbs [Page 15]
Internet draft MEGACO Requirements 26 February 1999
Calling Gateway Called Gatekeeper
| 1. Off-hook -->| | |
|<-- 2. Dial tone | | |
|3. First digit-->| | |
|<4. No dial tone | | |
|5. Digit -->| | |
...
|10. Digit -->| | |
| | 11. Admission Request (ARQ)---->|
| |<---12. Admission confirm (ACF) |
| | 13. SETUP -->| |
| | | 14. ARQ -->|
| | |<-- 15. ACF |
| |<-- 16. ALERTING | |
|<-- 17. ringback | | |
| |<-- 18. CONNECT | |
|<- 19. cutthrough| | |
...
| 20. On-hook -->| | |
| | 21. RELEASE -->| |
| |<-- 22. RLC | |
...
Note that the syntax used to describe this call flow (and subsequent
ones)is verbose to aid in the understanding of the flow. If text encod-
ing is used for this protocol, then a more terse description of the com-
mands and parameters, and a corresponding EBNF will be defined.
0a: SignallingConfig sent from MGC to MG
SignallingConfig <TransactionId=1200> MEGACOP x.x
RequestId:0123456789AB // to correlate the event with this config
EdgepointId= edgepoint/1@mg-1235.something.net
CallAgentId= ca@ca1.something.net
SignallingDescriptor= lineside_package(hd, digit collection)
0b: SignallingConfigResp from MG to MGC
SignallingConfigResp <TransactionId=1200> MEGACOP x.x
10a: NotifyEvent from MG to MGC
NotifyEvent <TransactionId=1201> MEGACOP x.x
RequestId=123456789AB
CallAgentId=ca@ca1.something.net
EventDescriptor= dialedNumber: 1234567 //observed events
Blatherwick, Cuervo, Greene, Gibbs [Page 16]
Internet draft MEGACO Requirements 26 February 1999
The number 1234567 is the number assigned to a friend's H.323 Client
installation.
10b: NotifyEventResp from MGC to MG
NotifyEventResp <TransactionId=1201> MEGACOP x.x
12a: MediaAdaptationConfig from MGC to MG
MediaAdaptationConfig <TransactionId=1203> MEGACOP x.x
CallId: abcdefg
EdgepointId: edgepoint/1@mg-1234.something.net
ExtConnMode:recvonly
MediaDescriptor:
L: p=10, a:G.711;G.726-32
ListOf:{
{Alias:*,
RemoteMediaDescriptor: //***info on the egress side - blank for now
}
Alias is wildcarded. RemoteMediaDescriptor is blank.
12b: MediaAdaptationConfigResp
MediaAdaptationConfigResp <TransactionId=1203> MEGACOP x.x
ExtConnectionId:yyy
MediaDescriptor:
L: p=10, a:G.711;G.726-32
ListOf:{
{Alias:47.123.456.789:3456,
AliasMediaDescriptor:
v=0
c=IN IP4 47.123.456.789
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G.726-32/8000
a=recvonly}
Alias and AliasMediaDescriptor are now filled in.
16a: ApplySignal sent from MGC to MG
ApplySignal <TransactionId=1204> MEGACOP x.x
EdgepointId: edgepoint/1@mg-1235.something.net
CallAgentId: ca@ca1.something.net
SignalDescriptor:v
Blatherwick, Cuervo, Greene, Gibbs [Page 17]
Internet draft MEGACO Requirements 26 February 1999
ApplySignal with SignalDescriptor set to v applies alerting/ringback to
the edgepoint.
16b: ApplySignalResp from MG to MGC
ApplySignalResp <TransactionId=1204> MEGACOP x.x
18a: ModifyExtConnMode from MGC to MG
ModifyExtConnMode <TransactionId=1205> MEGACOP x.x
ExtConnectionId:yyy
ExtConnMode: sendrecv
Use ModifyExtConnMode to change the mode of the external connection to
be sendrecv.
18b: ModifyExtConnModeResp from MG to MGC
ModifyExtConnModeResp <TransactionId=1205> MEGACOP x.x
20a: NotifyEvent from MG to MGC
NotifyEvent <TransactionId=1206> MEGACOP x.x
RequestId=123456789AB
CallAgentId: ca@ca1.something.net
EventDescriptor:hu
The MG has detected a hang-up event (hu).
20b: NotifyEventResp from MGC to MG
NotifyEventResp <TransactionId=1206> MEGACOP x.x
22a: EdgepointReset from MGC to MG
EdgepointReset <TransactionId=1207> MEGACOP x.x //for edgepoint1
CallId:abcdefg //passing only the CallId means call has terminated
The EdgepointReset deletes the external connectionId yyy for the call
CallId. Sending this command with only the CallId present means the call
has terminated.
22b: EdgepointResetResp from MG to MGC
EdgepointResetResp <TransactionId=1207> MEGACOP x.x
Blatherwick, Cuervo, Greene, Gibbs [Page 18]
Internet draft MEGACO Requirements 26 February 1999
A3.0 Call flow for a hairpin connection on an MG
0a: SignallingConfig sent from MGC to MG
SignallingConfig <TransactionId=1200> MEGACOP x.x
RequestId:0123456789AB // to correlate the event with this config
EdgepointId= edgepoint/1@mg-1235.something.net
CallAgentId= ca@ca1.something.net
SignallingDescriptor= lineside_package(hd, digit collection)
0b: SignallingConfigResp from MG to MGC
SignallingConfigResp <TransactionId=1200> MEGACOP x.x
Configure signalling of first edgepoint.
0c: SignallingConfig sent from MGC to MG
SignallingConfig <TransactionId=1201> MEGACOP x.x
RequestId:0123456789AB // to correlate the event with this config
EdgepointId= edgepoint/2@mg-1235.something.net
CallAgentId= ca@ca1.something.net
SignallingDescriptor= lineside_package(hd, digit collection)
0d: SignallingConfigResp from MG to MGC
SignallingConfigResp <TransactionId=1201> MEGACOP x.x
Configure signalling of second edgepoint.
10a: NotifyEvent from MG to MGC
NotifyEvent <TransactionId=1201> MEGACOP x.x
RequestId=123456789AB
CallAgentId=ca@ca1.something.net
EventDescriptor= dialedNumber: 1234567 //observed events
In the NotifyEvent, the number 1234567 is that of a called party on the
same MG.
Blatherwick, Cuervo, Greene, Gibbs [Page 19]
Internet draft MEGACO Requirements 26 February 1999
10b: NotifyEventResp from MGC to MG
NotifyEventResp <TransactionId=1201> MEGACOP x.x
10c: CreateMGConnection from MGC to MG
CreateMGConnection <TransactionId=1202> MEGACOP x.x
CallId: A3C47F21456789F0
Edgepoint1Id: edgepoint/1@mg-1234.something.net
ExtConn1Mode: sendrecv
{embeddedMediaAdaptationConfig
MediaDescriptor:
v=0
c=LOCAL EPN edgepoint/2
m=audio 0 LOCAL 0 }
{embeddedApplySignal
SignalDescriptor: v} //ringback
Edgepoint2Id: edgepoint/2@mg-1234.something.net
ExtConn1Mode: sendrecv
{embeddedMediaAdaptationConfig
MediaDescriptor:
v=0
c=LOCAL EPN edgepoint/1
m=audio 0 LOCAL 0 }
{embeddedApplySignal
SignalDescriptor: rg}
In this case, the MGC assigns the two edgepoints of the call. Both
edgepoints have loaded a signalling package for looking for on-hooks,
off-hooks, etc.
10d: CreateMGConnectionResp from MG to MGC
CreateMGConnectionResp <TransactionId=1202> MEGACOP x.x
MGConnectionId=xxx
ExtConnection1Id=yyy
ExtConnection2Id=zzz
10e: NotifyEvent from MG to MGC
NotifyEvent <TransactionId=1203> MEGACOP x.x
RequestId=123456789AB
EdgepointId= edgepoint/2@mg-1235.something.net
CallAgentId=ca@ca1.something.net
EventDescriptor= hd //observed events
Blatherwick, Cuervo, Greene, Gibbs [Page 20]
Internet draft MEGACO Requirements 26 February 1999
The MG sends a NotifyEvent when the second edgepoint picks up the phone
(hd event).
10f: NotifyEventResp from MGC to MG
NotifyEventResp <TransactionId=1203> MEGACOP x.x
10g: SignallingConfig sent from MGC to MG
SignallingConfig <TransactionId=1204> MEGACOP x.x
RequestId:0123456789AB // to correlate the event with this config
EdgepointId= edgepoint/2@mg-1235.something.net
CallAgentId= ca@ca1.something.net
SignallingDescriptor= hu
SignallingConfig is sent to program the MG to now look for a hang-up
(hu) on edgepoint/2. Note - 10g would be needed if the hu was not in the
package the edgepoint is using, and must be configured explicitly.
10h: SignallingConfigResp from MG to MGC
SignallingConfigResp <TransactionId=1204> MEGACOP x.x
10i: SignallingConfig sent from MGC to MG
SignallingConfig <TransactionId=1205> MEGACOP x.x
RequestId:0123456789AB // to correlate the event with this config
EdgepointId= edgepoint/1@mg-1235.something.net
CallAgentId= ca@ca1.something.net
SignallingDescriptor= hu
SignallingConfig is sent to program the MG to now look for a hang-up
(hu) on edgepoint/1. Note - 10i would be needed if the hu was not in the
package the edgepoint is using, and must be configured explicitly.
10j: SignallingConfigResp from MG to MGC
SignallingConfigResp <TransactionId=1205> MEGACOP x.x
10k: NotifyEvent from MG to MGC
NotifyEvent <TransactionId=1206> MEGACOP x.x
RequestId=123456789AB
EdgepointId= edgepoint/2@mg-1235.something.net
CallAgentId=ca@ca1.something.net
EventDescriptor= hu //observed events
Blatherwick, Cuervo, Greene, Gibbs [Page 21]
Internet draft MEGACO Requirements 26 February 1999
NotifyEvent tells MGC that edgepoint/2 hung up (hu).
10l: NotifyEventResp from MGC to MG
NotifyEventResp <TransactionId=1206> MEGACOP x.x
10m: DeleteMGConnection
DeleteMGConnection <TransactionId=1207> MEGACOP x.x
CallId: A3C47F21456789F0
{EmbeddedEdgepointReset
EdgepointId= edgepoint/1@mg-1235.something.net}
{EmbeddedEdgepointReset
EdgepointId= edgepoint/2@mg-1235.something.net}
The DeleteMGConnection causes the MGC to pull down the MGConnection and
the 2 external connection ids and resets the edgepoints. It also readies
the edgepoints to wait for the next call. The embedded EdgepointReset
with no parameters causes all external connection ids to be deleted for
the call. ExtConnectionIds just deleted are returned in the DeleteMGCon-
nectionResp.
10n: DeleteMGConnectionResp
DeleteMGConnectionResp <TransactionId=1207> MEGACOP x.x
MGConnectionId=xxx
ExtConnection1Id=yyy
ExtConnection2Id=zzz
The MGConnectionId, and the ExtConnectionIds just deleted are returned
in the DeleteMGConnectionResp.
A4.0 Scenarios with ATM as the backbone network
We go through a few scenarios for the example where the ingress MG has
PCM/TDM on one side, and an ATM network on the other side.
Blatherwick, Cuervo, Greene, Gibbs [Page 22]
Internet draft MEGACO Requirements 26 February 1999
ingress MG egress MG
+----+ +----+
E1ExternalConnId | | E2ExternalConnId | |
+ E1Descriptor | | + E2 Descriptor | |
| E1 E2 | | |
v | | v | |
----------------o o - - - - - - - - - - o o------------
| | e.g.ATM network | |
+----+ +----+
^
|
MG-ConnectionId (labels the internal connection between E1 & E2)
e.g.,TDM/PCM network e.g., TDM network
Figure A4.1: MG for TDM to ATM adaptation
List of scenarios:
* 1- dumb gateway: both edgepoints are chosen and their MediaDescrip-
tors are clearly asserted.
* 2- the less dumb gateway: both edgepoints are chosen but their
"connection options" are somewhat open.
* 3- the quasi-intelligent gateway: only one edgepoint is nailed
down, the other is selected by the MG.
A4.1 CASE 1:
In case 1, each edgepoint is indicated by the MGC. In the MediaDescrip-
tors, the MGC-CallAgent indicates the codec choices that are appropriate
for the task. If the gateway is not so dumb, it can figure out from the
codecs chosen for E1 and E2, what resources are needed for the media
transformation. If the gateway is really dumb and it exposes some of its
MediaDevices (or MediaResources), the needed MediaDevice is also indi-
cated from the MGC-DeviceControl: The MediaDevice has two named
edgepoints, E1a and E2a, and the transcoding function is indicated by a
pair of codec ids, which match those of E1 and E2 respectively. This
should be achievable with two CreateConnection commands. The price of
being dumb!: Connect E1 to E1a, and connect E2 to E2a.
Here is a look at the actual commands. It is assumed a SignallingConfig
was sent out from the MGC to E1 in the MG, and that the MG has sent a
NotifyEvent to the MGC.
The MGC then seizes the incoming circuit, decides on the media
Blatherwick, Cuervo, Greene, Gibbs [Page 23]
Internet draft MEGACO Requirements 26 February 1999
conversions, configures the handling of signalling in the edgepoints,
etc., using CreateMGConnection. For this purpose, CreateMGConnection
command embeds a MediaAdaptationConfig and a SignallingConfig for each
edgepoint. For instance, SignallingConfig is used to collect digits or
watch for an on-hook transition.
The following is sent from the MGC to the MG. With this command the MGC
indicates to the MC that it wants an MG connection between E1 and E2,
where E1 is a PCM trunk with echo cancellation and silence suppression.
E2 is given a one profile number. The MGC should wait for the response
before switching the edgepoints from "recv" to "sendrecv".
CreateMGConnection <TransactionId=1204> MEGACOP x.x
CallId: A3C47F21456789F0
E1: edgepoint/1@mg-1234.something.net
ExtConn1Mode: recv
{embeddedMediaAdaptationConfig
MediaDescriptor:
L: p:10, a:G.711 }
E2: outputport:xx, VP/VCI:yy/zz
ExtConn2Mode: recv
{embeddedMediaAdaptationConfig
MediaDescriptor:
v=1
c=ATM <ATMaddress=outputportxx> <ATMtrunkId=VPxx/VCIyy>
m=audio AAL2 <cid=8> 51
a=AAL2map: 51 <I.366.2-voiceprofile1> {encoding1} }
The MG immediately acknowledges the creation, sending back the identifi-
cation of the newly created connection: two external connection Ids, and
an MGConnectionId.
Blatherwick, Cuervo, Greene, Gibbs [Page 24]
Internet draft MEGACO Requirements 26 February 1999
200 1204 OK
MGConnectionId:FDE234C7
E1ExtConnectionId:FDE234C8
E2ExtConnectionId:FDE234C9
{SpecificE1Id: edgepoint/1@mg-1234.something.net
{embeddedMediaAdaptationConfigResp:
MediaDescriptor:
L: p:10, a:G.711 }
{embeddedSignallingConfigResp: } }
{SpecificE2Id: outputport:xx, VP/VCI:yy/zz
{embeddedMediaAdaptationConfigResp:
MediaDescriptor:
v=1
c=ATM <ATMinterface=outputportxx> <ATMtrunkId=VPxx/VCIyy>
m=audio AAL2 <cid=8> 51
a=AAL2map:51 <I.366.2-voiceprofile1> {encoding1} } }
where:
* - ATM trunk identifier is expressed as 16-bit integer encoded as
hexadecimal
* - cid is expressed as 8-bit integer encoded as hexadecimal
* - voice profile is expressed as decimal number in range 0-255 in
accordance with ITU-T I.366.2 Annex P or is dynamically assigned in
range 255-999.
*
NOTE: will need to define a means of defining dynamic voice profiles for
AAL2. This would take similar form to RTP profiles under SDP (RFC2327)
[5]. For example:
* a=AAL2map: <profile#> {encoding1} {encoding2} etc. where {encod-
ing} takes form
* <UUI upper
range>/<PacketLength>/<Descriptor>/<M>/<PacketTime>/<Seq.Interval>
i.e. similar to I.366.2 AnnexP.
The MGC is satisfied that the edgepoints will support the required
codecs and proceeds to modify the edgepoint modes in the connection.
Note, the Mode for both E1ExtConnectionId and E2ExtConnectionId will be
Blatherwick, Cuervo, Greene, Gibbs [Page 25]
Internet draft MEGACO Requirements 26 February 1999
changed to sendrecv when the MGC has received the ANM (if that is what
is required). The ModifyMGConnection is used to change the modes.
ModifyMGConnection <transactionId= 1206> MEGACOP x.x
MGConnectionId:FDE234C7
{Embedded-ModifyExtConnMode
ExtConnectionId: FDE234C8
ExtConnMode: Sendrecv }
{Embedded-ModifyExtConnMode
E2ExtConnectionId: FDE234C9
ExtConnMode: Sendrecv }
The MG immediately acknowledges the modification:
ModifyMGConnectionResp <transactionId= 1206> MEGACOP x.x OK
The Mode for both E1ExtConnectionId and E2ExtConnectionId will be
changed to sendrecv when the MGC has received the ANM (if that is what
is required).
A4.2 CASE 2:
In case 2, the edgepoints are chosen, but the choice of codecs is sorted
out by the MG. So for instance, E1 comes with choices a, and b, and E2
comes with choices a and c. Naturally, the best choice would be (E1,a)
and (E2,a) - no transcoding. But assuming that because reasons only
known to the MG (in most cases it won't have a choice), it chooses
(E1,a) and (E2,c). Then we shall assume that the MG has also internally
chosen the a<->c transcoder. The MGC need not worry about this. This is
why the gateway is "less dumb".
The following command is sent from the MGC to the MG. With this command
the MGC indicates to the MC that it wants an MG connection between E1
and E2, where E1 is a PCM trunk with echo cancellation and silence
suppression. E2 is given a number of profile choices. Until the MGC
makes sure that the remote gateway has a compatible set of choices
(i.e., there is at least one common codec), the edgepoints will remain
in "recv":
Blatherwick, Cuervo, Greene, Gibbs [Page 26]
Internet draft MEGACO Requirements 26 February 1999
CreateMGConnection <TransactionId=1204> MEGACOP x.x
CallId: A3C47F21456789F0
E1: edgepoint/1@mg-1234.something.net
ExtConn1Mode: recv
{embeddedMediaAdaptationConfig
MediaDescriptor:
L: p:10, a:G.711;G.726-32 }
E2: outputport:xx, VP/VCI:yy/zz
ExtConn2Mode: recv
{embeddedMediaAdaptationConfig
MediaDescriptor:
v=1
c=ATM <ATMinterface=outputportxx> <ATMtrunkId=VPxx/VCIyy>
m=audio AAL2 <cid=8> I.366.2 51 52 53
a=AAL2map:51 <I.366.2-voiceprofile1> {encoding1}
a=AAL2map:52 <I.366.2-voiceprofile2> {encoding2}
a=AAL2map:53 <I.366.2-voiceprofile3> {encoding3} }
The MG immediately acknowledges the creation, sending back the identifi-
cation of the newly created connection and the session description used
to receive audio data, and the codecs chosen:
CreateMGConnectionResp <TransactionId=1204> MEGACOP x.x
MGConnectionId:FDE234C7
E1ExtConnectionId:FDE234C8
E2ExtConnectionId:FDE234C9
{SpecificE1Id: edgepoint/1@mg-1234.something.net
{embeddedMediaAdaptationConfigResp:
MediaDescriptor:
L: p:10, a:G.711 }
{embeddedSignallingConfigResp: } }
{SpecificE2Id: outputport:xx, VP/VCI:yy/zz
{embeddedMediaAdaptationConfigResp:
MediaDescriptor:
v=1
c=ATM <ATMinterface=outputportxx> <ATMtrunkId=VPxx/VCIyy>
m=audio AAL2 <cid=8> 51
a=AAL2map:51 <I.366.2-voiceprofile1> {encoding1} } }
The MGC relays has a similar exchange with the egress gateway, when it
ascertains that the codecs for the ATM leg will match, it sends the fol-
lowing ModifyMGConnection. Note, the Mode for both E1ExtConnectionId and
E2ExtConnectionId will be changed to sendrecv when the MGC has received
the ANM (if that is what is required).
Blatherwick, Cuervo, Greene, Gibbs [Page 27]
Internet draft MEGACO Requirements 26 February 1999
ModifyMGConnection <transactionId= 1206> MEGACOP x.x
CallId: A3C47F21456789F0
MGConnectionId:FDE234C7
{Embedded-ModifyExtConnMode
E1ExtConnectionId: FDE234C8
ExtConnMode: sendrecv }
{Embedded-ModifyExtConnMode
E2ExtConnectionId: FDE234C9
ExtConnMode: Sendrecv }
The MG immediately acknowledges the modification:
ModifyMGConnectionResp <transactionId= 1206> MEGACOP x.x
A4.3 CASE 3:
In case 3, we assume that the first edgepoint is fully defined (assume
there are options also): (E1, a or b). Also, to use the superior intel-
ligence of the gateway, some additional description needs to be given to
the gateway so it can turn (*, a or c) or (*,*) into, for instance,
(E2,c). This is where SDP with the MediaDescriptor is set, depending on
the actual capabilities of the network (i.e, whether it routes or sig-
nals ATM or uses preset PVCs). So the fully phrased connection command
would look like this. (E1,a or b) + (*,*) + (E2MediaDescriptor).
CreateMGConnection <TransactionId=1204> MEGACOP x.x
CallId: A3C47F21456789F0
E1: edgepoint/1@mg-1234.something.net
ExtConn1Mode: recvonly
{embeddedMediaAdaptationConfig
MediaDescriptor:
L: p:10, a:G.711;G.726-32 }
E2: *
ExtConn2Mode: recvonly
{embeddedMediaAdaptationConfig
MediaDescriptor:
v=1
c=ATM <ATMaddress=xxxxxxxxxxxxxxxx> <ATMtrunkId=*> }
The gateway immediately acknowledges the creation, sending back the
identification of the newly created connection and the session descrip-
tion used to receive audio data. The gateway selects a port and a
Blatherwick, Cuervo, Greene, Gibbs [Page 28]
Internet draft MEGACO Requirements 26 February 1999
VP/VCI, an AAL2 cid and provides a choice of codecs.
CreateMGConnectionResp <TransactionId=1204> MEGACOP x.x
MGConnectionId:FDE234C7
E1ExtConnectionId:FDE234C8
E2ExtConnectionId:FDE234C9
{SpecificE1Id: edgepoint/1@mg-1234.something.net
{embeddedMediaAdaptationConfigResp:
MediaDescriptor:
L: p:10, a:G.711;G.726-32 }
{embeddedSignallingConfigResp: } }
{SpecificE2Id: outputport:xx, VP/VCI:yy/zz
{embeddedMediaAdaptationConfigResp:
MediaDescriptor:
v=1
c=ATM <ATMaddress=yyyyyyyyyyyyyyyyy> <ATMtrunkId=VPxx/VCIyy>
m=audio AAL2 <cid=8> I.366.2 51 52 53
a=AAL2map:51 <I.366.2-voiceprofile1> {encoding1}
a=AAL2map:52 <I.366.2-voiceprofile2> {encoding2}
a=AAL2map:53 <I.366.2-voiceprofile3> {encoding3} } }
The MG could provide different options for c&m here, and let the egress
MG choose one. It would do this by offering multiple "c"&"m" lines in
preferential order. This MG would find out what the egress MG chose in a
ModifyMGConnection command.
The MGC relays connection information to the egress gateway and receives
information back.
The MGC will relay the information to the ingress gateway, using a
ModifyMGConnection command. destinationATMaddress, ATMTrunkId and cid
will have been defined by the egress MG.
The Mode for the connection will be changed to sendrecv when the MGC has
received the ANM.
A5.0 Mapping of the proposed commands to MGCP commands in [3]
The following table is included here to help understand the relationship
between this proposal and [3]:
Blatherwick, Cuervo, Greene, Gibbs [Page 29]
Internet draft MEGACO Requirements 26 February 1999
2-ended conn model Bellcore/Cisco's
MGCP [2] MGCP [3]
----------------------------------------
ApplySignal = SignalRequest
CallAgentId = NotifiedEntity
SignallingConfig = NotificationRequest
SignallingDescriptor = RequestedEvents (e.g. hu)
SignalDescriptor = SignalRequest
NotifyEvent = Notify
MediaAdaptationConfig = EdgepointConfiguration + CreateConnection
MediaDescriptor = LocalConnectionOptions, RemoteConnectionOptions
ModifyExtConnMode = ModifyConnection
CreateMGConnection = CreateConnection with 2 edgepoints
ModifyMGConnection = ModifyConnection with 2 edgepoints
DeleteMGConnection = DeleteConnection with 2 edgepoints
RequestId = RequestIdentifier
StateChangeNotification = RestartInProgress
(this name change was proposed on the email list)
A6.0 Table comparing this proposal to [1] and [3]
(see Word file for this table: MGCPsCompared.doc - available at
ftp://standards.nortelnetworks.com/megaco) -end-
Blatherwick, Cuervo, Greene, Gibbs [Page 30]
