SER presence handbook (v. Ottendorf.pre1)


Table of Contents

1. Introduction
1.1. Main features
1.2. SER presence basics
2. Installation and running
2.1. Dependencies
2.2. Installation from CVS
2.3. Presence snapshots
2.4. Running SER
2.5. Database initialization
3. Tracing of trouble
3.1. Known problems
3.2. Reporting problems
3.3. New features
3.4. Searching a problem
4. XCAP
4.1. Introduction
4.2. XCAP examples
4.3. XCAP server simulation
5. PA module
5.1. Overview
5.2. Dependencies
5.3. Behaviour
5.4. State aggregation
5.5. XCAP authorization
5.6. Parameters
5.7. Functions
6. RLS (Resource List Server)
6.1. Dependencies
6.2. RLS and XCAP
6.3. Parameters
6.4. Functions
7. Presence B2B UA
7.1. Dependencies
7.2. Usage
7.3. Parameters
7.4. Functions
8. XCAP module
8.1. Parameters
8.2. Functions
9. Examples
9.1. Full presence server
9.2. Presence server with no authorization and without RLS
9.3. Forwarding to presence server
Bibliography
MESSAGE authorization rules
1. Terms
2. Instant message authorization documents
2.1. Conditions
2.2. Actions
2.3. Transformations
3. Example
4. Usage with XCAP
4.1. Naming conventions
Bibliography

1. Introduction

This document describes usage of SIP Express Router as a presence server.

1.1. Main features

  • presence events with XCAP authorization and watcher info support

  • resource list server (only for presence now)

  • B2BUA for presence events (no resource list support now)

  • MESSAGE authorization (via XCAP)

1.2. SER presence basics

Presence is one of quite important components of SER. It allows users to watch presence state of other users, process lists of them and manipulate one's own presence state.

Configuration data can be stored on a XCAP server [xcap] by user's client software and processed by SER. This may be useful for lists of watched users (resource lists) and for authorization rules.

There is a few of modules which serve as parts of "presence":

  • PA acts as a presence server. Its main function is processing of subscriptions to presence state of standalone users and processing presence state publications for them.

  • RLS - Resource list server - this module processes subscriptions to lists of resources. It gets presence information for standalone users from internal queries to PA module or remote presence server queries and build them together into list notifications.

  • PRESENCE_B2B can be used to subscribe to presence state on remote server. It can be used by RLS for remote presence server queries.

  • XCAP offers internal functions for querying XCAP server.

  • DIALOG module is a helper module used by other presence modules for some dialog operations. It was intended to contain dialog management functions but it was not finished.

All “presence” modules share common code stored in SER libraries. Their interface is described in standalone documents.

1.2.1. Persistence

Modules can store their status (working data) into database. This data is automatically reloaded on startup, so it is possible to restart SER and clients don't note it. Established SIP dialogs are stored in database too.

Details about database storage are described for each module separately in module documentation.

1.2.2. Authorization

Authorization is very important in presence services. The server must take care about authorization rules defined by user about whom and whom not allow access to user's presence status. More about authorization rules may be found in [common auth] and [presence auth].

Only XCAP storage of authorization rules is supported at this moment. It is not fully implemented now - only basic rule conditions, no sphere and time conditions. Transformations defined in [presence auth] are ignored. May be, that in the future will be possible to use other variants like webdav or storing authorization rules in SER's own database.