Resources.PresenceServer History

Hide minor edits - Show changes to output

April 24, 2013, at 07:42 PM by 109.99.235.212 -
Changed lines 1-63 from:
!!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:)
to:
(:redirect Documentation.Tutorials-Presence-PresenceServer quiet=1:)
February 28, 2013, at 12:31 PM by bogdan -
Deleted lines 61-66:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~b]] &mdash; [-15 February 2013, 15:40-]
>>messageitem<<
a
>><<
February 15, 2013, at 04:40 PM by b - Comment added
Added lines 62-67:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~b]] &mdash; [-15 February 2013, 15:40-]
>>messageitem<<
a
>><<
October 23, 2012, at 04:12 PM by bogdan -
Deleted lines 61-66:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Meysa]] &mdash; [-22 October 2012, 16:10-]
>>messageitem<<
You are all right to a certain nxetet. It really depends on what level of study we are talking about. To develop small or non critical softwares or to administrate non critical networks, we don't need to be very good at these two subject to study IT. For now, these are usually needed for IT markets in Cambodia. Physics (specifically electronics) are required for computer engineers (people who design, e.g., CPU). For critical systems, like softwares to control airplane, techniques in maths are used, e.g., to prove that the softwares are correct. Even in Networks, we use techniques in maths to prove correctness of protocols. Cryptography, which also concerns maths, is used to transmit data securely on networks.But for the need of our country right now, we don't need to be very good at these two subject to be able study IT. As already mentioned in the comments, it depends on our efforts and commitments. Everybody can study IT if they really like it.
>><<
October 22, 2012, at 05:10 PM by Meysa - Comment added
Added lines 62-67:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Meysa]] &mdash; [-22 October 2012, 16:10-]
>>messageitem<<
You are all right to a certain nxetet. It really depends on what level of study we are talking about. To develop small or non critical softwares or to administrate non critical networks, we don't need to be very good at these two subject to study IT. For now, these are usually needed for IT markets in Cambodia. Physics (specifically electronics) are required for computer engineers (people who design, e.g., CPU). For critical systems, like softwares to control airplane, techniques in maths are used, e.g., to prove that the softwares are correct. Even in Networks, we use techniques in maths to prove correctness of protocols. Cryptography, which also concerns maths, is used to transmit data securely on networks.But for the need of our country right now, we don't need to be very good at these two subject to be able study IT. As already mentioned in the comments, it depends on our efforts and commitments. Everybody can study IT if they really like it.
>><<
January 17, 2012, at 10:59 PM by rgagnon -
Changed line 23 from:
'''Presence Diagrame''' (click to enlarge)
to:
'''Presence Diagram''' (click to enlarge)
January 17, 2012, at 10:58 PM by rgagnon -
Changed line 14 from:
** a faster integrated xcap mode that uses database as an interface with the XCAP server ( works with OpenXCAP )
to:
** a faster integrated xcap mode that uses a database as an interface with the XCAP server ( works with OpenXCAP )
Changed line 16 from:
** a fallback to database mode can be configured useful when more that one server is used for a domain
to:
** a fallback to database mode can be configured useful when more than one server is used for a domain
Changed line 33 from:
*[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSER modules.
to:
*[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSIPS modules.
October 27, 2011, at 05:36 PM by bogdan -
Deleted lines 61-66:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Ducky]] &mdash; [-26 October 2011, 22:51-]
>>messageitem<<
The gneius store called, they're running out of you.
>><<
October 26, 2011, at 11:51 PM by Ducky - Comment added
Added lines 62-67:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Ducky]] &mdash; [-26 October 2011, 22:51-]
>>messageitem<<
The gneius store called, they're running out of you.
>><<
September 18, 2011, at 08:31 PM by bogdan -
Changed lines 61-65 from:
[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Ronalee]] &mdash; [-16 September 2011, 19:30-]
>>messageitem<<
These pieces really set a standard in the insudtry.
>><<
to:
September 16, 2011, at 08:30 PM by Ronalee - Comment added
Added lines 60-65:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Ronalee]] &mdash; [-16 September 2011, 19:30-]
>>messageitem<<
These pieces really set a standard in the insudtry.
>><<
February 11, 2011, at 06:02 PM by anca_vamanu -
Deleted lines 59-123:


[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Shreyas]] &mdash; [-27 August 2009, 11:14-]
>>messageitem<<
Great!!!!!!!
>><<

[[#comment2]](:nl:)>>messagehead<<
!!!!![[~Sanjeev]] &mdash; [-09 September 2009, 06:21-]
>>messageitem<<
these four tables are pre-created in the database? \\
%blue%[bogdan] yes, they are created with "opesipsdbctl" tool %%
>><<

[[#comment3]](:nl:)>>messagehead<<
!!!!![[~CheeWii]] &mdash; [-01 November 2009, 08:00-]
>>messageitem<<
yehn..
>><<

[[#comment4]](:nl:)>>messagehead<<
!!!!![[~Alcon]] &mdash; [-19 November 2009, 01:20-]
>>messageitem<<
Thanks for the explanation and the Databases !!
>><<

[[#comment5]](:nl:)>>messagehead<<
!!!!![[~china users]] &mdash; [-15 December 2009, 10:20-]
>>messageitem<<
HI,how can i use utf-8 in mysql ? \\
%blue%[bogdan] when creating the tables, you can select a charset to be used %%
>><<

[[#comment6]](:nl:)>>messagehead<<
!!!!![[~Qasim ]] &mdash; [-25 November 2010, 13:44-]
>>messageitem<<
Hello I am trying to configure opensips with presence module. After making loading and parametizing both presence and db_mysql when I try to launch opensips. I get the following error.What could be the problem ?

Thanks
Regards
.
.
.
.
Nov 25 13:41:56 [9189] DBG:db_mysql:db_mysql_connect: opening connection: mysql://xxxx:xxxx@localhost/opensips
Nov 25 13:41:56 [9189] ERROR:db_mysql:db_mysql_connect: driver error(2002): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Nov 25 13:41:56 [9189] ERROR:db_mysql:db_mysql_new_connection: initial connect failed
Nov 25 13:41:56 [9189] ERROR:core:db_do_init: could not add connection to the pool
Nov 25 13:41:56 [9189] ERROR:presence:mod_init: connecting to database failed
Nov 25 13:41:56 [9189] ERROR:core:init_mod: failed to initialize module presence
Nov 25 13:41:56 [9189] ERROR:core:main: error while initializing modules
Nov 25 13:41:56 [9189] DBG:presence_xml:destroy: start
Nov 25 13:41:56 [9189] NOTICE:presence:destroy: destroy module ...
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: tm_shutdown : start
Nov 25 13:41:56 [9189] DBG:tm:unlink_timer_lists: emptying DELETE list
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: emptying hash table
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: releasing timers
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: removing semaphores
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: destroying callback lists
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: tm_shutdown : done
Nov 25 13:41:56 [9189] DBG:core:shm_mem_destroy:
Nov 25 13:41:56 [9189] DBG:core:shm_mem_destroy: destroying the shared memory lock

>><<
February 11, 2011, at 06:01 PM by anca_vamanu -
Deleted lines 59-200:

'''[++The description of the tables++]'''

'''presentity'''

|| border=1
||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| username || varchar(64) || NO || MUL || NULL || ||
|| domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || NULL || ||
|| etag || varchar(64) || NO || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| received_time || int(11) || NO || || NULL || ||
|| body || blob || NO || || NULL || ||

[++[@
CREATE TABLE `presentity` (
`id` int(10) unsigned NOT NULL auto_increment,
`username` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL,
`etag` varchar(64) NOT NULL,
`expires` int(11) NOT NULL,
`received_time` int(11) NOT NULL,
`body` blob NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `presentity_idx` (`username`,`domain`,`event`,`etag`)
) ENGINE=MyISAM;
@]++]

'''active_watchers'''

||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| presentity_uri || varchar(128) || NO || MUL || NULL || ||
|| watcher_username || varchar(64) || NO || || NULL || ||
|| watcher_domain || varchar(64) || NO || || NULL || ||
|| to_user || varchar(64) || NO || || NULL || ||
|| to_domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || presence || ||
|| event_id || varchar(64) || YES || || NULL || ||
|| to_tag || varchar(64) || NO || || NULL || ||
|| from_tag || varchar(64) || NO || || NULL || ||
|| callid || varchar(64) || NO || || NULL || ||
|| local_cseq || int(11) || NO || || NULL || ||
|| remote_cseq || int(11) || NO || || NULL || ||
|| contact || varchar(64) || NO || || NULL || ||
|| record_route || text || YES || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| status || int(11) || NO || || 2 || ||
|| reason || varchar(64) || NO || || NULL || ||
|| version || int(11) || NO || || 0 || ||
|| socket_info || varchar(64) || NO || || NULL || ||
|| local_contact || varchar(128) || NO || || NULL || ||

[++[@
CREATE TABLE `active_watchers` (
`id` int(10) unsigned NOT NULL auto_increment,
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`to_user` varchar(64) NOT NULL,
`to_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`event_id` varchar(64) default NULL,
`to_tag` varchar(64) NOT NULL,
`from_tag` varchar(64) NOT NULL,
`callid` varchar(64) NOT NULL,
`local_cseq` int(11) NOT NULL,
`remote_cseq` int(11) NOT NULL,
`contact` varchar(64) NOT NULL,
`record_route` text,
`expires` int(11) NOT NULL,
`status` int(11) NOT NULL default '2',
`reason` varchar(64) NOT NULL,
`version` int(11) NOT NULL default '0',
`socket_info` varchar(64) NOT NULL,
`local_contact` varchar(128) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `active_watchers_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`)
) ENGINE=MyISAM;
@]++]


'''watchers'''

||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| presentity_uri || varchar(128) || NO || MUL || NULL || ||
|| watcher_username || varchar(64) || NO || || NULL || ||
|| watcher_domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || presence || ||
|| status || int(11) || NO || || NULL || ||
|| reason || varchar(64) || YES || || NULL || ||
|| inserted_time || int(11) || NO || || NULL || ||

[++[@
CREATE TABLE `watchers` (
`id` int(10) unsigned NOT NULL auto_increment,
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`status` int(11) NOT NULL,
`reason` varchar(64) default NULL,
`inserted_time` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `watcher_idx` (`presentity_uri`,`watcher_username`,`watcher_domain`,`event`)
) ENGINE=MyISAM;
@]++]


'''xcap'''

||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| username || varchar(64) || NO || MUL || NULL || ||
|| domain || varchar(64) || NO || || NULL || ||
|| doc || blob || NO || || NULL || ||
|| doc_type || int(11) || NO || || NULL || ||
|| etag || varchar(64) || NO || || NULL || ||
|| source || int(11) || NO || MUL || NULL || ||
|| doc_uri || varchar(128) || NO || || NULL || ||
|| port || int(11) || NO || || NULL || ||

[++[@
CREATE TABLE `xcap` (
`id` int(10) unsigned NOT NULL auto_increment,
`username` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`doc` blob NOT NULL,
`doc_type` int(11) NOT NULL,
`etag` varchar(64) NOT NULL,
`source` int(11) NOT NULL,
`doc_uri` varchar(128) NOT NULL,
`port` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `account_doc_type_idx` (`username`,`domain`,`doc_type`,`doc_uri`),
KEY `source_idx` (`source`)
) ENGINE=MyISAM;
@]++]
February 11, 2011, at 03:48 PM by anca_vamanu -
Added line 3:
%block text-align=right% '''written by Anca Vamanu'''
November 25, 2010, at 02:44 PM by Qasim - Comment added
Added lines 233-264:
>><<

[[#comment6]](:nl:)>>messagehead<<
!!!!![[~Qasim ]] &mdash; [-25 November 2010, 13:44-]
>>messageitem<<
Hello I am trying to configure opensips with presence module. After making loading and parametizing both presence and db_mysql when I try to launch opensips. I get the following error.What could be the problem ?

Thanks
Regards
.
.
.
.
Nov 25 13:41:56 [9189] DBG:db_mysql:db_mysql_connect: opening connection: mysql://xxxx:xxxx@localhost/opensips
Nov 25 13:41:56 [9189] ERROR:db_mysql:db_mysql_connect: driver error(2002): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Nov 25 13:41:56 [9189] ERROR:db_mysql:db_mysql_new_connection: initial connect failed
Nov 25 13:41:56 [9189] ERROR:core:db_do_init: could not add connection to the pool
Nov 25 13:41:56 [9189] ERROR:presence:mod_init: connecting to database failed
Nov 25 13:41:56 [9189] ERROR:core:init_mod: failed to initialize module presence
Nov 25 13:41:56 [9189] ERROR:core:main: error while initializing modules
Nov 25 13:41:56 [9189] DBG:presence_xml:destroy: start
Nov 25 13:41:56 [9189] NOTICE:presence:destroy: destroy module ...
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: tm_shutdown : start
Nov 25 13:41:56 [9189] DBG:tm:unlink_timer_lists: emptying DELETE list
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: emptying hash table
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: releasing timers
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: removing semaphores
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: destroying callback lists
Nov 25 13:41:56 [9189] DBG:tm:tm_shutdown: tm_shutdown : done
Nov 25 13:41:56 [9189] DBG:core:shm_mem_destroy:
Nov 25 13:41:56 [9189] DBG:core:shm_mem_destroy: destroying the shared memory lock
February 18, 2010, at 12:15 PM by bogdan -
Changed lines 212-213 from:
these four tables are pre-created in the database?
to:
these four tables are pre-created in the database? \\
%blue%[bogdan] yes, they are created with "opesipsdbctl" tool %%
Changed lines 231-232 from:
HI,how can i use utf-8 in mysql ?
to:
HI,how can i use utf-8 in mysql ? \\
%blue%[bogdan] when creating the tables, you can select a charset to be used %%
December 15, 2009, at 11:20 AM by china users - Comment added
Added lines 225-230:
>><<

[[#comment5]](:nl:)>>messagehead<<
!!!!![[~china users]] &mdash; [-15 December 2009, 10:20-]
>>messageitem<<
HI,how can i use utf-8 in mysql ?
November 19, 2009, at 02:20 AM by Alcon - Comment added
Added lines 219-224:
>><<

[[#comment4]](:nl:)>>messagehead<<
!!!!![[~Alcon]] &mdash; [-19 November 2009, 01:20-]
>>messageitem<<
Thanks for the explanation and the Databases !!
November 01, 2009, at 09:00 AM by CheeWii - Comment added
Added lines 213-218:
>><<

[[#comment3]](:nl:)>>messagehead<<
!!!!![[~CheeWii]] &mdash; [-01 November 2009, 08:00-]
>>messageitem<<
yehn..
September 09, 2009, at 07:21 AM by Sanjeev - Comment added
Added lines 207-212:
>><<

[[#comment2]](:nl:)>>messagehead<<
!!!!![[~Sanjeev]] &mdash; [-09 September 2009, 06:21-]
>>messageitem<<
these four tables are pre-created in the database?
August 27, 2009, at 12:14 PM by Shreyas - Comment added
Added lines 202-207:

[[#comment1]](:nl:)>>messagehead<<
!!!!![[~Shreyas]] &mdash; [-27 August 2009, 11:14-]
>>messageitem<<
Great!!!!!!!
>><<
March 16, 2009, at 03:15 PM by anca_vamanu -
Changed line 42 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 [[openxcap_pres_config | configuration file example]] here.\\
March 16, 2009, at 03:13 PM by anca_vamanu -
Changed lines 42-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 [[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'.
March 03, 2009, at 01:17 PM by anca_vamanu -
Added lines 200-202:


(:commentboxchrono:)
January 16, 2009, at 04:28 PM by 81.180.102.217 -
Changed lines 42-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.
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 [[openxcap_pres_config | configuration file example]] here.
October 03, 2008, at 01:43 PM by 81.180.102.217 -
Changed line 9 from:
(:toc-float Table of Content:)
to:
October 03, 2008, at 01:42 PM by 81.180.102.217 -
Changed line 9 from:
to:
(:toc-float Table of Content:)
August 05, 2008, at 03:05 PM by 81.180.102.217 -
Changed lines 23-24 from:
[[Presence Diagram | http://www.opensips.org/images/presence-schema-small.jpg]]
to:
[[Presence_Diagram | http://www.opensips.org/images/presence-schema-small.jpg]]
Changed line 37 from:
The architecture in the [[pres_schem| 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 [[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.
August 05, 2008, at 02:54 PM by 81.180.102.217 -
Changed lines 23-24 from:
[[http://www.opensips.org/images/presence-schema-small.jpg]]
to:
[[Presence Diagram | http://www.opensips.org/images/presence-schema-small.jpg]]
August 05, 2008, at 02:52 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' (click to enlarge) http://www.opensips.org/images/presence-schema-small.jpg
to:
'''Presence Diagrame''' (click to enlarge)
[[http://www.opensips.org/images/presence-schema-small.jpg]]
August 05, 2008, at 02:51 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' [[http://www.opensips.org/html/presence-schema.jpg | presence scheme]]
to:
'''Presence Diagrame''' (click to enlarge) http://www.opensips.org/images/presence-schema-small.jpg
August 05, 2008, at 02:45 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' [[http://www.opensips.org/pmwiki/images/presence-schema.jpg | presence scheme]]
to:
'''Presence Diagrame''' [[http://www.opensips.org/html/presence-schema.jpg | presence scheme]]
August 05, 2008, at 02:39 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' [[http://www.opensips.org/images/presence-schema.jpg||presence scheme]]
to:
'''Presence Diagrame''' [[http://www.opensips.org/pmwiki/images/presence-schema.jpg | presence scheme]]
August 05, 2008, at 02:39 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' [[http://www.opensips.org/images/presence-schema.jpg|presence scheme]]
to:
'''Presence Diagrame''' [[http://www.opensips.org/images/presence-schema.jpg||presence scheme]]
August 05, 2008, at 02:38 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' [[[http://www.opensips.org/images/presence-schema.jpg|presence scheme]]
to:
'''Presence Diagrame''' [[http://www.opensips.org/images/presence-schema.jpg|presence scheme]]
August 05, 2008, at 02:38 PM by 81.180.102.217 -
Changed lines 22-23 from:
'''Presence Diagrame''' (click to enlarge) [[wiki:presence-schema-small.jpg|presence scheme]]
to:
'''Presence Diagrame''' [[[http://www.opensips.org/images/presence-schema.jpg|presence scheme]]
July 31, 2008, at 06:15 PM by 81.180.102.217 -
Changed lines 36-38 from:
The architecture in the [[pres_schem| diagram]] coresponds 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 accoring to the needs and resources. This can be done by configuring the modules so that some connections are removed or others appear.
to:
The architecture in the [[pres_schem| 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.
Changed lines 41-42 from:
# If you want presence privacy rules enabled and you use a XCAP server, but one that comunicates 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 comunicates only with the database.
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.
Changed lines 45-47 from:
# 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 achived by setting the '''presence''' module parameter '''fallback2db'''.

to:
# 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'''.

July 24, 2008, at 12:05 PM by 81.180.102.217 -
Changed lines 3-72 from:
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 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 that 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 Diagrame''' (click to enlarge) [[wiki:presence-schema-small.jpg|presence scheme]]

[[#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 OpenSER modules.


[[#configuration]]
!!Configuration
The architecture in the [[pres_schem| diagram]] coresponds 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 accoring 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 comunicates 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 comunicates only with the database.

# 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 achived 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.

'''[++The description of the tables++]'''

'''presentity'''

|| border=1
||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| username || varchar(64) || NO || MUL || NULL || ||
|| domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || NULL || ||
|| etag || varchar(64) || NO || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| received_time || int(11) || NO || || NULL || ||
|| body || blob || NO || || NULL || ||
Changed line 74 from:
CREATE TABLE `active_watchers` (
to:
CREATE TABLE `presentity` (
Changed lines 76-89 from:
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`to_user` varchar(64) NOT NULL,
`to_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`event_id` varchar(64) default NULL,
`to_tag` varchar(64) NOT NULL,
`from_tag` varchar(64) NOT NULL,
`callid` varchar(64) NOT NULL,
`local_cseq` int(11) NOT NULL,
`remote_cseq` int(11) NOT NULL,
`contact` varchar(64) NOT NULL,
`record_route` text,
to:
`username` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL,
`etag` varchar(64) NOT NULL,
Changed lines 81-85 from:
`status` int(11) NOT NULL default '2',
`reason` varchar(64) NOT NULL,
`version` int(11) NOT NULL default '0',
`socket_info` varchar(64) NOT NULL,
`local_contact` varchar(128) NOT NULL,
to:
`received_time` int(11) NOT NULL,
`body` blob NOT NULL,
Changed lines 84-85 from:
UNIQUE KEY `active_watchers_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`)
) ENGINE=MyISAM
to:
UNIQUE KEY `presentity_idx` (`username`,`domain`,`event`,`etag`)
) ENGINE=MyISAM;
Added lines 87-198:

'''active_watchers'''

||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| presentity_uri || varchar(128) || NO || MUL || NULL || ||
|| watcher_username || varchar(64) || NO || || NULL || ||
|| watcher_domain || varchar(64) || NO || || NULL || ||
|| to_user || varchar(64) || NO || || NULL || ||
|| to_domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || presence || ||
|| event_id || varchar(64) || YES || || NULL || ||
|| to_tag || varchar(64) || NO || || NULL || ||
|| from_tag || varchar(64) || NO || || NULL || ||
|| callid || varchar(64) || NO || || NULL || ||
|| local_cseq || int(11) || NO || || NULL || ||
|| remote_cseq || int(11) || NO || || NULL || ||
|| contact || varchar(64) || NO || || NULL || ||
|| record_route || text || YES || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| status || int(11) || NO || || 2 || ||
|| reason || varchar(64) || NO || || NULL || ||
|| version || int(11) || NO || || 0 || ||
|| socket_info || varchar(64) || NO || || NULL || ||
|| local_contact || varchar(128) || NO || || NULL || ||

[++[@
CREATE TABLE `active_watchers` (
`id` int(10) unsigned NOT NULL auto_increment,
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`to_user` varchar(64) NOT NULL,
`to_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`event_id` varchar(64) default NULL,
`to_tag` varchar(64) NOT NULL,
`from_tag` varchar(64) NOT NULL,
`callid` varchar(64) NOT NULL,
`local_cseq` int(11) NOT NULL,
`remote_cseq` int(11) NOT NULL,
`contact` varchar(64) NOT NULL,
`record_route` text,
`expires` int(11) NOT NULL,
`status` int(11) NOT NULL default '2',
`reason` varchar(64) NOT NULL,
`version` int(11) NOT NULL default '0',
`socket_info` varchar(64) NOT NULL,
`local_contact` varchar(128) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `active_watchers_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`)
) ENGINE=MyISAM;
@]++]


'''watchers'''

||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| presentity_uri || varchar(128) || NO || MUL || NULL || ||
|| watcher_username || varchar(64) || NO || || NULL || ||
|| watcher_domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || presence || ||
|| status || int(11) || NO || || NULL || ||
|| reason || varchar(64) || YES || || NULL || ||
|| inserted_time || int(11) || NO || || NULL || ||

[++[@
CREATE TABLE `watchers` (
`id` int(10) unsigned NOT NULL auto_increment,
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`status` int(11) NOT NULL,
`reason` varchar(64) default NULL,
`inserted_time` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `watcher_idx` (`presentity_uri`,`watcher_username`,`watcher_domain`,`event`)
) ENGINE=MyISAM;
@]++]


'''xcap'''

||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| username || varchar(64) || NO || MUL || NULL || ||
|| domain || varchar(64) || NO || || NULL || ||
|| doc || blob || NO || || NULL || ||
|| doc_type || int(11) || NO || || NULL || ||
|| etag || varchar(64) || NO || || NULL || ||
|| source || int(11) || NO || MUL || NULL || ||
|| doc_uri || varchar(128) || NO || || NULL || ||
|| port || int(11) || NO || || NULL || ||

[++[@
CREATE TABLE `xcap` (
`id` int(10) unsigned NOT NULL auto_increment,
`username` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`doc` blob NOT NULL,
`doc_type` int(11) NOT NULL,
`etag` varchar(64) NOT NULL,
`source` int(11) NOT NULL,
`doc_uri` varchar(128) NOT NULL,
`port` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `account_doc_type_idx` (`username`,`domain`,`doc_type`,`doc_uri`),
KEY `source_idx` (`source`)
) ENGINE=MyISAM;
@]++]
July 24, 2008, at 11:57 AM by 81.180.102.217 -
Deleted lines 3-72:
# [[#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 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 that 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 Diagrame''' (click to enlarge) [[wiki:presence-schema-small.jpg|presence scheme]]

[[#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 OpenSER modules.


[[#configuration]]
!!Configuration
The architecture in the [[pres_schem| diagram]] coresponds 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 accoring 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 comunicates 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 comunicates only with the database.

# 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 achived 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.

'''[++The description of the tables++]'''

'''presentity'''

|| border=1
||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| username || varchar(64) || NO || MUL || NULL || ||
|| domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || NULL || ||
|| etag || varchar(64) || NO || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| received_time || int(11) || NO || || NULL || ||
|| body || blob || NO || || NULL || ||
Changed line 5 from:
CREATE TABLE `presentity` (
to:
CREATE TABLE `active_watchers` (
Changed lines 7-10 from:
`username` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL,
`etag` varchar(64) NOT NULL,
to:
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`to_user` varchar(64) NOT NULL,
`to_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`event_id` varchar(64) default NULL,
`to_tag` varchar(64) NOT NULL,
`from_tag` varchar(64) NOT NULL,
`callid` varchar(64) NOT NULL,
`local_cseq` int(11) NOT NULL,
`remote_cseq` int(11) NOT NULL,
`contact` varchar(64) NOT NULL,
`record_route` text,
Changed lines 22-23 from:
`received_time` int(11) NOT NULL,
`body` blob NOT NULL,
to:
`status` int(11) NOT NULL default '2',
`reason` varchar(64) NOT NULL,
`version` int(11) NOT NULL default '0',
`socket_info` varchar(64) NOT NULL,
`local_contact` varchar(128) NOT NULL,
Changed lines 28-29 from:
UNIQUE KEY `presentity_idx` (`username`,`domain`,`event`,`etag`)
) ENGINE=MyISAM ;
to:
UNIQUE KEY `active_watchers_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`)
) ENGINE=MyISAM
Deleted lines 30-96:

'''active_watchers'''
||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| presentity_uri || varchar(128) || NO || MUL || NULL || ||
|| watcher_username || varchar(64) || NO || || NULL || ||
|| watcher_domain || varchar(64) || NO || || NULL || ||
|| to_user || varchar(64) || NO || || NULL || ||
|| to_domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || presence || ||
|| event_id || varchar(64) || YES || || NULL || ||
|| to_tag || varchar(64) || NO || || NULL || ||
|| from_tag || varchar(64) || NO || || NULL || ||
|| callid || varchar(64) || NO || || NULL || ||
|| local_cseq || int(11) || NO || || NULL || ||
|| remote_cseq || int(11) || NO || || NULL || ||
|| contact || varchar(64) || NO || || NULL || ||
|| record_route || text || YES || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| status || int(11) || NO || || 2 || ||
|| reason || varchar(64) || NO || || NULL || ||
|| version || int(11) || NO || || 0 || ||
|| socket_info || varchar(64) || NO || || NULL || ||
|| local_contact || varchar(128) || NO || || NULL || ||

[++[@
--
-- Host: localhost
-- Generation Time: Jul 24, 2008 at 11:55 AM
-- Server version: 5.0.51
-- PHP Version: 5.2.0-8+etch7
--
-- Database: `opensips`
--

-- --------------------------------------------------------

--
-- Table structure for table `active_watchers`
--

CREATE TABLE `active_watchers` (
`id` int(10) unsigned NOT NULL auto_increment,
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`to_user` varchar(64) NOT NULL,
`to_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`event_id` varchar(64) default NULL,
`to_tag` varchar(64) NOT NULL,
`from_tag` varchar(64) NOT NULL,
`callid` varchar(64) NOT NULL,
`local_cseq` int(11) NOT NULL,
`remote_cseq` int(11) NOT NULL,
`contact` varchar(64) NOT NULL,
`record_route` text,
`expires` int(11) NOT NULL,
`status` int(11) NOT NULL default '2',
`reason` varchar(64) NOT NULL,
`version` int(11) NOT NULL default '0',
`socket_info` varchar(64) NOT NULL,
`local_contact` varchar(128) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `active_watchers_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`)
) ENGINE=MyISAM
@]++]
July 24, 2008, at 11:57 AM by 81.180.102.217 -
Added lines 89-154:
'''active_watchers'''
||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| presentity_uri || varchar(128) || NO || MUL || NULL || ||
|| watcher_username || varchar(64) || NO || || NULL || ||
|| watcher_domain || varchar(64) || NO || || NULL || ||
|| to_user || varchar(64) || NO || || NULL || ||
|| to_domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || presence || ||
|| event_id || varchar(64) || YES || || NULL || ||
|| to_tag || varchar(64) || NO || || NULL || ||
|| from_tag || varchar(64) || NO || || NULL || ||
|| callid || varchar(64) || NO || || NULL || ||
|| local_cseq || int(11) || NO || || NULL || ||
|| remote_cseq || int(11) || NO || || NULL || ||
|| contact || varchar(64) || NO || || NULL || ||
|| record_route || text || YES || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| status || int(11) || NO || || 2 || ||
|| reason || varchar(64) || NO || || NULL || ||
|| version || int(11) || NO || || 0 || ||
|| socket_info || varchar(64) || NO || || NULL || ||
|| local_contact || varchar(128) || NO || || NULL || ||

[++[@
--
-- Host: localhost
-- Generation Time: Jul 24, 2008 at 11:55 AM
-- Server version: 5.0.51
-- PHP Version: 5.2.0-8+etch7
--
-- Database: `opensips`
--

-- --------------------------------------------------------

--
-- Table structure for table `active_watchers`
--

CREATE TABLE `active_watchers` (
`id` int(10) unsigned NOT NULL auto_increment,
`presentity_uri` varchar(128) NOT NULL,
`watcher_username` varchar(64) NOT NULL,
`watcher_domain` varchar(64) NOT NULL,
`to_user` varchar(64) NOT NULL,
`to_domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL default 'presence',
`event_id` varchar(64) default NULL,
`to_tag` varchar(64) NOT NULL,
`from_tag` varchar(64) NOT NULL,
`callid` varchar(64) NOT NULL,
`local_cseq` int(11) NOT NULL,
`remote_cseq` int(11) NOT NULL,
`contact` varchar(64) NOT NULL,
`record_route` text,
`expires` int(11) NOT NULL,
`status` int(11) NOT NULL default '2',
`reason` varchar(64) NOT NULL,
`version` int(11) NOT NULL default '0',
`socket_info` varchar(64) NOT NULL,
`local_contact` varchar(128) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `active_watchers_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`)
) ENGINE=MyISAM
@]++]
July 24, 2008, at 11:52 AM by 81.180.102.217 -
Changed line 74 from:
[@
to:
[++[@
Changed lines 87-88 from:
@]
to:
@]++]
July 24, 2008, at 11:52 AM by 81.180.102.217 -
Changed lines 74-75 from:
[=CREATE TABLE `presentity` (
to:
[@
CREATE TABLE `presentity` (
Changed lines 86-87 from:
) ENGINE=MyISAM ;=]
to:
) ENGINE=MyISAM ;
@]
July 24, 2008, at 11:51 AM by 81.180.102.217 -
Changed lines 74-75 from:
[=
CREATE TABLE `presentity` (
to:
[=CREATE TABLE `presentity` (
Changed lines 85-87 from:
) ENGINE=MyISAM ;
=]
to:
) ENGINE=MyISAM ;=]
July 24, 2008, at 11:51 AM by 81.180.102.217 -
Deleted lines 73-77:
-- --------------------------------------------------------

--
-- Table structure for table `presentity`
--
July 24, 2008, at 11:51 AM by 81.180.102.217 -
Changed lines 59-62 from:
!!!The description of the tables

!!presentity
to:
'''[++The description of the tables++]'''

'''presentity'''
July 24, 2008, at 11:50 AM by 81.180.102.217 -
Added lines 59-62:
!!!The description of the tables

!!presentity
Added lines 73-93:

-- --------------------------------------------------------

--
-- Table structure for table `presentity`
--
[=
CREATE TABLE `presentity` (
`id` int(10) unsigned NOT NULL auto_increment,
`username` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`event` varchar(64) NOT NULL,
`etag` varchar(64) NOT NULL,
`expires` int(11) NOT NULL,
`received_time` int(11) NOT NULL,
`body` blob NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `presentity_idx` (`username`,`domain`,`event`,`etag`)
) ENGINE=MyISAM ;
=]
July 24, 2008, at 11:46 AM by 81.180.102.217 -
Added line 58:
Changed lines 60-67 from:
||!Keys ||! Type ||! Actions ||! Description ||
||p_user || varchar(64) || primary || presentity username ||
||p_domain || varchar(128) || primary || presentity domain ||
||w_user || varchar(64) || primary || watcher username ||
||w_domain || varchar(128) || primary || watcher domain ||
||subs_status|| varchar(64)|| || the current subscription status ||
||reason || varchar(64) || || if the status is terminated this field records the reason that lead to this ||
||inserted_time|| int(11) || || timestamp of insertion ||
to:
||! Field ||! Type ||! Null ||! Key ||! Default ||! Extra ||
|| id || int(10) unsigned || NO || PRI || NULL || auto_increment ||
|| username || varchar(64) || NO || MUL || NULL || ||
|| domain || varchar(64) || NO || || NULL || ||
|| event || varchar(64) || NO || || NULL || ||
|| etag || varchar(64) || NO || || NULL || ||
|| expires || int(11) || NO || || NULL || ||
|| received_time || int(11) || NO || || NULL || ||
|| body || blob || NO || || NULL || ||
July 24, 2008, at 11:40 AM by 81.180.102.217 -
Changed line 66 from:
|inserted_time|| int(11) || || timestamp of insertion ||
to:
||inserted_time|| int(11) || || timestamp of insertion ||
July 24, 2008, at 11:40 AM by 81.180.102.217 -
Changed line 59 from:
||!Keys || !Type || !Actions || !Description ||
to:
||!Keys ||! Type ||! Actions ||! Description ||
July 24, 2008, at 11:39 AM by 81.180.102.217 -
Changed lines 58-65 from:
^Keys ^Type ^Actions ^Description |
|p_user | varchar(64) | primary | presentity username |
|p_domain | varchar(128) | primary | presentity domain |
|w_user | varchar(64) | primary | watcher username |
|w_domain | varchar(128) | primary | watcher domain |
|subs_status | varchar(64)| | the current subscription status |
|reason | varchar(64) | | if the status is terminated this field records the reason that lead to this |
|inserted_time | int(11)| | timestamp of insertion |
to:
|| border=1
||!Keys || !Type || !Actions || !Description ||
||p_user || varchar(64) || primary || presentity username ||
||p_domain || varchar(128) || primary || presentity domain ||
||w_user || varchar(64) || primary || watcher username ||
||w_domain || varchar(128) || primary || watcher domain ||
||subs_status|| varchar(64)|| || the current subscription status ||
||reason || varchar(64) || || if the status is terminated this field records the reason that lead to this ||
|inserted_time|| int(11) || || timestamp of insertion ||
July 24, 2008, at 11:34 AM by 81.180.102.217 -
Added lines 58-65:
^Keys ^Type ^Actions ^Description |
|p_user | varchar(64) | primary | presentity username |
|p_domain | varchar(128) | primary | presentity domain |
|w_user | varchar(64) | primary | watcher username |
|w_domain | varchar(128) | primary | watcher domain |
|subs_status | varchar(64)| | the current subscription status |
|reason | varchar(64) | | if the status is terminated this field records the reason that lead to this |
|inserted_time | int(11)| | timestamp of insertion |
July 24, 2008, at 11:24 AM by 81.180.102.217 -
Changed lines 38-39 from:
There is the possibility to simplify teh scheme accoring to the needs and resources. This can be done by configuring the modules so that some connections are removed or others appear.
to:
There is the possibility to simplify the scheme accoring to the needs and resources. This can be done by configuring the modules so that some connections are removed or others appear.
Changed lines 46-48 from:
# 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 achived by setting the '''presence''' module parameter ''fallback2sb'''.

to:
# 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 achived by setting the '''presence''' module parameter '''fallback2db'''.

Changed lines 50-57 from:
!!Database
to:
!!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.
July 24, 2008, at 11:17 AM by 81.180.102.217 -
Changed lines 44-45 from:
# 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
to:
# 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).
Changed lines 48-51 from:
Xcap_client
*
periodical_query: if this parameter is unset ( set to 0 ), then the connection from xcap_client to the XCAP server for query for updates disappears. In this case, the xcap_client module expects to receive a MI command from the server when an update occurs.
to:
July 23, 2008, at 07:18 PM by 81.180.102.217 -
Changed lines 40-44 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.
Other configuration possibilities
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 [[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.
July 23, 2008, at 07:15 PM by 81.180.102.217 -
Changed lines 45-47 from:
# If you want presence privacy rules enabled and you use a XCAP server, but one that comunicates 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 comunicates only with the database.
to:
# If you want presence privacy rules enabled and you use a XCAP server, but one that comunicates 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 comunicates only with the database.
July 23, 2008, at 07:14 PM by 81.180.102.217 -
Deleted line 45:
July 23, 2008, at 07:14 PM by 81.180.102.217 -
Changed lines 49-53 from:
#
The chart shows the interactions when no restrictions are imposed.

1.
Presence module
to:
# 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

# 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 achived by setting the '''presence''' module parameter ''fallback2sb'''.

Xcap_client
Deleted lines 54-63:
fallback2db: the database is also queried for Subscribe dialog information, assuming that there might be others stored there besides the ones from the servers cache, when more servers share the same database.
2.
Presence_xml module
*
force_active: the connection with xcap_client module disappears; no query for rules doc- all subscriptions are allowed.
*
integrated_xcap_server: again the connection with xcap_client module disappears; the module only queries the database table which should be filled by the xcap_server and if no record is found then supposes that it does not exist on the server.
3.
Xcap_client
*
July 23, 2008, at 05:30 PM by 81.180.102.217 -
Changed lines 37-41 from:
The architecture in the [[pres_schem| diagram]] coresponds to a full configuration with privacy permission rules handling enabled and the use of a general XCAP server.
This can be simplificated accoring to the needs and resources.

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]].
to:
The architecture in the [[pres_schem| diagram]] coresponds 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 teh scheme accoring 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]].
Changed lines 43-66 from:
to:
Other configuration possibilities

# If you want presence privacy rules enabled and you use a XCAP server, but one that comunicates 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 comunicates only with the database.

#
The chart shows the interactions when no restrictions are imposed.

1.
Presence module
*
fallback2db: the database is also queried for Subscribe dialog information, assuming that there might be others stored there besides the ones from the servers cache, when more servers share the same database.
2.
Presence_xml module
*
force_active: the connection with xcap_client module disappears; no query for rules doc- all subscriptions are allowed.
*
integrated_xcap_server: again the connection with xcap_client module disappears; the module only queries the database table which should be filled by the xcap_server and if no record is found then supposes that it does not exist on the server.
3.
Xcap_client
*
periodical_query: if this parameter is unset ( set to 0 ), then the connection from xcap_client to the XCAP server for query for updates disappears. In this case, the xcap_client module expects to receive a MI command from the server when an update occurs.
July 23, 2008, at 05:05 PM by 81.180.102.217 -
Changed lines 39-41 from:
The most simple configuration is a presence server without privacy rules, when any body is allowed to see the presence status of anybody and there is no need for an xcap server. In this case the xcap part disapears 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 [[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.
July 23, 2008, at 04:37 PM by 81.180.102.217 -
Changed lines 37-38 from:

to:
The architecture in the [[pres_schem| diagram]] coresponds to a full configuration with privacy permission rules handling enabled and the use of a general XCAP server.
This can be simplificated accoring to the needs and resources.
The most simple configuration is a presence server without privacy rules, when any body is allowed to see the presence status of anybody and there is no need for an xcap server. In this case the xcap part disapears 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.
July 21, 2008, at 07:17 PM by 81.180.102.217 -
Changed lines 17-19 from:
* extensible - new events to be handled can be added easily due to the layered architecture

to:
* extensible - new events to be handled by the server can be added easily due to the layered architecture

July 21, 2008, at 07:16 PM by 81.180.102.217 -
Changed line 30 from:
** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' ()draft-anil-sipping- bla-03.txt)
to:
** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' (draft-anil-sipping- bla-03.txt)
July 21, 2008, at 07:02 PM by 81.180.102.217 -
Changed lines 9-10 from:
----
to:

Changed lines 15-16 from:
* fast caching with fallback to database possiblity
to:
* fast caching with periodic update in database
** a fallback to database mode can be configured useful when more that one server is used for a domain
July 21, 2008, at 06:50 PM by 81.180.102.217 -
Changed lines 14-15 from:
** a faster integrated xcap mode that uses as an interface with the XCAP server an SQL DB ( works with OpenXCAP)
* fast cache storage mode with fallback to database possiblity
to:
** a faster integrated xcap mode that uses database as an interface with the XCAP server ( works with OpenXCAP )
* fast caching with fallback to database possiblity
July 21, 2008, at 06:47 PM by 81.180.102.217 -
Added line 4:
# [[#ps_features| Features]]
Added lines 11-18:
[[#ps_features]]
!!Features
* privacy rules with XCAP storage
** a faster integrated xcap mode that uses as an interface with the XCAP server an SQL DB ( works with OpenXCAP)
* fast cache storage mode with fallback to database possiblity
* extensible - new events to be handled can be added easily due to the layered architecture

July 21, 2008, at 06:17 PM by 81.180.102.217 -
Changed lines 18-19 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:
*[[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:
Changed lines 22-30 from:
*[[#xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSER modules.

[[#presence_module]]
!!!presence module
[[#presence_aux_modules]]
!!!presence_xml and presence_mwi modules
[[#xcap_client_module]]
!!!xcap_client module
to:
*[[xcap_client_module| XCAP_CLIENT module]] - an XCAP client interface with data retrieving functionality only, for OpenSER modules.

July 21, 2008, at 06:11 PM by 81.180.102.217 -
Changed lines 20-21 from:
** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' ()draft-anil-sipping- bla-03.txt)
** presence_mwi: 'message-summary' (RFC 3842)
to:
** presence_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' ()draft-anil-sipping- bla-03.txt)
** presence_mwi: 'message-summary' (RFC 3842)
July 21, 2008, at 06:10 PM by 81.180.102.217 -
July 21, 2008, at 06:10 PM by 81.180.102.217 -
Changed line 26 from:
[#presence_aux_modules]]
to:
[[#presence_aux_modules]]
July 21, 2008, at 06:10 PM by 81.180.102.217 -
Changed line 25 from:
''presence module
to:
!!!presence module
Changed line 27 from:
''presence_xml and presence_mwi modules
to:
!!!presence_xml and presence_mwi modules
Changed lines 29-30 from:
''xcap_client module
to:
!!!xcap_client module
July 21, 2008, at 06:09 PM by 81.180.102.217 -
Changed line 12 from:
----
to:
Changed line 17 from:
----
to:
July 21, 2008, at 06:09 PM by 81.180.102.217 -
Changed line 25 from:
!!presence module
to:
''presence module
Changed line 27 from:
!!presence_xml and presence_mwi modules
to:
''presence_xml and presence_mwi modules
Changed lines 29-30 from:
!!XCAP_CLIENT module
to:
''xcap_client module
Changed lines 33-34 from:
----
to:

July 21, 2008, at 06:08 PM by 81.180.102.217 -
Changed lines 18-22 from:
*[[#presence_module| '''PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903
- **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**- an XCAP client interface with data retrieving functionality only, for OpenSER modules.
to:
*[[#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 OpenSER modules.

[[#presence_module]]
!!presence module
[#presence_aux_modules]]
!!presence_xml and presence_mwi modules
[[#xcap_client_module]]
!!XCAP_CLIENT module
July 21, 2008, at 06:04 PM by 81.180.102.217 -
Changed line 18 from:
*[[#presence_module|'''PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903
to:
*[[#presence_module| '''PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903
July 21, 2008, at 06:03 PM by 81.180.102.217 -
Changed lines 13-14 from:
to:
'''Presence Diagrame''' (click to enlarge) [[wiki:presence-schema-small.jpg|presence scheme]]
Changed lines 18-22 from:
to:
*[[#presence_module|'''PRESENCE module]] - a general, event package independent Subscribe, Publish handler – Notify generator according to RFCs 3265 and 3903
- **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**- an XCAP client interface with data retrieving functionality only, for OpenSER modules.
July 21, 2008, at 05:57 PM by 81.180.102.217 -
Changed lines 10-11 from:
#[[#ps_architecture]]
Architecture
to:
[[#ps_architecture]]
!!Architecture
Changed lines 14-15 from:
#[[#module_description]]
Module Description
to:
[[#module_description]]
!!Module Description
Changed line 19 from:
#Configuration
to:
!!Configuration
Changed line 23 from:
#Database
to:
!!Database
July 21, 2008, at 05:56 PM by 81.180.102.217 -
Changed lines 8-9 from:
to:
----
Added lines 12-13:
----
Added lines 16-17:
----
Added lines 20-21:
----
July 21, 2008, at 05:55 PM by 81.180.102.217 -
July 21, 2008, at 05:52 PM by 81.180.102.217 -
Changed lines 9-12 from:
[[#ps_architecture]]
#Architecture
[[#module_description]]
#Module Description
to:
#[[#ps_architecture]]
Architecture
#[[#module_description]]
Module Description
July 21, 2008, at 05:49 PM by 81.180.102.217 -
Changed lines 9-10 from:
[[#ps_architecture]]#Architecture
[[#module_description]]#Module Description
to:
[[#ps_architecture]]
#Architecture
[[#module_description]]
#Module Description
July 21, 2008, at 05:49 PM by 81.180.102.217 -
Changed lines 9-12 from:
[[#ps_architecture]]
#Architecture
[[#module_description]]
#Module Description
to:
[[#ps_architecture]]#Architecture
[[#module_description]]#Module Description
July 21, 2008, at 05:49 PM by 81.180.102.217 -
Deleted line 10:
July 21, 2008, at 05:48 PM by 81.180.102.217 -
Changed lines 5-8 from:
# [[module_description| Module Description]]
# [[configuration| Configuration]]
# [[database| Database]]
to:
# [[#module_description| Module Description]]
# [[#configuration| Configuration]]
# [[#database| Database]]
Changed lines 10-17 from:
#Architecture
to:
#Architecture

[[#module_description]]
#Module Description
[[#configuration]]
#Configuration
[[#database]]
#Database
July 21, 2008, at 05:47 PM by 81.180.102.217 -
Changed line 4 from:
# [[ps_architecture| Architecture]]
to:
# [[#ps_architecture| Architecture]]
July 21, 2008, at 05:46 PM by 81.180.102.217 -
Changed line 9 from:
[[ps_architecture]]
to:
[[#ps_architecture]]
July 21, 2008, at 05:45 PM by 81.180.102.217 -
Added lines 8-10:

[[ps_architecture]]
#Architecture
July 21, 2008, at 05:44 PM by 81.180.102.217 -
Added line 1:
!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsPapPa | Presence]] -> Presence Server
July 21, 2008, at 05:40 PM by 81.180.102.217 -
Changed lines 1-6 from:
!!Presence Server
to:
!!Presence Server

# [[ps_architecture| Architecture]]
# [[module_description| Module Description]]
# [[configuration| Configuration]]
# [[database| Database]]
July 21, 2008, at 05:39 PM by 81.180.102.217 -
Added line 1:
!!Presence Server

Page last modified on April 24, 2013, at 07:42 PM