DesignXMPP arch » History » Version 13
Anonymous, 03/01/2012 02:15 PM
| 1 | 1 | = XMPP gateway architecture = |
|
|---|---|---|---|
| 2 | |||
| 3 | 13 | [[TOC(DesignXMPP, DesignXMPP_arch, depth=2)]] |
|
| 4 | 9 | ||
| 5 | 4 | The architecture of the SIP-XMPP gateway can be modeled in two different ways: |
|
| 6 | 1 | ||
| 7 | 4 | * Based on an XMPP component |
|
| 8 | * Based on an XMPP server (using server-to-server communication) |
||
| 9 | 1 | ||
| 10 | 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. |
|
| 11 | |||
| 12 | == XMPP component based architecture == |
||
| 13 | |||
| 14 | 10 | [[Image(xmppgw-arch-component.png, 700px, center)]] |
|
| 15 | 2 | ||
| 16 | 5 | === Elements required === |
|
| 17 | 3 | ||
| 18 | 5 | * XMPP server (ejabberd for example) |
|
| 19 | 1 | * XMPP server plugin (divert stanzas to offline users to a given component) |
|
| 20 | * SIP Application server which is also a XMPP component |
||
| 21 | * SIP proxy (registration, AAA and routing) |
||
| 22 | 4 | ||
| 23 | == XMPP server based architecture == |
||
| 24 | 1 | ||
| 25 | 10 | [[Image(xmppgw-arch-server.png, 700px, center)]] |
|
| 26 | 4 | ||
| 27 | 5 | === Elements required === |
|
| 28 | 4 | ||
| 29 | 5 | * SIP Application server which is also a XMPP server |
|
| 30 | * SIP proxy (registration, AAA and routing) |
||
| 31 | 6 | ||
| 32 | == Chosen architecture == |
||
| 33 | |||
| 34 | 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. |
||
| 35 | |||
| 36 | The chosen model has a number of advantages / disadvantages: |
||
| 37 | |||
| 38 | * Advantages |
||
| 39 | * Less network elements involved |
||
| 40 | * Full control over XMPP routing since the server is customized |
||
| 41 | * No need for developing plugins for any XMPP server |
||
| 42 | * Disadvantages: |
||
| 43 | * Inability to use an XMPP client in the local domain |
||
| 44 | |||
| 45 | 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. |
||
| 46 | 7 | ||
| 47 | 8 | The aforementioned disadvantage would also disappear if the chosen library implemented accepting XMPP client connections, which is likely to happen in the future. |