DesignXMPP arch » History » Revision 7
Revision 6 (Anonymous, 02/29/2012 12:27 PM) → Revision 7/30 (Anonymous, 02/29/2012 12:30 PM)
= XMPP gateway architecture = The architecture of the SIP-XMPP gateway can be modeled in two different ways: * Based on an XMPP component * Based on an XMPP server (using server-to-server communication) 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. == XMPP component based architecture == [[Image(xmppgw-arch-component.png)]] === Elements required === * XMPP server (ejabberd for example) * XMPP server plugin (divert stanzas to offline users to a given component) * SIP Application server which is also a XMPP component * SIP proxy (registration, AAA and routing) == XMPP server based architecture == [[Image(xmppgw-arch-server.png)]] === Elements required === * SIP Application server which is also a XMPP server * SIP proxy (registration, AAA and routing) == Chosen architecture == 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. The chosen model has a number of advantages / disadvantages: * Advantages * Less network elements involved * Full control over XMPP routing since the server is customized * No need for developing plugins for any XMPP server * Disadvantages: * Inability to use an XMPP client in the local domain 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. The aforementioned disadvantage might also disappear in the future if the chosen library implements accepting XMPP client connections.