aboutsummaryrefslogtreecommitdiffstats
path: root/lib/megaco/doc/src/megaco_architecture.xml
blob: 082268a07694b011e4d3dbe287910cd99eb18678 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2000</year><year>2016</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at
 
          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions 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>