DesignXMPP arch
Version 1 (Tijmen de Mes, 05/07/2012 11:00 am)
| 1 | 1 | Tijmen de Mes | h1. Gateway Architecture |
|---|---|---|---|
| 2 | 1 | Tijmen de Mes | |
| 3 | 1 | Tijmen de Mes | |
| 4 | 1 | Tijmen de Mes | |
| 5 | 1 | Tijmen de Mes | |
| 6 | 1 | Tijmen de Mes | Due to the dedicated server architecture of XMPP and requirements for availabiliy of public DNS entries for the target domain, is not possible to position the gateway between two clients. The architecture of the SIP-XMPP gateway can be modeled in two different ways, both dependent on the way XMPP server is deployed: |
| 7 | 1 | Tijmen de Mes | |
| 8 | 1 | Tijmen de Mes | * Based on an XMPP server (using server-to-server communication) |
| 9 | 1 | Tijmen de Mes | * Based on an XMPP component connected to an existing XMPP server |
| 10 | 1 | Tijmen de Mes | |
| 11 | 1 | Tijmen de Mes | These approaches are not mutually exclusive, they could potentially be implemented and decide which one to use by setting a configuration option. |
| 12 | 1 | Tijmen de Mes | |
| 13 | 1 | Tijmen de Mes | |
| 14 | 1 | Tijmen de Mes | |
| 15 | 1 | Tijmen de Mes | |
| 16 | 1 | Tijmen de Mes | h2. XMPP Server Based Architecture |
| 17 | 1 | Tijmen de Mes | |
| 18 | 1 | Tijmen de Mes | |
| 19 | 1 | Tijmen de Mes | !xmppgw-arch-server.png! |
| 20 | 1 | Tijmen de Mes | |
| 21 | 1 | Tijmen de Mes | * SIP Application server which is also a XMPP server |
| 22 | 1 | Tijmen de Mes | * SIP proxy (registration, AAA and routing) |
| 23 | 1 | Tijmen de Mes | |
| 24 | 1 | Tijmen de Mes | |
| 25 | 1 | Tijmen de Mes | h2. XMPP Component Based Architecture |
| 26 | 1 | Tijmen de Mes | |
| 27 | 1 | Tijmen de Mes | |
| 28 | 1 | Tijmen de Mes | !xmppgw-arch-component.png! |
| 29 | 1 | Tijmen de Mes | |
| 30 | 1 | Tijmen de Mes | * XMPP server (ejabberd for example) |
| 31 | 1 | Tijmen de Mes | * XMPP server plugin (divert stanzas to offline users to a given component) |
| 32 | 1 | Tijmen de Mes | * SIP Application server which is also a XMPP component |
| 33 | 1 | Tijmen de Mes | * SIP proxy (registration, AAA and routing) |
| 34 | 1 | Tijmen de Mes | |
| 35 | 1 | Tijmen de Mes | |
| 36 | 1 | Tijmen de Mes | h2. Chosen Architecture |
| 37 | 1 | Tijmen de Mes | |
| 38 | 1 | Tijmen de Mes | |
| 39 | 1 | Tijmen de Mes | 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. |
| 40 | 1 | Tijmen de Mes | |
| 41 | 1 | Tijmen de Mes | The server based architecture model has a number of advantages / disadvantages: |
| 42 | 1 | Tijmen de Mes | |
| 43 | 1 | Tijmen de Mes | * Advantages |
| 44 | 1 | Tijmen de Mes | ** Less network elements involved |
| 45 | 1 | Tijmen de Mes | ** Full control over XMPP routing since the server is customized |
| 46 | 1 | Tijmen de Mes | ** No need for developing plugins for any XMPP server |
| 47 | 1 | Tijmen de Mes | * Disadvantages: |
| 48 | 1 | Tijmen de Mes | ** Inability to use an XMPP client in the local domain |
| 49 | 1 | Tijmen de Mes | |
| 50 | 1 | Tijmen de Mes | 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. |
| 51 | 1 | Tijmen de Mes | |
| 52 | 1 | Tijmen de Mes | The aforementioned disadvantage would also disappear if the chosen library implemented accepting XMPP client connections, which is likely to happen in the future. |