From 84adefa331c4159d432d22840663c38f155cd4c1 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Fri, 20 Nov 2009 14:54:40 +0000 Subject: The R13B03 release. --- lib/megaco/doc/src/megaco_architecture.xml | 187 +++++++++++++++++++++++++++++ 1 file changed, 187 insertions(+) create mode 100644 lib/megaco/doc/src/megaco_architecture.xml (limited to 'lib/megaco/doc/src/megaco_architecture.xml') 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 @@ + + + + +
+ + 20002009 + Ericsson AB. All Rights Reserved. + + + 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. + + + + Architecture + Håkan Mattsson + Håkan Mattsson + + Håkan Mattsson + + 2007-06-15 + %VSN% + megaco_architecture.xml +
+ +
+ Network view +

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.

+

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.

+ + Network architecture + +

Megaco and peer protocols are complementary in nature and entirely + compatible within the same system. At a system level, Megaco allows + for

+ + +

overall network cost and performance optimization

+ + +

protection of investment by isolation of changes at the call + control layer

+ + +

freedom to geographically distribute both call function and + gateway function

+ + +

adaption of legacy equipment

+ + +
+ +
+ General +

This Erlang/OTP application supplies a framework for building + applications that needs to utilize the Megaco/H.248 protocol.

+

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.

+

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".

+

The protocol engine uses callback modules to handle various + things:

+ + +

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.

+ + +

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.

+ + +

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.

+ + +

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.

+

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.

+

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.

+

The protocol stack does also handle things like automatic + sending of acknowledgements, pending transactions, re-send of + messages, supervision of connections etc.

+

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.

+
+ +
+ Single node config +

Here a system configuration with an MG and MGC residing + in one Erlang node each is outlined:

+ + Single node config + +
+ +
+ Distributed config +

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).

+

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. +

+

+ + Distributes node config + +
+ +
+ Message round-trip call flow +

The typical round-trip of a message can be viewed as + follows. Firstly we view the call flow on the originating + side:

+ + Message Call Flow (originating side) + +

Then we continue with the call flow on the destination + side:

+ + Message Call Flow (destination side) + +
+ + -- cgit v1.2.3