Resources.PresenceServer HistoryShow minor edits - Show changes to markup April 24, 2013, at 07:42 PM
by
- Changed lines 1-63 from:
Resources -> Documentation -> Presence -> Presence ServerPresence Serverwritten by Anca Vamanu Features
ArchitecturePresence Diagram (click to enlarge) http://www.opensips.org/images/presence-schema-small.jpg Module Description
ConfigurationThe architecture in the diagram corresponds to a full configuration, when no restrictions are imposed, with privacy permission rules handling enabled and the use of a general XCAP server. There is the possibility to simplify the scheme according to the needs and resources. This can be done by configuring the modules so that some connections are removed or others appear.
DatabasePresence Server requires 4 tables in database:
The first three tables are only used internally by the server. The xcap table is either used as a communication interface between the XCAP server (if the server is working in 'integrated_xcap' mode) or as a communication means between the xcap_client module which populates the table and presence_xml module which uses that information. (:commentboxchrono:) to:
(:redirect Documentation.Tutorials-Presence-PresenceServer quiet=1:) February 28, 2013, at 12:31 PM
by
- Deleted lines 61-66:
February 15, 2013, at 04:40 PM
by
- Comment addedAdded lines 62-67:
October 23, 2012, at 04:12 PM
by
- Deleted lines 61-66:
October 22, 2012, at 05:10 PM
by
- Comment addedAdded lines 62-67:
January 17, 2012, at 10:59 PM
by
- Changed line 23 from:
Presence Diagrame (click to enlarge) to:
Presence Diagram (click to enlarge) January 17, 2012, at 10:58 PM
by
- Changed line 14 from:
to:
Changed line 16 from:
to:
Changed line 33 from:
to:
October 27, 2011, at 05:36 PM
by
- Deleted lines 61-66:
October 26, 2011, at 11:51 PM
by
- Comment addedAdded lines 62-67:
September 18, 2011, at 08:31 PM
by
- Changed lines 61-65 from:
to:
September 16, 2011, at 08:30 PM
by
- Comment addedAdded lines 60-65:
February 11, 2011, at 06:02 PM
by
- Deleted lines 59-123:
February 11, 2011, at 06:01 PM
by
- Deleted lines 59-200:
The description of the tables 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; 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; watchers
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
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
- Added line 3:
written by Anca Vamanu November 25, 2010, at 02:44 PM
by
- Comment addedAdded lines 233-264:
February 18, 2010, at 12:15 PM
by
- Changed lines 212-213 from:
these four tables are pre-created in the database? to:
these four tables are pre-created in the database? Changed lines 231-232 from:
HI,how can i use utf-8 in mysql ? to:
HI,how can i use utf-8 in mysql ? December 15, 2009, at 11:20 AM
by
- Comment addedAdded lines 225-230:
(:nl:)>>messagehead<< china users? — 15 December 2009, 10:20November 19, 2009, at 02:20 AM
by
- Comment addedAdded lines 219-224:
November 01, 2009, at 09:00 AM
by
- Comment addedAdded lines 213-218:
September 09, 2009, at 07:21 AM
by
- Comment addedAdded lines 207-212:
August 27, 2009, at 12:14 PM
by
- Comment addedAdded lines 202-207:
March 16, 2009, at 03:15 PM
by
- Changed line 42 from:
to:
March 16, 2009, at 03:13 PM
by
- Changed lines 42-43 from:
to:
March 03, 2009, at 01:17 PM
by
- Added lines 200-202:
(:commentboxchrono:) January 16, 2009, at 04:28 PM
by
- Changed lines 42-43 from:
to:
October 03, 2008, at 01:43 PM
by
- Changed line 9 from:
(:toc-float Table of Content:) to:
October 03, 2008, at 01:42 PM
by
- Changed line 9 from:
to:
(:toc-float Table of Content:) August 05, 2008, at 03:05 PM
by
- Changed lines 23-24 from:
to:
Changed line 37 from:
The architecture in the diagram? corresponds to a full configuration, when no restrictions are imposed, with privacy permission rules handling enabled and the use of a general XCAP server. to:
The architecture in the diagram corresponds to a full configuration, when no restrictions are imposed, with privacy permission rules handling enabled and the use of a general XCAP server. August 05, 2008, at 02:54 PM
by
- Changed lines 23-24 from:
http://www.opensips.org/images/presence-schema-small.jpg to:
August 05, 2008, at 02:52 PM
by
- 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
- Changed lines 22-23 from:
Presence Diagrame 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
- Changed lines 22-23 from:
Presence Diagrame presence scheme to:
Presence Diagrame presence scheme August 05, 2008, at 02:39 PM
by
- Changed lines 22-23 from:
Presence Diagrame |presence scheme to:
Presence Diagrame presence scheme August 05, 2008, at 02:39 PM
by
- Changed lines 22-23 from:
Presence Diagrame presence scheme to:
Presence Diagrame |presence scheme August 05, 2008, at 02:38 PM
by
- Changed lines 22-23 from:
Presence Diagrame to:
Presence Diagrame presence scheme August 05, 2008, at 02:38 PM
by
- Changed lines 22-23 from:
Presence Diagrame (click to enlarge) presence scheme? to:
Presence Diagrame July 31, 2008, at 06:15 PM
by
- Changed lines 36-38 from:
The architecture in the 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 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:
to:
Changed lines 45-47 from:
to:
July 24, 2008, at 12:05 PM
by
- Changed lines 3-72 from:
to:
Features
ArchitecturePresence Diagrame (click to enlarge) presence scheme?
Module Description
ConfigurationThe architecture in the 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.
DatabasePresence Server requires 4 tables in database:
The first three tables are only used internally by the server. The xcap table is either used as a communication interface between the XCAP server (if the server is working in 'integrated_xcap' mode) or as a communication means between the xcap_client module which populates the table and presence_xml module which uses that information. The description of the tables presentity
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
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
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
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
- Deleted lines 3-72:
Features
ArchitecturePresence Diagrame (click to enlarge) presence scheme?
Module Description
ConfigurationThe architecture in the 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.
DatabasePresence Server requires 4 tables in database:
The first three tables are only used internally by the server. The xcap table is either used as a communication interface between the XCAP server (if the server is working in 'integrated_xcap' mode) or as a communication means between the xcap_client module which populates the table and presence_xml module which uses that information. The description of the tables presentity
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
-- -- 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
- Added lines 89-154:
active_watchers
-- -- 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
- Changed line 74 from:
[@ to:
[++[@ Changed lines 87-88 from:
@] to:
@]++] July 24, 2008, at 11:52 AM
by
- 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
- 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
- Deleted lines 73-77:
-- -------------------------------------------------------- -- -- Table structure for table `presentity` -- July 24, 2008, at 11:51 AM
by
- Changed lines 59-62 from:
The description of the tablespresentityto:
The description of the tables presentity July 24, 2008, at 11:50 AM
by
- Added lines 59-62:
The description of the tablespresentityAdded 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
- Added line 58:
Changed lines 60-67 from:
to:
July 24, 2008, at 11:40 AM
by
- Changed line 66 from:
|inserted_time|| int(11) || || timestamp of insertion || to:
July 24, 2008, at 11:40 AM
by
- Changed line 59 from:
to:
July 24, 2008, at 11:39 AM
by
- 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:
|inserted_time|| int(11) || || timestamp of insertion || July 24, 2008, at 11:34 AM
by
- 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
- 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:
to:
Changed lines 50-57 from:
Databaseto:
DatabasePresence Server requires 4 tables in database:
The first three tables are only used internally by the server. The xcap table is either used as a communication interface between the XCAP server (if the server is working in 'integrated_xcap' mode) or as a communication means between the xcap_client module which populates the table and presence_xml module which uses that information. July 24, 2008, at 11:17 AM
by
- Changed lines 44-45 from:
to:
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
- Changed lines 40-44 from:
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:
July 23, 2008, at 07:15 PM
by
- Changed lines 45-47 from:
In this case the scheme simplifies by removing the xcap_client module and having the presence_xml module comunicates only with the database. to:
July 23, 2008, at 07:14 PM
by
- Deleted line 45:
July 23, 2008, at 07:14 PM
by
- Changed lines 49-53 from:
The chart shows the interactions when no restrictions are imposed. 1. Presence module to:
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
- Changed lines 37-41 from:
The architecture in the 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 here. to:
The architecture in the 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.
Changed lines 43-66 from:
to:
Other configuration possibilities
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
- 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 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 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
- Changed lines 37-38 from:
to:
The architecture in the 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 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
- Changed lines 17-19 from:
to:
July 21, 2008, at 07:16 PM
by
- Changed line 30 from:
to:
July 21, 2008, at 07:02 PM
by
- Changed lines 9-10 from:
to:
Changed lines 15-16 from:
to:
July 21, 2008, at 06:50 PM
by
- Changed lines 14-15 from:
to:
July 21, 2008, at 06:47 PM
by
- Added line 4:
Added lines 11-18:
Features
July 21, 2008, at 06:17 PM
by
- Changed lines 18-19 from:
to:
Changed lines 22-30 from:
presence modulepresence_xml and presence_mwi modulesxcap_client moduleto:
July 21, 2008, at 06:11 PM
by
- 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:
July 21, 2008, at 06:10 PM
by - July 21, 2008, at 06:10 PM
by
- Changed line 26 from:
[#presence_aux_modules]] to:
July 21, 2008, at 06:10 PM
by
- Changed line 25 from:
''presence module to:
presence moduleChanged line 27 from:
''presence_xml and presence_mwi modules to:
presence_xml and presence_mwi modulesChanged lines 29-30 from:
''xcap_client module to:
xcap_client moduleJuly 21, 2008, at 06:09 PM
by
- Changed line 12 from:
to:
Changed line 17 from:
to:
July 21, 2008, at 06:09 PM
by
- Changed line 25 from:
presence moduleto:
''presence module Changed line 27 from:
presence_xml and presence_mwi modulesto:
''presence_xml and presence_mwi modules Changed lines 29-30 from:
XCAP_CLIENT moduleto:
''xcap_client module Changed lines 33-34 from:
to:
July 21, 2008, at 06:08 PM
by
- Changed lines 18-22 from:
- **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_xml: 'presence'( RFC 3856) , 'presence.winfo' (RFC 3857), 'dialog;sla' ()draft-anil-sipping- bla-03.txt) ** presence_mwi: 'message-summary' (RFC 3842)
presence module[#presence_aux_modules]] presence_xml and presence_mwi modules
XCAP_CLIENT moduleJuly 21, 2008, at 06:04 PM
by
- Changed line 18 from:
to:
July 21, 2008, at 06:03 PM
by
- Changed lines 13-14 from:
to:
Presence Diagrame (click to enlarge) presence scheme? Changed lines 18-22 from:
to:
- **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
- Changed lines 10-11 from:
Architecture to:
ArchitectureChanged lines 14-15 from:
Module Description to:
Module DescriptionChanged line 19 from:
to:
ConfigurationChanged line 23 from:
to:
DatabaseJuly 21, 2008, at 05:56 PM
by
- 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 - July 21, 2008, at 05:52 PM
by
- Changed lines 9-12 from:
to:
Architecture Module Description July 21, 2008, at 05:49 PM
by
- Changed lines 9-10 from:
#Architecture #Module Description to:
July 21, 2008, at 05:49 PM
by
- Changed lines 9-12 from:
to:
#Architecture #Module Description July 21, 2008, at 05:49 PM
by
- Deleted line 10:
July 21, 2008, at 05:48 PM
by
- Changed lines 5-8 from:
to:
Changed lines 10-17 from:
to:
July 21, 2008, at 05:44 PM
by
- Added line 1:
Resources -> Documentation -> Presence -> Presence ServerJuly 21, 2008, at 05:40 PM
by
- Changed lines 1-6 from:
Presence Serverto:
Presence ServerJuly 21, 2008, at 05:39 PM
by
- Added line 1:
Presence Server |