aboutsummaryrefslogtreecommitdiffstats
path: root/lib/megaco/doc/src/megaco_architecture.xml
diff options
context:
space:
mode:
authorErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
committerErlang/OTP <[email protected]>2009-11-20 14:54:40 +0000
commit84adefa331c4159d432d22840663c38f155cd4c1 (patch)
treebff9a9c66adda4df2106dfd0e5c053ab182a12bd /lib/megaco/doc/src/megaco_architecture.xml
downloadotp-84adefa331c4159d432d22840663c38f155cd4c1.tar.gz
otp-84adefa331c4159d432d22840663c38f155cd4c1.tar.bz2
otp-84adefa331c4159d432d22840663c38f155cd4c1.zip
The R13B03 release.OTP_R13B03
Diffstat (limited to 'lib/megaco/doc/src/megaco_architecture.xml')
-rw-r--r--lib/megaco/doc/src/megaco_architecture.xml187
1 files changed, 187 insertions, 0 deletions
diff --git a/lib/megaco/doc/src/megaco_architecture.xml b/lib/megaco/doc/src/megaco_architecture.xml
new file mode 100644
index 0000000000..aeea17c5cf
--- /dev/null
+++ b/lib/megaco/doc/src/megaco_architecture.xml
@@ -0,0 +1,187 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+ <header>
+ <copyright>
+ <year>2000</year><year>2009</year>
+ <holder>Ericsson AB. All Rights Reserved.</holder>
+ </copyright>
+ <legalnotice>
+ The contents of this file are subject to the Erlang Public License,
+ Version 1.1, (the "License"); you may not use this file except in
+ compliance with the License. You should have received a copy of the
+ Erlang Public License along with this software. If not, it can be
+ retrieved online at http://www.erlang.org/.
+
+ Software distributed under the License is distributed on an "AS IS"
+ basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+ the License for the specific language governing rights and limitations
+ under the License.
+
+ </legalnotice>
+
+ <title>Architecture</title>
+ <prepared>H&aring;kan Mattsson</prepared>
+ <responsible>H&aring;kan Mattsson</responsible>
+ <docno></docno>
+ <approved>H&aring;kan Mattsson</approved>
+ <checked></checked>
+ <date>2007-06-15</date>
+ <rev>%VSN%</rev>
+ <file>megaco_architecture.xml</file>
+ </header>
+
+ <section>
+ <title>Network view</title>
+ <p>Megaco is a (master/slave) protocol for control of gateway functions at
+ the edge of the packet network. Examples of this is IP-PSTN trunking
+ gateways and analog line gateways. The main function of Megaco is to
+ allow gateway decomposition into a call agent (call control) part (known
+ as Media Gateway Controller, MGC) - master, and an gateway interface
+ part (known as Media Gateway, MG) - slave. The MG has no call control
+ knowledge and only handle making the connections and simple
+ configurations.</p>
+ <p>SIP and H.323 are peer-to-peer protocols for call control (valid only
+ for some of the protocols within H.323), or more generally multi-media
+ session protocols. They both operate at a different level (call control)
+ from Megaco in a decomposed network, and are therefor not aware of
+ whether or not Megaco is being used underneath.</p>
+ <image file="megaco_sys_arch.gif">
+ <icaption>Network architecture</icaption>
+ </image>
+ <p>Megaco and peer protocols are complementary in nature and entirely
+ compatible within the same system. At a system level, Megaco allows
+ for</p>
+ <list type="bulleted">
+ <item>
+ <p>overall network cost and performance optimization</p>
+ </item>
+ <item>
+ <p>protection of investment by isolation of changes at the call
+ control layer</p>
+ </item>
+ <item>
+ <p>freedom to geographically distribute both call function and
+ gateway function</p>
+ </item>
+ <item>
+ <p>adaption of legacy equipment</p>
+ </item>
+ </list>
+ </section>
+
+ <section>
+ <title>General</title>
+ <p>This Erlang/OTP application supplies a framework for building
+ applications that needs to utilize the Megaco/H.248 protocol.</p>
+ <p>We have introduced the term "user" as a generic term for either
+ an MG or an MGC, since most of the functionality we support, is
+ common for both MG's and MGC's. A (local) user may be configured
+ in various ways and it may establish any number of connections
+ to its counterpart, the remote user. Once a connection has been
+ established, the connection is supervised and it may be used for
+ the purpose of sending messages. N.B. according to the standard
+ an MG is connected to at most one MGC, while an MGC may be
+ connected to any number of MG's.</p>
+ <p>For the purpose of managing "virtual MG's", one Erlang node may
+ host any number of MG's. In fact it may host a mix of MG's and
+ MGC's. You may say that an Erlang node may host any number of
+ "users".</p>
+ <p>The protocol engine uses callback modules to handle various
+ things:</p>
+ <list type="bulleted">
+ <item>
+ <p>encoding callback modules - handles the encoding and
+ decoding of messages. Several modules for handling different
+ encodings are included, such as ASN.1 BER, pretty well
+ indented text, compact text and some others. Others may be
+ written by you.</p>
+ </item>
+ <item>
+ <p>transport callback modules - handles sending and receiving
+ of messages. Transport modules for TCP/IP and UDP/IP are
+ included and others may be written by you.</p>
+ </item>
+ <item>
+ <p>user callback modules - the actual implementation of an MG
+ or MGC. Most of the functions are intended for handling of a
+ decoded transaction (request, reply, acknowledgement), but
+ there are others that handles connect, disconnect and
+ errors cases.</p>
+ </item>
+ </list>
+ <p>Each connection may have its own configuration of callback
+ modules, re-send timers, transaction id ranges etc. and they may
+ be re-configured on-the-fly.</p>
+ <p>In the API of Megaco, a user may explicitly send action
+ requests, but generation of transaction identifiers, the
+ encoding and actual transport of the message to the remote user
+ is handled automatically by the protocol engine according to the
+ actual connection configuration. Megaco messages are not exposed
+ in the API.</p>
+ <p>On the receiving side the transport module receives the message
+ and forwards it to the protocol engine, which decodes it and
+ invokes user callback functions for each transaction. When a
+ user has handled its action requests, it simply returns a list
+ of action replies (or a message error) and the protocol engine
+ uses the encoding module and transport module to compose and
+ forward the message to the originating user.</p>
+ <p>The protocol stack does also handle things like automatic
+ sending of acknowledgements, pending transactions, re-send of
+ messages, supervision of connections etc.</p>
+ <p>In order to provide a solution for scalable implementations of
+ MG's and MGC's, a user may be distributed over several Erlang
+ nodes. One of the Erlang nodes is connected to the physical
+ network interface, but messages may be sent from other nodes and
+ the replies are automatically forwarded back to the originating
+ node.</p>
+ </section>
+
+ <section>
+ <title>Single node config</title>
+ <p>Here a system configuration with an MG and MGC residing
+ in one Erlang node each is outlined:</p>
+ <image file="single_node_config.gif">
+ <icaption>Single node config</icaption>
+ </image>
+ </section>
+
+ <section>
+ <title>Distributed config</title>
+ <p>In a larger system with a user (in this case an MGC)
+ distributed over several Erlang nodes, it looks a little bit
+ different. Here the encoding is performed on the originating
+ Erlang node (1) and the binary is forwarded to the node (2) with
+ the physical network interface. When the potential message reply
+ is received on the interface on node (2), it is decoded there
+ and then different actions will be taken for each transaction in
+ the message. The transaction reply will be forwarded in its
+ decoded form to the originating node (1) while the other types
+ of transactions will be handled locally on node (2).</p>
+ <p>Timers and re-send of messages will be handled on locally on
+ one node, that is node(1), in order to avoid unnecessary
+ transfer of data between the Erlang nodes.
+ </p>
+ <p></p>
+ <image file="distr_node_config.gif">
+ <icaption>Distributes node config</icaption>
+ </image>
+ </section>
+
+ <section>
+ <title>Message round-trip call flow</title>
+ <p>The typical round-trip of a message can be viewed as
+ follows. Firstly we view the call flow on the originating
+ side:</p>
+ <image file="call_flow.gif">
+ <icaption>Message Call Flow (originating side)</icaption>
+ </image>
+ <p>Then we continue with the call flow on the destination
+ side:</p>
+ <image file="call_flow_cont.gif">
+ <icaption>Message Call Flow (destination side)</icaption>
+ </image>
+ </section>
+</chapter>
+