DesignXMPP arch
Version 7 (Anonymous, 02/29/2012 12:30 pm)
1 | 1 | = XMPP gateway architecture = |
|
---|---|---|---|
2 | 1 | ||
3 | 4 | The architecture of the SIP-XMPP gateway can be modeled in two different ways: |
|
4 | 1 | ||
5 | 4 | * Based on an XMPP component |
|
6 | 4 | * Based on an XMPP server (using server-to-server communication) |
|
7 | 1 | ||
8 | 4 | Both approaches are not mutually exclusive, they can both be implemented at the same time and decide which one to use with a configuration option to allow different deployment scenarios. |
|
9 | 4 | ||
10 | 4 | == XMPP component based architecture == |
|
11 | 4 | ||
12 | 5 | [[Image(xmppgw-arch-component.png)]] |
|
13 | 2 | ||
14 | 5 | === Elements required === |
|
15 | 3 | ||
16 | 5 | * XMPP server (ejabberd for example) |
|
17 | 1 | * XMPP server plugin (divert stanzas to offline users to a given component) |
|
18 | 1 | * SIP Application server which is also a XMPP component |
|
19 | 1 | * SIP proxy (registration, AAA and routing) |
|
20 | 4 | ||
21 | 4 | == XMPP server based architecture == |
|
22 | 1 | ||
23 | 5 | [[Image(xmppgw-arch-server.png)]] |
|
24 | 4 | ||
25 | 5 | === Elements required === |
|
26 | 4 | ||
27 | 5 | * SIP Application server which is also a XMPP server |
|
28 | 5 | * SIP proxy (registration, AAA and routing) |
|
29 | 6 | ||
30 | 6 | == Chosen architecture == |
|
31 | 6 | ||
32 | 6 | After experimenting with both models the chosen model to be implemented first is the '''XMPP server based architecture'''. The component based approach shall be added at a later time. |
|
33 | 6 | ||
34 | 6 | The chosen model has a number of advantages / disadvantages: |
|
35 | 6 | ||
36 | 6 | * Advantages |
|
37 | 6 | * Less network elements involved |
|
38 | 6 | * Full control over XMPP routing since the server is customized |
|
39 | 6 | * No need for developing plugins for any XMPP server |
|
40 | 6 | * Disadvantages: |
|
41 | 6 | * Inability to use an XMPP client in the local domain |
|
42 | 6 | ||
43 | 6 | The critical factor when making this choice is the fact that if a custom XMPP server is built all the routing logic can be customized without the need of running an extra XMPP server and writing a plugin for it. Thus, this approach is more sustainable over time. |
|
44 | 7 | ||
45 | 7 | The aforementioned disadvantage might also disappear in the future if the chosen library implements accepting XMPP client connections. |