Published on iptel.org (http://www.iptel.org)

pa

By greger
Created 2007-01-14 14:43

Standard-dep

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.


vaclav.kubart@iptel.org [1]>

Jamey Hicks

Hewlett-Packard Company

Jan Janak

FhG FOKUS

i [4] 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

  • publish [5]])

  • to be done: from reg events subscriptions

  • to be done: from subscriptions to users

  • TODO: cache mode needed by large setups, when the presence status will be in memory only cached, not fully stored (limited size of cache, possibility to switch it off). [status: design in progress, coding will start after Ottendorf will be branched]

    pidf [6]]

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

  • PIDF extensions (like RPID [rpid [7]])

  • Supported document formats in NOTIFY:

    • PIDF - see [pidf [8]]

    • 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)

    • PIDF extensions (like RPID [rpid [9]])

    i [10]

  • usrloc

  • optionaly database module (mysql, ...)

  • optionaly xcap module for XCAP authorization

  • Libraries

    • libxml2 - external library for parsing XML documents

    • libcds (internal)

    • libxcap (internal) - XCAP queries (authorization)

    • libpresence (internal) - used for internal subscriptions from RLS

    i [11] (see Sip-If-Match and SIP-ETag header fields).

    PA understoods only basic PIDF, but it can handle PIDF extensions like RPID too. PIDF extensions are hold as whole XML elements without knowing about their definition and thus publishing client is responsible for correct content of them. PA ignores "mustUnderstand" attribute (see [pidf [12]]). [Are there any problems with it?]

    You can control this source by PUBLISH request handling in config script (function handle_publish).

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

    i [14]

    Authorization documents are read for presentities according to their presentity URIs (presentity URI is URI in To header of SUBSCRIBE request). Resulting XCAP URI with authorization document is:

    <xcap-root>/pres-rules/users/<username>/presence-rules.xml,

    where <xcap-root> is set in configuration of XCAP module and <username> is UUID (unique user identification used in SERi [15] everywhere) discovered from presentity URI.

    If you need to use other filename than default “presence-rules.xml”, you can redefine it by parameter pres_rules_file. Problem can be, that pres_rules_file is specified as module parameter and thus common for all users.

    MESSAGE authorization rules [16]. We ignore sphere, transformations and date and time conditions like in the case of presence authorization.

    xcap_diff [17]] and [xcap_profiles [18]] (planned in future versions).

    i [19]: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.

    Warning

    Internal subscriptions are not handled in configuration script thus they use default values of parameters (like XCAP root settings for authorization, ...)

    presence auth [20]]. In this case the xcap module must be loaded.

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

    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

    pres_rules_file

    Name of the file with presence rules on XCAP server. The filename is by default “presence-rules.xml”. It is common for all subscriptions/users which seems to be insufficient. It will be replaced by holding this information for each user separately in user attributes (TODO).

    ignore_408_on_notify

    If set to 1 the 408 response to NOTIFY is ignored, otherwise all 4xx responses including 408 destroys the subscription.

    Reason for this parameter is that some clients are not able to process two NOTIFY requests received shortly in sequence and unresponded NOTIFY resulting in generated 408 response destroyed subscription created by them.

    Default value is 0.

    timer_interval

    Interval in seconds when the timer runs and clears expired watchers/tuples and send NOTIFYs for changed presentities.

    default_priority_percentage

    Priority value used for tuples created by registration in percents. Default value is 0.

    auth_rules_refresh_time

    Time interval specifying amount of time between re-reading of authorization documents stored on XCAP server. In other words it means the time interval of subscription reauthorization.

    Default value is 300.

    async_auth_queries

    Set to 1 if you want to use asynchronous XCAP queries (recommended), 0 otherwise.

    Default value is 0.

    max_auth_requests_per_tick

    Maximum number of asynchronous XCAP requests done at once (within one second).

    Default value is 600.

    watcherinfo_notify parameter [21]) events.

    Meaning of the parameters is as follows:

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

    MESSAGE authorization rules [22].

    Filename parameter specifies the name of file on XCAP server which contains message authorization rules. It is “im-rules.xml” by default.

    presentity [23]

    Table holding presentities for PA module. It is basic PA table, most of other PA tables are related to this one.

    presentity_notes [24]

    Table holding <note> elements published directly in <presence> element i.e. notes related to whole presentity not only for tuples.

    presentity_extensions [25]

    Table holding extension elements (non-PIDF) published directly in <presence>.

    presentity_contact [26]

    Table holding published tuples (NOT tuples generated by registrations).

    watcherinfo [27]

    Table holding information about watchers. Here are both presence and presence.winfo watchers.

    tuple_notes [28]

    Tuple related published notes.

    tuple_extensions [29]

    Extension elements published within tuples.

    offline_winfo [30]

    Table used to store information about subscriptions to "offline presentities". Data here can be manipulated using functions store_winfo and dump_stored_winfo.

    IETF [31] by name.

    XCAP

    draft-ietf-simple-xcap-07.txt [32] - XCAP specification.

    draft-ietf-simple-xcap-diff-01.txt [33] - XCAP changes notifications format.

    draft-ietf-sipping-config-framework-07.txt [34] -XCAP user profiles.

    Presence

    RFC 3265 - SIP Events [35].

    RFC 3856 - Presence Event package [36].

    RFC 3863 - Presence Information Data Format [37].

    RFC 4480 - Rich Presence Extensions to the Presence Information Data Format [38].

    RFC 3903 - Event state publication [39].

    RFC 3857 - Watcher info event package [40].

    RFC 3858 - Data Format for watcher info [41].

    [reg] RFC 3680 - SIP Reg Events [42].

    Authorization

    draft-ietf-geopriv-common-policy-05.txt [43].

    draft-ietf-simple-presence-rules-03.txt [44] - presence authorization XML based data format and usage with XCAP.

    Resource lists

    draft-ietf-simple-xcap-list-usage-05.txt [45] - XML formats for representing resource lists.

    draft-ietf-simple-event-list-07.txt [46] - Event Notification Extension for Resource Lists.