# Introduction

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

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

## SIP-router presence basics

Presence is one of quite important components of SIP-router. 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 pres_rfc_xcap by user's client software and processed by SIP-router. 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 SIP-router libraries. Their interface is described in standalone documents.

### Persistence

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

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

### 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 pres_draft_common_auth and pres_draft_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 pres_draft_auth are ignored. Maybe, in the future it will be possible to use other variants like webdav or storing authorization rules in SIP-router's own database.