DesignXMPP arch
Version 20 (Adrian Georgescu, 03/07/2012 09:30 am) → Version 21/30 (Adrian Georgescu, 03/07/2012 09:34 am)
= Gateway Architecture =
[[TOC(DesignXMPP, DesignXMPP_analysis, DesignXMPP_arch, DesignXMPP_im, , DesignXMPP_conference, DesignXMPP_presence, DesignXMPP_jingle, depth=2)]]
The architecture of the SIP-XMPP gateway can be modeled in two ways:
* Based on an XMPP server (using server-to-server communication) component
* Based on an XMPP component connected to an existing XMPP server (using server-to-server communication)
These approaches are not mutually exclusive, they could potentially can both be implemented at the same time and decide which one to use by setting with a configuration option.
> Due option 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. allow different deployment scenarios.
== XMPP Server Component Based Architecture ==
[[Image(xmppgw-arch-server.png, [[Image(xmppgw-arch-component.png, 700px, center)]]
* 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 server component
* SIP proxy (registration, AAA and routing)
== XMPP Component Server Based Architecture ==
[[Image(xmppgw-arch-component.png, [[Image(xmppgw-arch-server.png, 700px, center)]]
* 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 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 could be added at a later time.
The server based architecture 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 would also disappear if the chosen library implemented accepting XMPP client connections, which is likely to happen in the future.
> Due to the dedicated server architecture of XMPP, is not possible to have the gateway between two clients.
[[TOC(DesignXMPP, DesignXMPP_analysis, DesignXMPP_arch, DesignXMPP_im, , DesignXMPP_conference, DesignXMPP_presence, DesignXMPP_jingle, depth=2)]]
The architecture of the SIP-XMPP gateway can be modeled in two ways:
* Based on an XMPP server (using server-to-server communication) component
* Based on an XMPP component connected to an existing XMPP server (using server-to-server communication)
These approaches are not mutually exclusive, they could potentially can both be implemented at the same time and decide which one to use by setting with a configuration option.
> Due option 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. allow different deployment scenarios.
== XMPP Server Component Based Architecture ==
[[Image(xmppgw-arch-server.png, [[Image(xmppgw-arch-component.png, 700px, center)]]
* 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 server component
* SIP proxy (registration, AAA and routing)
== XMPP Component Server Based Architecture ==
[[Image(xmppgw-arch-component.png, [[Image(xmppgw-arch-server.png, 700px, center)]]
* 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 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 could be added at a later time.
The server based architecture 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 would also disappear if the chosen library implemented accepting XMPP client connections, which is likely to happen in the future.
> Due to the dedicated server architecture of XMPP, is not possible to have the gateway between two clients.