DesignXMPP presence

Version 4 (Saúl Ibarra Corretgé, 05/31/2012 12:20 pm)

1 1 Tijmen de Mes
h1. SIP-XMPP Presence
2 2 Saúl Ibarra Corretgé
3 2 Saúl Ibarra Corretgé
XMPP defines 2 ways for exchanging presence information: simple presence and rich presence.
4 2 Saúl Ibarra Corretgé
5 2 Saúl Ibarra Corretgé
* 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.
6 2 Saúl Ibarra Corretgé
* 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.
7 2 Saúl Ibarra Corretgé
8 2 Saúl Ibarra Corretgé
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.
9 2 Saúl Ibarra Corretgé
10 2 Saúl Ibarra Corretgé
The current implementation acts as a gateway just for XMPP simple presence, support for rich presence will be added at a later stage.
11 2 Saúl Ibarra Corretgé
12 2 Saúl Ibarra Corretgé
The mechanisms described here follow the currently available specifications for SIP-XMPP interoperability:
13 2 Saúl Ibarra Corretgé
14 2 Saúl Ibarra Corretgé
* http://xmpp.org/internet-drafts/attic/draft-saintandre-sip-xmpp-presence-02.html
15 2 Saúl Ibarra Corretgé
16 2 Saúl Ibarra Corretgé
17 2 Saúl Ibarra Corretgé
h3. Model differences
18 2 Saúl Ibarra Corretgé
19 3 Saúl Ibarra Corretgé
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.
20 1 Tijmen de Mes
21 3 Saúl Ibarra Corretgé
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.
22 1 Tijmen de Mes
23 4 Saúl Ibarra Corretgé
XMPP servers maintain one or more TCP connections with other servers in order to exchange stanzas, and any kind of stanza is exchanged over those connections. Because subscriptions are permanent (until explicitly revoked) there is no indication about when a subscription has started and when it ends. SylkServer implements the concept of a 'virtual' subscription, by identifying stanzas and abstracting the model so that it matches the one in SIP.
24 2 Saúl Ibarra Corretgé
25 1 Tijmen de Mes
26 3 Saúl Ibarra Corretgé
h2. SIP-XMPP translation
27 1 Tijmen de Mes
28 3 Saúl Ibarra Corretgé
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.
29 3 Saúl Ibarra Corretgé
30 3 Saúl Ibarra Corretgé
TODO (picture)
31 3 Saúl Ibarra Corretgé
32 3 Saúl Ibarra Corretgé
h3. Overview
33 3 Saúl Ibarra Corretgé
34 3 Saúl Ibarra Corretgé
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.
35 3 Saúl Ibarra Corretgé
36 3 Saúl Ibarra Corretgé
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.
37 3 Saúl Ibarra Corretgé
 
38 3 Saúl Ibarra Corretgé
39 3 Saúl Ibarra Corretgé
h2. XMPP-SIP translation
40 1 Tijmen de Mes
41 4 Saúl Ibarra Corretgé
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.
42 1 Tijmen de Mes
43 4 Saúl Ibarra Corretgé
44 1 Tijmen de Mes
h3. Overview
45 3 Saúl Ibarra Corretgé
46 4 Saúl Ibarra Corretgé
When a _subscribe_ or _probe_ presence stanza is received a 'virtual' XMPP subscription is created and an outgoing SIP subscription is created mirroring the one received on XMPP. SylkServer was designed to work behind a SIP proxy, thus, 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 (because SIP proxies implement a presence agent that will do it). Thus, the translation path for XMPP-->SIP maps a single 'virtual' XMPP subscription to a single SIP subscription.
47 3 Saúl Ibarra Corretgé
48 4 Saúl Ibarra Corretgé
49 1 Tijmen de Mes
h2. Payload translation
50 4 Saúl Ibarra Corretgé
51 4 Saúl Ibarra Corretgé
As mentioned earlier, XMPP and SIP have two completely different formats for conveying presence state. The draft-saintandre-sip-xmpp-presence draft defines a set of rules for translating XMPP stanzas to valid SIP PIDFs, but unfortunately doesn't cover all cases and some adjustments had to be made while implementing the translation mechanism in SylkServer.
52 4 Saúl Ibarra Corretgé
53 4 Saúl Ibarra Corretgé
This section contains a detailed description of the translation process followed by SylkServer. Some extensions to the PIDF have been defined by following the XML schema extension rules, thus interoperability between SIP clients unaware of this extensions hasn't been compromised.
54 4 Saúl Ibarra Corretgé
55 4 Saúl Ibarra Corretgé
56 4 Saúl Ibarra Corretgé
h3. XMPP stanza to PIDF
57 4 Saúl Ibarra Corretgé
58 4 Saúl Ibarra Corretgé
TODO
59 4 Saúl Ibarra Corretgé
60 4 Saúl Ibarra Corretgé
h3. PIDF to XMPP stanza
61 2 Saúl Ibarra Corretgé
62 2 Saúl Ibarra Corretgé
TODO