DesignXMPP arch
Version 22 (Adrian Georgescu, 03/07/2012 09:34 am)
| 1 | 17 | Adrian Georgescu | = Gateway Architecture = |
|---|---|---|---|
| 2 | 1 | ||
| 3 | 19 | Adrian Georgescu | [[TOC(DesignXMPP, DesignXMPP_analysis, DesignXMPP_arch, DesignXMPP_im, , DesignXMPP_conference, DesignXMPP_presence, DesignXMPP_jingle, depth=2)]] |
| 4 | 9 | ||
| 5 | 20 | Adrian Georgescu | The architecture of the SIP-XMPP gateway can be modeled in two ways: |
| 6 | 1 | ||
| 7 | 1 | * Based on an XMPP server (using server-to-server communication) |
|
| 8 | 21 | Adrian Georgescu | * Based on an XMPP component connected to an existing XMPP server |
| 9 | 1 | ||
| 10 | 21 | Adrian Georgescu | These approaches are not mutually exclusive, they could potentially be implemented and decide which one to use by setting a configuration option. |
| 11 | 1 | ||
| 12 | 21 | Adrian Georgescu | > Due to the dedicated server architecture of XMPP and requirement for public DNS entries for the target domain, is not possible to position the gateway between two clients. |
| 13 | 1 | ||
| 14 | 22 | Adrian Georgescu | |
| 15 | 1 | == XMPP Server Based Architecture == |
|
| 16 | 1 | ||
| 17 | 1 | [[Image(xmppgw-arch-server.png, 700px, center)]] |
|
| 18 | 1 | ||
| 19 | 1 | * SIP Application server which is also a XMPP server |
|
| 20 | 1 | * SIP proxy (registration, AAA and routing) |
|
| 21 | 1 | ||
| 22 | 21 | Adrian Georgescu | == XMPP Component Based Architecture == |
| 23 | 15 | Adrian Georgescu | |
| 24 | 21 | Adrian Georgescu | [[Image(xmppgw-arch-component.png, 700px, center)]] |
| 25 | 21 | Adrian Georgescu | |
| 26 | 21 | Adrian Georgescu | * XMPP server (ejabberd for example) |
| 27 | 21 | Adrian Georgescu | * XMPP server plugin (divert stanzas to offline users to a given component) |
| 28 | 21 | Adrian Georgescu | * SIP Application server which is also a XMPP component |
| 29 | 21 | Adrian Georgescu | * SIP proxy (registration, AAA and routing) |
| 30 | 21 | Adrian Georgescu | |
| 31 | 15 | Adrian Georgescu | == Chosen Architecture == |
| 32 | 6 | ||
| 33 | 16 | Adrian Georgescu | After experimenting with both models the chosen model to be implemented first is the '''XMPP server based architecture'''. The component based approach could be added at a later time. |
| 34 | 6 | ||
| 35 | 16 | Adrian Georgescu | The server based architecture model has a number of advantages / disadvantages: |
| 36 | 6 | ||
| 37 | 6 | * Advantages |
|
| 38 | 6 | * Less network elements involved |
|
| 39 | 6 | * Full control over XMPP routing since the server is customized |
|
| 40 | 6 | * No need for developing plugins for any XMPP server |
|
| 41 | 6 | * Disadvantages: |
|
| 42 | 6 | * Inability to use an XMPP client in the local domain |
|
| 43 | 7 | ||
| 44 | 1 | 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. |
|
| 45 | 20 | Adrian Georgescu | |
| 46 | 20 | Adrian Georgescu | The aforementioned disadvantage would also disappear if the chosen library implemented accepting XMPP client connections, which is likely to happen in the future. |