diff options
Diffstat (limited to 'lib/megaco/doc/src/megaco_architecture.xml')
| -rw-r--r-- | lib/megaco/doc/src/megaco_architecture.xml | 187 |
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åkan Mattsson</prepared> + <responsible>Håkan Mattsson</responsible> + <docno></docno> + <approved>Hå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> + |