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
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
Supported document formats in PUBLISH:
Supported document formats in NOTIFY:
Modules
tm
dialog
usrloc
optionaly database module (mysql, ...)
Libraries
libxml2 - external library for parsing XML documents
libcds (internal)
libxcap (internal) - XCAP queries (authorization)
libpresence (internal) - used for internal subscriptions from RLS
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>
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.
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>
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.
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).
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.
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:
All watchers are always authorized. This is not recommended because it ignores user's wish.
All watchers are always pending. This is not recommended because it means, that no presence data is sent to all watchers.
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.
winfo_auth (string)This variable specifies authorization type for watcher info watchers (event package is “presence.winfo”). Value can be one of:
All watcher info watchers are always authorized. This is not recommended.
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”
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".
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.