Table of Content (hide)
Presence Diagram (click to enlarge)
The architecture in the diagram corresponds to a full configuration, when no restrictions are imposed, with privacy permission rules handling enabled and the use of a general XCAP server. There is the possibility to simplify the scheme according to the needs and resources. This can be done by configuring the modules so that some connections are removed or others appear.
The most simple configuration is a presence server without privacy rules, when anybody is allowed to see the presence status of anybody and there is no need for an xcap server. In this case the xcap part disappears from the scheme.. This mode of operation is configured by setting the flag force_active which is a module parameter for presence_xml module.
You can see a configuration file example for this case here.
If you want presence privacy rules enabled and you use a XCAP server, but one that communicates with the OpenSIPS Presence Server through a database table ( like OpenXCAP) than you can configure the presence server to work in an integrated xcap sever mode. For this you have to set the integrated_xcap_server parameter from presence_xml module. In this case the scheme simplifies by removing the xcap_client module and having the presence_xml module communicates only with the database.
You will notice in the configuration file that the mi_xmlrpc module is also loaded. The MI interface needs to be activated, so that OpenXCAP can signal to OpenSIPS when a change occurs in the presence rules documents. In this way the changes be effective immediately.The MI command that is sent in this case is 'refreshWatchers'.
See configuration file example here.
If you decide to have a presence server with privacy authorization and not use an integrated xcap server, an improvement can be made in this case also. For a non integrated XCAp server, xcap_client module has to be used and the address of the server( or servers) must be set using the presence_xml modules parameter - xcap_server. The xcap_client module has the task to retrieve XCAP documents from XCAP servers and store them in database. Also the module can be asked to synchronize documents saved in database with those on the server. For this a mean of detecting an update is required. The general mean, that apply to every XCAP server is periodical query. There is however the possibility for the server to signal an update to the module. For this the module has to be able to send refreshXcapDoc MI command when an update occurs. If you are using a XCAP server able to send this command then you can configure the server to work in no periodical query mode. For this you have to unset the xcap_client module parameter periodical_query ( set it to 0).
Another configuration option refers to the way the presence module stores information. The default method is caching with periodical update in database for fast processing. However, if you have more presence servers serving the same domain and sharing the same database, this mode will not work. In this case you need to ensure that the servers will be able to communicate through the database. This can be achieved by setting the presence module parameter fallback2db.
Presence Server requires 4 tables in database:
The first three tables are only used internally by the server. The xcap table is either used as a communication interface between the XCAP server (if the server is working in 'integrated_xcap' mode) or as a communication means between the xcap_client module which populates the table and presence_xml module which uses that information.