This module implements a presence server, i.e. entity that receives SUBSCRIBE requests and sends NOTIFY when presence status of a user changes and allows user to use PUBLISH request for publishing presence status information.

4.1.1. Features

  • handle SUBSCRIBE requests

  • handle PUBLISH requests

  • XCAP authorization of subscriptions

  • failover - all subscription's data including SIP dialogs can be stored into database and reloaded on startup

  • offline watcher info - watchers can be stored into database when presentity is offline and sent in watcher info notification when presentity subscribes to its watcherinfo again

4.1.2. Presence status

User's presence status is hold internaly; it can be taken from:

  • registrar - online/offline information with contact

  • published information by user (see [publish])

  • to be done: from reg events subscriptions

  • to be done: from subscriptions to users

4.1.3. Supported document formats

Supported document formats in PUBLISH:

  • PIDF - see [pidf]

  • CPIM-PIDF (last version which differs from PIDF only in namespaces and MIME type name)

  • RPID - only <person> elements - see [rpid]

Supported document formats in NOTIFY:

  • PIDF - see [pidf]

  • CPIM-PIDF (last version which differs from PIDF only in namespaces and MIME type name)

  • LPIDF

  • XPIDF (MS variant used by Windows Messenger 4.7)

  • RPID - only <person> elements - see [rpid]

4.2. Dependencies

Modules

Libraries

4.3. XCAP authorization

4.3.1. Presence authorization documents

Presence authorization documents are described in [presence auth] and they are not fully supported now. We ignore sphere, transformations and date and time conditions. [Are there any clients supporting this?].

Example 7. presence authorization document

This document has two rules: one named “blacklist” disabling subscriptions from user “smith” and one named “whitelist” enabling subscriptions from all other users from domain “test-domain.com”. (It doesn't depend on names of rules but on actions for them.)

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy" 
		xmlns:pr="urn:ietf:params:xml:ns:pres-rules">
	<rule id="blacklist">
		<conditions>
			<identity>
				<id>sip:smith@test-domain.com</id>
			</identity>
		</conditions>
		<actions>
			<pr:sub-handling>block</pr:sub-handling>
		</actions>
		<transformations/>
	</rule>
	
	<rule id="whitelist">
		<conditions>
			<identity>
				<domain domain="test-domain.com"/>
				<except entity="smith"/>
			</identity>
		</conditions>
		<actions>
			<pr:sub-handling>allow</pr:sub-handling>
		</actions>
		<transformations/>
	</rule>
</ruleset>

4.3.2. Presence authorization document URI

Authorization documents are read for presentities according to their presentity URIs. Presentity URI is AOR of SUBSCRIBE request. Resulting URI will be:

<xcap-root>/pres-rules/users/<username>/presence-rules.xml where <xcap-root> is set in configuration and <username> is UUID (unique user identification used in SER everywhere) discovered from presentity URI.

Example 8. presence authorization document uri

For example for presentity sip:joe@iptel.org with UUID “joe” and xcap-root http://localhost/xcap-root will be the URI for the authorization document http://localhost/xcap-root/pres-rules/users/joe/presence-rules.xml

4.3.3. Message authorization documents

Message authorization documents are described in MESSAGE authorization rules. We ignore sphere, transformations and date and time conditions like in the case of presence authorization.

Example 9. message authorization document

This document has one rule named “blacklist” disabling messages sent from users “jan@test-domain.com” and “jana@test-domain.com”.

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy" xmlns:im="urn:iptel:xml:ns:im-rules">
	<rule id="blacklist">
		<conditions>
			<identity>
				<id>sip:jana@test-domain.com</id>
				<id>sip:jan@test-domain.com</id>
			</identity>
		</conditions>
		<actions>
			<im:im-handling>block</im:im-handling>
		</actions>
		<transformations/>
	</rule>
</ruleset>

4.3.4. Message authorization document URI

Authorization documents are read for recipients according to To URIs. Resulting URI for XCAP will be:

<xcap-root>/im-rules/users/<username>/im-rules.xml where <xcap-root> is set in configuration and <username> is UUID discovered from To URI.

Example 10. message authorization document uri

For example for recipient sip:smith@iptel.org with UUID “smith” and xcap-root http://localhost/xcap-root will be the URI for the authorization document http://localhost/xcap-root/im-rules/users/smith/im-rules.xml

4.3.5. Disadvantages

One of the worst disadvantages of XCAP authorization is slowness of XCAP queries compared to - for example - data stored in local database. This is the reason for caching XCAP queries and responses, but there is a problem - how to detect changes in data stored on XCAP server. One of possible solutions is to implement client for “XCAP change notifications” described in [xcap_diff] and [xcap_profiles] (planned in future versions).

4.3.6. Standard incompliances

XCAP authorization support is not finished yet, there are some standard incompliances now:

  • ignored sphere

  • ignored date and time conditions

  • ignored transformations

4.4. Parameters

default_expires (integer)

Default expiration value to be used when the client doesn't supply one (in seconds). It is used for both subscriptions and publications.

Default value is 3600.

max_subscription_expiration (integer)

Maximal subscription expiration value in seconds.

Default value is 3600.

max_publish_expiration (integer)

Maximal expiration of presence status information published via PUBLISH in seconds.

Default value is 3600.

use_db (integer)

If set to 1, PA module stores all subscription data into database and reloads them on startup. Requires db_url to be set.

Default value is 1.

db_url (integer)

Database connection URL. It has to be specified if use_db or use_offline_winfo is set.

Default value is empty.

Example 11. db_url settings

...
modparam("pa", "use_db", 1)
modparam("pa", "db_url", "mysql://ser:heslo@127.0.0.1:3306/ser")
...
use_callbacks (integer)

If set to 1 callbacks to registrar/jabber will be used, if set to 0 callbacks will not be used, thus it will work only with published information.

Default value is 1.

accept_internal_subscriptions (integer)

If set to 1 PA module will accept internal subscriptions via Querry Status API otherwise not. Set this to 1 if you want RLS module to be using internal subscriptions to PA. You can't use presence B2B UA in this case!

Default value is 0.

watcherinfo_notify (integer)

Set this to 1 if you want to enable subscriptions to "presence.winfo" events. If set to 0, watcherinfo subscriptions are denied.

Default value is 1.

use_offline_winfo (integer)

Set this to 1 if you want to use offline watcher info notifications. In such case can be watcher information stored in database and later dumped to presentity in watcher info notification, requires db_url to be set. See functions for example.

Default value is 0.

offline_winfo_expiration (integer)

Expiration time of stored "offline watcher information" in seconds. After this time is the information removed from database.

Default value is 259200.

offline_winfo_timer (integer)

Number of seconds after which is triggered automatic cleanup of expired offline watcherinfo.

Default value is 3600.

auth (string)

This variable specifies authorization type for presence watchers (event package is “presence”). Value can be one of:

none

All watchers are always authorized. This is not recommended because it ignores user's wish.

implicit

All watchers are always pending. This is not recommended because it means, that no presence data is sent to all watchers.

xcap

This type of authorization means, that authorization rules are read from XCAP server and processed [presence auth]. In this case the auth_xcap_root must be set.

Default value is empty. In this case “implict” authorization is used with an error message.

auth_xcap_root (string)

This parameter holds value of XCAP root URI used for reading authorization rules. Value must be set to nonempty value if “xcap” authorization is used.

Authorization document is loaded using HTTP GET method from URI composed from auth_xcap_root and user's name as follows: auth_xcap_root/pres-rules/users/username/presence-rules.xml.

Example 12. XCAP authorization settings

...
modparam("pa", "auth", "xcap")
modparam("pa", "auth_xcap_root", "http://localhost/xcap-root")
...
		

Settings above will result for presentity “smith@iptel.org” in authorization queries to http://localhost/xcap-root/pres-rules/users/smith/presence-rules.xml.

winfo_auth (string)

This variable specifies authorization type for watcher info watchers (event package is “presence.winfo”). Value can be one of:

none

All watcher info watchers are always authorized. This is not recommended.

implicit

This value means, that presentity can subscribe to its own watcher info data and nobody else. This is done via comparing watcher's and presentity's uri. If these values equals, the subscription is allowed. In other cases is the subscription rejected.

Default value is “implict

4.5. Functions

handle_subscription(domain)

This function processes SUBSCRIBE requests to "presence" and "presence.winfo" (see watcherinfo_notify parameter) events. It sets AVP named “subscription_status” according to status assigned by authorization (“active”, “pending”, “terminated”) or “error” if an error occurs.

Meaning of the parameters is as follows:

  • domain - This can be either "registrar" or "jabber".

Example 13. handle_subscription usage

...
handle_subscription("registrar");
...
			
target_online(domain)

This function returns 1 if the target (using get_to_uid on current message) is online, -1 otherwise.

store_winfo(domain)

This function stores data about currently created subscription into database for later dumping in the form of watcherinfo notification. It should be called after handle_subscription during processing SUBSCRIBE request. As subscription status is stored value taken from AVP “subscription_status”.

dump_stored_winfo(domain, event_package)

This function tries to send stored watcherinfo data in in the context of existing watcherinfo subscription. It uses get_to_uid as target for notification. If there is no watcherinfo subscription to such presentity, no information is sent.

If the client responds with 2xx on generated NOTIFY request, the stored information is removed from database.

Example 14. target_online, store_winfo, dump_stored_winfo usage

...
if (method=="SUBSCRIBE") {
	if (!t_newtran()) {
		sl_reply_error();
		break;
	};
	
	if (handle_subscription("registrar")) {; # uses uid from AVP (get_to_uid)
		if (@msg.event=~"presence\.winfo") {
			log(1, "subscription to watcherinfo\n");
			dump_stored_winfo("registrar", "presence");
			log(1, "OFFLINE AUTH: watcherinfo dumped\n");
		}
		else {
			if ((@msg.event=~"presence") && (%subscription_status=="pending")) {
				log(1, "pending subscription to presence\n");
				# if offline user and new "pending" subscription
				if (!target_online("registrar") && (@to.tag=="")) {
					log(1, "OFFLINE AUTH: storing for offline user\n");
					store_winfo("registrar");
				}
			}
		}
	}
	break;
};
...
authorize_message(xcap_root)

This function reads and processes IM authorization data and returns 1 if message can be accepted by destination user. If there is no IM authorization document on given XCAP server, it returns 1 too (MESSAGE is enabled by default). If the sender is blocked by recipient rules, this function returns -1. For more details about authorization documents see MESSAGE authorization rules.

Example 15. authorize_message usage

...
if (method=="MESSAGE") {
	if (authorize_message("http://localhost/xcap")) {
		if (!lookup("location")) {
			sl_reply("404", "Not Found");
			break;
		};
		if (!t_relay()) { sl_reply_error(); };
	}
	else {
		sl_reply("403", "Forbidden");
	}
	break;
}
...
Home |  Recent changes |  Search |  Glossary |  Sitemap |  Login