SylkServer

h1. SIP-XMPP Presence

XMPP defines 2 ways for exchanging presence information: simple presence and rich presence.

* Simple presence: The _presence_ stanza is used and it conveys basic information about the user's availability, such as the status, availability note and a timestamp indicating the last time it was seen.

* Rich presence: _IQ_ stanzas are used and it enhances the simple presence by adding information such as the user avatar, music the user is listening to, etc.

SIP, on the contrary, defines a single framework for presence (SIMPLE) and then multiple extensions have been published which extend the information that can be conveyed in the payload.

The current implementation acts as a gateway just for XMPP simple presence, support for rich presence will be added at a later stage.

The mechanisms described here follow the currently available specifications for SIP-XMPP interoperability:

* http://xmpp.org/internet-drafts/attic/draft-saintandre-sip-xmpp-presence-02.html

h3. Model differences

In XMPP the client doesn't initiate a subscription, the server does so on his behalf, by sending a presence stanza of type _probe_ to each of the contacts in his roster. Then each contact will send his presence state and the server will dispatch it. This subscriptions last for as long as a user has a contact in his roster, they don't need to be refreshed.

In SIP, on the other hand, the client is responsible for starting and maintaing subscriptions. Subscriptions are timed, so the client needs to take care of refreshing the subscription when/if it expires.

h2. SIP-XMPP translation

When a SIP SUBSCRIBE needs to be translated to XMPP a presence stanza of type _subscribe_ will be sent. This is only necessary the first tine a user is subscribed, but this can't be known in advance. Just in case the XMPP server disregards the stanza another presence stanza is sent, this time of type _probe_ in order to instruct the remote XMPP server that it should deliver the last known presence state for the requested user.

TODO (picture)

h3. Overview

When a SIP SUBSCRIBE is received a 'virtual' XMPP subscription is created between the bare SIP URI and bare XMPP JID. If another SIP client (with the same SIP account) sends a SUBSCRIBE for the same user, the subscription is added to a list of SIP subscriptions for this translation path (SIP user --> XMPP user). That is, there might be multiple SIP subscriptions matching a single XMPP subscription.

When a XMPP presence stanza is received it will be converted to a SIP PIDF following the mechanism defined in the *Payload translation* section and sent as an in-dialog NOTIFY request over each of the SIP subscriptions.

h2. XMPP-SIP translation

As mentioned before, in XMPP a user only subscribes to another user once, after that his server will send a _probe_stanza every time it needs to know the presence state of any contact. When either a _subscribe_ or _probe_ presence stanzas are received over XMPP, SylkServer will create a SIP subscription (if none was found). SylkServer was designed to work behind a SIP proxy, and because SIP proxies implement a presence agent, SylkServer doesn't need to send multiple SIP SUBSCRIBE requests to get the state of the user across multiple devices, the server will aggregate that information. Thus, the translation path for XMPP-->SIP maps a single 'virtual' XMPP subscription to a single SIP subscription.

h3. Overview

TODO

h2. Payload translation

TODO