Documentation |
Documentation.Tutorials-Presence-PresenceServer HistoryShow minor edits - Show changes to output July 02, 2014, at 03:28 PM
by
- Changed line 37 from:
You can see a [[Documentation/Tutorials-Presence-SimplePresConfig|configuration file example for this case here]. to:
You can see a [[Documentation/Tutorials-Presence-SimplePresConfig|configuration file example for this case here]]. July 02, 2014, at 03:28 PM
by
- Changed lines 35-42 from:
# 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. You can see a configuration file example for this case [[Documentation/Tutorials-Presence-SimplePresConfig| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. # 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. See [[Documentation/Tutorials-Presence-OpenxcapPresConfig | configuration file example]] here.\\ 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'. # 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'''. to:
!!!! Basic Presence Server 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 [[Documentation/Tutorials-Presence-SimplePresConfig|configuration file example for this case here]. !!!! Presence Server with integrated XCAP 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 [[Documentation/Tutorials-Presence-OpenxcapPresConfig | configuration file example]] here. !!!! Presence Server with external XCAP 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). !!!! Presence server with shared DB 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'''. May 07, 2014, at 12:48 PM
by
- Changed line 37 from:
# 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. See [[openxcap_pres_config | configuration file example]] here.\\ to:
# 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. See [[Documentation/Tutorials-Presence-OpenxcapPresConfig | configuration file example]] here.\\ May 07, 2014, at 12:47 PM
by
- Changed line 35 from:
# 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. You can see a configuration file example for this case [[simple_pres_config| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. to:
# 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. You can see a configuration file example for this case [[Documentation/Tutorials-Presence-SimplePresConfig| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. May 07, 2014, at 12:33 PM
by
- Changed line 27 from:
*[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. to:
*[[Documentation.Tutorials-Presence-XcapClient| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. May 07, 2014, at 12:32 PM
by
- Changed line 24 from:
*[[Documentation.Tutorials-Presence-PresenceAuxModules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: to:
*[[Documentation.Tutorials-Presence-PresenceAuxModules| PRESENCE_XML and PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: May 07, 2014, at 12:26 PM
by
- Changed lines 23-24 from:
*[[presence_module| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 *[[presence_aux_modules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: to:
*[[Documentation.Tutorials-Presence-PresenceModule| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 *[[Documentation.Tutorials-Presence-PresenceAuxModules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: May 07, 2014, at 12:23 PM
by
- Changed lines 3-12 from:
# [[#ps_features| Features]] # [[#ps_architecture| Architecture]] # [[#module_description| Module Description]] # [[#configuration| Configuration]] # [[#database| Database]] [[#ps_features]] !!Features to:
(:toc-float Table of Content:) !!!Features Changed lines 12-16 from:
[[#ps_architecture]] !!Architecture to:
---- !!!Architecture Changed lines 18-21 from:
[[#module_description]] !!Module Description to:
---- !!!Module Description Changed lines 28-31 from:
[[#configuration]] !!Configuration to:
---- !!!Configuration Changed lines 43-46 from:
[[#database]] !!Database to:
---- !!!Database Changed lines 54-57 from:
(:commentboxchrono:) to:
---- May 07, 2014, at 12:18 PM
by
- Changed lines 24-25 from:
[[Presence_Diagram | http://www.opensips.org/images/presence-schema-small.jpg]] to:
[[Documentation.Tutorials-Presence-PresenceDiagram | http://www.opensips.org/images/presence-schema-small.jpg]] Changed line 38 from:
The architecture in the [[Presence_Diagram | 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. to:
The architecture in the [[Documentation.Tutorials-Presence-PresenceDiagram| 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. May 07, 2014, at 12:15 PM
by
- Changed line 1 from:
[[Documentation.Index | Documentation]] -> Tutorials -> [[Documentation.Tutorials-Presence | Presence]] to:
!!!!! Documentation -> [[Documentation.Tutorials | Tutorials ]] -> [[Documentation/Tutorials-Presence|Presence]] -> Presence Server Changed lines 4-27 from:
!!!OpenSIPS Presence Note: Most of these instructions relate to 1.4 version. For an up to date tutorial see OpenSIP and OpenXCAP tutorial. I. [[Documentation.Tutorials-Presence-PresenceServer| Presence Server]] # [[Documentation.Tutorials-Presence-PresenceServer:#ps_architecture| Architecture]] # [[Documentation.Tutorials-Presence-PresenceServer:#module_description| Module Description]] # [[Documentation.Tutorials-Presence-PresenceServer:#configuration| Configuration]] # [[Documentation.Tutorials-Presence-PresenceServer:#database| Database]] II. [[Documentation.Tutorials-PUAExtensions| Presence User Agent Extensions]] # [[Documentation.Tutorials-PUAExtensions:#pua_usrloc| pua_usrloc]] # [[Documentation.Tutorials-PUAExtensions:#pua_mi| pua_mi]] # [[Documentation.Tutorials-PUAExtensions:#pua_xmpp| pua_xmpp]] # [[Documentation.Tutorials-PUAExtensions:#pua_bla| pua_bla]] # [[Documentation.Tutorials-PUAExtensions:#pua_dialoginfo| pua_dialoginfo]] III.[[Documentation.Tutorials-RLS | Resource List Server]] # [[Documentation.Tutorials-RLS:#rls_features| Features]] # [[Documentation.Tutorials-RLS:#description| Description]] # [[Documentation.Tutorials-RLS:#rls_configuration| Configuration]] # [[Documentation.Tutorials-RLS:#rls_database| Database]] IV. [[ http://www.opensips.org/pub/docs/Presence-Anca_Vamanu-Von_SAN_JOSE_2008.pdf | Slides from the presentation held at VON San Jose, 2008]] describing with schemes and examples all presence features in OpenSIPS. to:
# [[#ps_features| Features]] # [[#ps_architecture| Architecture]] # [[#module_description| Module Description]] # [[#configuration| Configuration]] # [[#database| Database]] [[#ps_features]] !!Features * privacy rules with XCAP storage ** a faster integrated xcap mode that uses a database as an interface with the XCAP server ( works with OpenXCAP ) * fast caching with periodic update in database ** a fallback to database mode can be configured useful when more than one server is used for a domain * extensible - new events to be handled by the server can be added easily due to the layered architecture [[#ps_architecture]] !!Architecture '''Presence Diagram''' (click to enlarge) [[Presence_Diagram | http://www.opensips.org/images/presence-schema-small.jpg]] [[#module_description]] !!Module Description *[[presence_module| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 *[[presence_aux_modules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: ** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' (draft-anil-sipping- bla-03.txt) ** presence_mwi: 'message-summary' (RFC 3842) *[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. [[#configuration]] !!Configuration The architecture in the [[Presence_Diagram | 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. You can see a configuration file example for this case [[simple_pres_config| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. # 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. See [[openxcap_pres_config | configuration file example]] here.\\ 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'. # 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'''. [[#database]] !!Database Presence Server requires 4 tables in database: # active_watchers : stores the active Subscribe dialogs # presentity: stores the published information # watchers: stores the subscription status of the watchers # xcap: stores the XCAP documents 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. (:commentboxchrono:) May 09, 2013, at 02:39 PM
by
- Changed line 8 from:
I. [[Documentation/Tutorials-Presence-PresenceServer| Presence Server]] to:
I. [[Documentation.Tutorials-Presence-PresenceServer| Presence Server]] Changed lines 14-25 from:
II. [[Documentation/Tutorials-PUAExtension| Presence User Agent Extensions]] # [[Documentation/Tutorials-PUAExtensions:#pua_usrloc| pua_usrloc]] # [[Documentation/Tutorials-PUAExtensions:#pua_mi| pua_mi]] # [[Documentation/Tutorials-PUAExtensions:#pua_xmpp| pua_xmpp]] # [[Documentation/Tutorials-PUAExtensions:#pua_bla| pua_bla]] # [[Documentation/Tutorials-PUAExtensions:#pua_dialoginfo| pua_dialoginfo]] III.[[Documentation/Tutorials-RL | Resource List Server]] # [[Documentation/Tutorials-RLS:#rls_features| Features]] # [[Documentation/Tutorials-RLS:#description| Description]] # [[Documentation/Tutorials-RLS:#rls_configuration| Configuration]] # [[Documentation/Tutorials-RLS:#rls_database| Database]] to:
II. [[Documentation.Tutorials-PUAExtensions| Presence User Agent Extensions]] # [[Documentation.Tutorials-PUAExtensions:#pua_usrloc| pua_usrloc]] # [[Documentation.Tutorials-PUAExtensions:#pua_mi| pua_mi]] # [[Documentation.Tutorials-PUAExtensions:#pua_xmpp| pua_xmpp]] # [[Documentation.Tutorials-PUAExtensions:#pua_bla| pua_bla]] # [[Documentation.Tutorials-PUAExtensions:#pua_dialoginfo| pua_dialoginfo]] III.[[Documentation.Tutorials-RLS | Resource List Server]] # [[Documentation.Tutorials-RLS:#rls_features| Features]] # [[Documentation.Tutorials-RLS:#description| Description]] # [[Documentation.Tutorials-RLS:#rls_configuration| Configuration]] # [[Documentation.Tutorials-RLS:#rls_database| Database]] May 09, 2013, at 02:38 PM
by
- Changed lines 1-63 from:
!![[Documentation/Documentation | Documentation]] -> [[Documentation/Tutorials-Presence | Presence Tutorial]] -> Presence Server !!Presence Server %block text-align=right% '''written by Anca Vamanu''' # [[#ps_features| Features]] # [[#ps_architecture| Architecture]] # [[#module_description| Module Description]] # [[#configuration| Configuration]] # [[#database| Database]] [[#ps_features]] !!Features * privacy rules with XCAP storage ** a faster integrated xcap mode that uses a database as an interface with the XCAP server ( works with OpenXCAP ) * fast caching with periodic update in database ** a fallback to database mode can be configured useful when more than one server is used for a domain * extensible - new events to be handled by the server can be added easily due to the layered architecture [[#ps_architecture]] !!Architecture '''Presence Diagram''' (click to enlarge) [[ Documentation/Tutorials-Presence-PresenceDiagram | http://www.opensips.org/images/presence-schema-small.jpg]] [[#module_description]] !!Module Description *[[Documentation.Tutorials-Presence-PresenceModule| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 *[[Documentation/Tutorials-Presence-PresenceAuxModules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: ** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' (draft-anil-sipping- bla-03.txt) ** presence_mwi: 'message-summary' (RFC 3842) *[[Documentation/Tutorials-Presence-XcapClient| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. [[#configuration]] !!Configuration The architecture in the [[Documentation/Tutorials-Presence-PresenceDiagram | 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. You can see a configuration file example for this case [[Documentation/Tutorials-Presence-SimplePresConfig| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. # 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. See [[Documentation/Tutorials-Presence-OpenxcapPresConfig | configuration file example]] here.\\ 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'. # 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'''. [[#database]] !!Database Presence Server requires 4 tables in database: # active_watchers : stores the active Subscribe dialogs # presentity: stores the published information # watchers: stores the subscription status of the watchers # xcap: stores the XCAP documents 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. (:commentboxchrono:) to:
[[Documentation.Index | Documentation]] -> Tutorials -> [[Documentation.Tutorials-Presence | Presence]] ---- !!!OpenSIPS Presence Note: Most of these instructions relate to 1.4 version. For an up to date tutorial see OpenSIP and OpenXCAP tutorial. I. [[Documentation/Tutorials-Presence-PresenceServer| Presence Server]] # [[Documentation.Tutorials-Presence-PresenceServer:#ps_architecture| Architecture]] # [[Documentation.Tutorials-Presence-PresenceServer:#module_description| Module Description]] # [[Documentation.Tutorials-Presence-PresenceServer:#configuration| Configuration]] # [[Documentation.Tutorials-Presence-PresenceServer:#database| Database]] II. [[Documentation/Tutorials-PUAExtension| Presence User Agent Extensions]] # [[Documentation/Tutorials-PUAExtensions:#pua_usrloc| pua_usrloc]] # [[Documentation/Tutorials-PUAExtensions:#pua_mi| pua_mi]] # [[Documentation/Tutorials-PUAExtensions:#pua_xmpp| pua_xmpp]] # [[Documentation/Tutorials-PUAExtensions:#pua_bla| pua_bla]] # [[Documentation/Tutorials-PUAExtensions:#pua_dialoginfo| pua_dialoginfo]] III.[[Documentation/Tutorials-RL | Resource List Server]] # [[Documentation/Tutorials-RLS:#rls_features| Features]] # [[Documentation/Tutorials-RLS:#description| Description]] # [[Documentation/Tutorials-RLS:#rls_configuration| Configuration]] # [[Documentation/Tutorials-RLS:#rls_database| Database]] IV. [[ http://www.opensips.org/pub/docs/Presence-Anca_Vamanu-Von_SAN_JOSE_2008.pdf | Slides from the presentation held at VON San Jose, 2008]] describing with schemes and examples all presence features in OpenSIPS. May 09, 2013, at 12:39 PM
by
- Changed line 24 from:
[[Presence_Diagram | http://www.opensips.org/images/presence-schema-small.jpg]] to:
[[ Documentation/Tutorials-Presence-PresenceDiagram | http://www.opensips.org/images/presence-schema-small.jpg]] May 09, 2013, at 12:38 PM
by
- Changed line 1 from:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsPapPa | Presence]] -> Presence Server to:
!![[Documentation/Documentation | Documentation]] -> [[Documentation/Tutorials-Presence | Presence Tutorial]] -> Presence Server April 26, 2013, at 12:29 PM
by
- Changed line 41 from:
# 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. You can see a configuration file example for this case [[simple_pres_config| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. to:
# 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. You can see a configuration file example for this case [[Documentation/Tutorials-Presence-SimplePresConfig| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. April 26, 2013, at 12:28 PM
by
- Changed line 43 from:
# 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. See [[openxcap_pres_config | configuration file example]] here.\\ to:
# 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. See [[Documentation/Tutorials-Presence-OpenxcapPresConfig | configuration file example]] here.\\ April 26, 2013, at 12:24 PM
by
- Changed line 38 from:
The architecture in the [[Presence_Diagram | 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. to:
The architecture in the [[Documentation/Tutorials-Presence-PresenceDiagram | 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. April 24, 2013, at 08:17 PM
by
- Changed line 33 from:
*[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. to:
*[[Documentation/Tutorials-Presence-XcapClient| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. April 24, 2013, at 08:15 PM
by
- Changed line 30 from:
*[[presence_aux_modules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: to:
*[[Documentation/Tutorials-Presence-PresenceAuxModules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: April 24, 2013, at 08:13 PM
by
- Changed line 29 from:
*[[presence_module| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 to:
*[[Documentation.Tutorials-Presence-PresenceModule| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 April 24, 2013, at 07:41 PM
by
- Added lines 1-63:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsPapPa | Presence]] -> Presence Server !!Presence Server %block text-align=right% '''written by Anca Vamanu''' # [[#ps_features| Features]] # [[#ps_architecture| Architecture]] # [[#module_description| Module Description]] # [[#configuration| Configuration]] # [[#database| Database]] [[#ps_features]] !!Features * privacy rules with XCAP storage ** a faster integrated xcap mode that uses a database as an interface with the XCAP server ( works with OpenXCAP ) * fast caching with periodic update in database ** a fallback to database mode can be configured useful when more than one server is used for a domain * extensible - new events to be handled by the server can be added easily due to the layered architecture [[#ps_architecture]] !!Architecture '''Presence Diagram''' (click to enlarge) [[Presence_Diagram | http://www.opensips.org/images/presence-schema-small.jpg]] [[#module_description]] !!Module Description *[[presence_module| PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903 *[[presence_aux_modules| PRESENCE_XML and **PRESENCE_MWI modules]] - clients for PRESENCE module; register specific events to be handled by PRESENCE module: ** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' (draft-anil-sipping- bla-03.txt) ** presence_mwi: 'message-summary' (RFC 3842) *[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules. [[#configuration]] !!Configuration The architecture in the [[Presence_Diagram | 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. You can see a configuration file example for this case [[simple_pres_config| here]]. This mode of operation is configured by setting the flag '''force_active''' which is a module parameter for '''presence_xml''' module. # 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. See [[openxcap_pres_config | configuration file example]] here.\\ 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'. # 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'''. [[#database]] !!Database Presence Server requires 4 tables in database: # active_watchers : stores the active Subscribe dialogs # presentity: stores the published information # watchers: stores the subscription status of the watchers # xcap: stores the XCAP documents 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. (:commentboxchrono:) |