DesignXMPP arch
Version 5 (Anonymous, 02/29/2012 12:17 pm) → Version 6/30 (Anonymous, 02/29/2012 12:27 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 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.