The Flexisip Presence server is a SIP user-agent handling SUBSCRIBE/NOTIFY for the "presence" event.
It implements the following RFCs:

The overall behavior of the presence server is quite simple: it receives SIP SUBSCRIBEs from clients that wish to receive presence information for an individual contact URI, or a list URI that represents a set of SIP contacts.
The presence server processes the target URIs for which presence information is requested, and generates a SIP NOTIFY request back to the clients containing the presence information.
The presence information is obtained from two different sources:
- from PUBLISH requests received by clients, that directly publish their presence information on a regular basis. This presence information is called "short term presence".
- from the authentication database of the flexisip. Because this database contains the list of SIP users that are member of the service, it allows to distribute to clients a long term reachability information about other users. Independently of the whether users are actively using their SIP application, the fact that some SIP users exist or not in the list of users that have registered an account on the SIP service gives a useful indication about their reachability. This presence information is refered as "long term presence".
The two sources are queried in that order: first long term presence, then short term presence. Then a presence PIDF+RPID document describing the results of the two sources is synthesized and send within a SIP NOTIFY.

Operation in GNU/Linux

From a system perspective, the presence server runs as a daemon in its own process, and hence has no adherence on the proxy from an execution standpoint.
It can be started, stopped, restarted using usual systemd commands, for example:

systemctl status flexisip-presence

It can of course be started from a terminal, for example:

/opt/belledonne-communications/bin/flexisip --server presence --debug

The configuration of the presence server is read by default from /etc/flexisip/flexisip.conf, mainly from the [presence-server] section.

The presence server in the SIP network

The presence server itself performs no authentication, no request integrity checking, no DoS protection, which are tasks left to the proxy server. Furthermore, it listens only on SIP/TCP.
It is then recommended to configure the presence server to listen on a private IP address or localhost, so that it cannot be reached directly from the internet.
Instead, all requests shall first go through the flexisip proxy server, that can then forward presence related requests to the the presence server thanks to the Presence module of the proxy.
This module is in charge to recognize presence-related requests and forwards them to the presence server's URI.

Using long-term presence

The long-term presence information is obtained by querying the database setup in the module::Authentication section of flexisip.conf, using the same SQL request as the configured to obtain passwords for a given user.
In addition, the long-term information can be obtained through an alias indirection such as the e164 phone number of users. Indeed, users can typically be invited to register to the SIP service by providing two pieces of informations:
- a username that they choose
- a phone number, usually verified thanks to a short code sent by SMS.
A typical use case for a communication app running on a phone is then to be able from the phone's addressbook to identify phone numbers that are part of the SIP service.
This can be done thanks to the "long term presence" ability to use the alias indirection, according to the following flow:

1. the SIP client sends a SIP SUBSCRIBE with a self-contained ressource list (RFC5367) containing SIP URIs with "phone=" parameter, containing all the phone numbers of the addressbook, for example:


<resource-lists xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:+195XXXXXXXX@sip.linphone.org;user=phone"/>
<entry uri="sip:+332XXXXXXXX@sip.linphone.org;user=phone"/>
<entry uri="sip:+33XXXXXXXXX@sip.linphone.org;user=phone"/>
...
</list>
</resource-lists>

2. The presence server extracts the phone numbers, and queries the authentication database (as setup in module::Authentication) to search for these phone numbers and return the list of SIP users matching these numbers. When the authentication database is configured to use the soci connector, the 'soci-users-with-phones-request' SQL request is executer to obtain such list.

3. the presence server generates and sends a NOTIFY request including a PIDF+RPID body, containing the list of matched phone numbers and their associated SIP URI as a <contact> XML element, as well as the presence their associated presence information. The body is by default compressed to save bandwidth.

Using ressource lists

Despite individual SUBSCRIBEs are supported, they are not an effecient way to obtain other users's presence in a real deployment. Indeed, for each contact in the addressbook for a given user, a SIP SUBSCRIBE will be generated, creating a dialog, and then NOTIFY requests will be received to get the presence of each contact.
For that reason, the use of ressource lists (RFC4662) by clients is highly recommended.

Ressource lists can be of two types in the presence server.

Dynamically client provided resources lists

These are self-contained resource lists as described in RFC5367. This use case is the typical one for a SIP service where users have an addressbook already populated on their phones. Should the local addressbook be updated by the user, a new SUBSCRIBE can be sent to reflect the change. To save bandwidth, the SIP user-agent may compress the SIP body with the standard "deflate" encoding.

Server known resource lists

The SIP user-agent is configured to SUBSCRIBE to a URI identified ressource list, such as "sip:bob-list@company.example.org". The user-agent has no idea about the elements of this list, but the server knows. When receiving such a SUBSCRIBE for URI identified resource list, the presence server can query a SQL database to obtain the list of SIP contacts that are part of the list. Then, presence information (long term, short term) is queried following the same process as for SUBSCRIBE self-contained resource lists.

The 'soci-connection-string' and 'external-list-subscription-request' properties of the [presence-server] section of the configuration define the respectively the database connection and the SQL request to perform to obtain the content of the resource list. Please note that the SIP identity of the subscriber can be passed to the request, which allows to generate per-user content despite the name the SIP URI identifying the list can be the same for all users.

When the SIP client receives the NOTIFY from the server, it can then discover the members of the list, since the NOTIFY contains all the elements of the resource lists, as well as presence documents for contacts for which presence is known.

The server known resource lists are suitable for a SIP service where users don't have a populated addressbook already: for example for employees in a company, so that each employee can have the list of contact information and presence for his/her colleagues.

Confidentiality rules for accessing the presence information

Before a SIP SUBSCRIBE reaches the presence server, it goes through the SIP proxy that can authenticate or reject the request.
However to insure an reasonable protection of user's privacy, the presence server restricts the distribution of presence information to users that both subscribed to each other.
Let's take this concrete example:
A subscribes to B's presence. B does not subscibe to B presence. Then A will receive no information about B's presence.
B decides to subscribe for presence information for A. A and B are then mutually subscribed to each other's presence. The presence server then notifies B's presence to A, as well as A's presence to B.
This rule stands for both long-term and short-term presence.

High availability and scalability

The presence server can be deployed redondantly, for example collocated with a proxy server node, as long as only long-term presence is required for the service.
Indeed, the distribution of short term presence information accross presence server nodes is currently not implemented.

 

Tags: