DesignXMPP presence

Version 44 (Adrian Georgescu, 05/31/2012 05:18 pm)

1 1 Tijmen de Mes
h1. SIP-XMPP Presence
2 2 Saúl Ibarra Corretgé
3 11 Adrian Georgescu
The mechanisms described here follows the currently available specifications for SIP-XMPP interoperability:
4 11 Adrian Georgescu
5 11 Adrian Georgescu
* http://xmpp.org/internet-drafts/attic/draft-saintandre-sip-xmpp-presence-02.html
6 11 Adrian Georgescu
7 34 Adrian Georgescu
h2. SIP presence
8 34 Adrian Georgescu
9 34 Adrian Georgescu
SIP protocol defines a single framework for presence ("SIMPLE":http://datatracker.ietf.org/wg/simple/charter/) and then multiple extensions have been published which extend the information that can be conveyed in the payload.
10 34 Adrian Georgescu
11 36 Adrian Georgescu
The client is responsible for starting and maintaing subscriptions dialogs as described in "RFC 3265":http://tools.ietf.org/html/rfc5627 by using SUBSCRIBE method.  Subscriptions are temporary, so the client needs to take care of refreshing them when they expires. As a result of a SUBSCRIBE, subsequent NOTIFY messages are received back as part of the same dialog.
12 36 Adrian Georgescu
13 34 Adrian Georgescu
h2. XMPP presence
14 34 Adrian Georgescu
15 38 Adrian Georgescu
XMPP defines two ways for exchanging presence information: simple presence and rich presence.
16 2 Saúl Ibarra Corretgé
17 38 Adrian Georgescu
* 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.
18 38 Adrian Georgescu
* 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.
19 38 Adrian Georgescu
20 40 Adrian Georgescu
In XMPP protocol, the client doesn't create directly 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 back to the clients that requested it. This subscriptions last for as long as a user has a contact in his roster, they don't need to be explicitely refreshed.
21 40 Adrian Georgescu
22 42 Adrian Georgescu
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. Subscriptions are permanent (until explicitly revoked).
23 1 Tijmen de Mes
24 42 Adrian Georgescu
h2. Subscription model
25 1 Tijmen de Mes
26 42 Adrian Georgescu
SylkServer implements the concept of a 'virtual' subscription, by identifying stanzas and abstracting the model so that it matches the one in SIP. The current SylkServer implementation acts as a gateway for XMPP simple presence, support for rich presence will be added at a later stage.
27 1 Tijmen de Mes
28 27 Adrian Georgescu
h2. SIP-XMPP presence translation
29 1 Tijmen de Mes
30 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.
31 3 Saúl Ibarra Corretgé
32 17 Saúl Ibarra Corretgé
!{ 700px, center}xmppgw_presence_s2x.png!
33 3 Saúl Ibarra Corretgé
34 31 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 27 Adrian Georgescu
h2. XMPP-SIP presence translation
39 1 Tijmen de Mes
40 30 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.
41 1 Tijmen de Mes
42 17 Saúl Ibarra Corretgé
!{ 700px, center}xmppgw_presence_x2s.png!
43 4 Saúl Ibarra Corretgé
44 32 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.
45 3 Saúl Ibarra Corretgé
46 1 Tijmen de Mes
h2. Payload translation
47 4 Saúl Ibarra Corretgé
48 24 Adrian Georgescu
As mentioned earlier, XMPP and SIP have two completely different formats for conveying presence state. The "draft-saintandre-sip-xmpp-presence":http://xmpp.org/internet-drafts/attic/draft-saintandre-sip-xmpp-presence-02.html 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.
49 4 Saúl Ibarra Corretgé
50 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.
51 4 Saúl Ibarra Corretgé
52 6 Saúl Ibarra Corretgé
h4. Status
53 6 Saúl Ibarra Corretgé
54 6 Saúl Ibarra Corretgé
In XMPP the availability of a given device is either 'available' or 'unavailable' and the _show_ element gives some extra information about it: free for chat, do not disturb, away or extended away. There is no way to map this information to PIDF, unfortunately. PIDF defines the _person_ element and RPID extends it to add activities, but there can only be a single person element per PIDF, so it can't be used as multiple XMPP stanzas need to be aggregated in a single PIDF document.
55 1 Tijmen de Mes
56 23 Adrian Georgescu
"SIP SIMPLE Client SDK":http://sipsimpleclient.com used by SylkServer implements an extension to "PIDF":http://sipsimpleclient.com/projects/sipsimpleclient/repository/entry/sipsimple/payloads/pidf.py which adds the _extended_ child element with the following allowed values: available, offline, away, extended-away and busy. Here is an example of the status element with both _basic_ and _extended_ elements:
57 6 Saúl Ibarra Corretgé
58 6 Saúl Ibarra Corretgé
<pre>
59 6 Saúl Ibarra Corretgé
    <tuple id='id1234'>
60 6 Saúl Ibarra Corretgé
        <status>
61 6 Saúl Ibarra Corretgé
            <basic>open</basic>
62 6 Saúl Ibarra Corretgé
            <extended>away</extended>
63 6 Saúl Ibarra Corretgé
        </status>
64 1 Tijmen de Mes
    </tuple>
65 1 Tijmen de Mes
</pre>
66 7 Saúl Ibarra Corretgé
67 7 Saúl Ibarra Corretgé
The new _extended_ element is used to translate the _show_ element from XMPP.
68 7 Saúl Ibarra Corretgé
69 7 Saúl Ibarra Corretgé
To avoid losing information a Person element is also created with the combined activities from all stanzas. Since only a single Person element makes sense in the PIDF document, the ID of the person is set to the MD5sum of the AoR (that is, user@domain) so that elements aggregating PIDF documents will find conflicting elements (ID can't be duplicated) and leave a single Person element.
70 7 Saúl Ibarra Corretgé
71 7 Saúl Ibarra Corretgé
h4. Resource and URI
72 7 Saúl Ibarra Corretgé
73 43 Saúl Ibarra Corretgé
According to the "draft":http://xmpp.org/internet-drafts/attic/draft-saintandre-sip-xmpp-presence-02.html the XMPP resource should be used as the PIDF tuple ID. Unfortunately, since the resource can contain arbitrary unicode characters it will need to be encoded. The chosen mechanism is to encode the unicode resource in UTF8 and then hex encode it. The result is prefixed with "ID-" in order to comply with the rules of the XML xs:ID element. Example translation of a resource called "my computer":
74 1 Tijmen de Mes
75 43 Saúl Ibarra Corretgé
<pre>
76 43 Saúl Ibarra Corretgé
    ID-6d7920636f6d7075746572
77 43 Saúl Ibarra Corretgé
</pre>
78 43 Saúl Ibarra Corretgé
79 43 Saúl Ibarra Corretgé
In a similar manner, when building the Contact element of the PIDF, the XMPP JID will be converted to a SIP URI by encoding the resource as mentioned above and using it as the GRUU. Example URI translating _saul@ag-projects.com/my computer_:
80 43 Saúl Ibarra Corretgé
81 43 Saúl Ibarra Corretgé
<pre>
82 43 Saúl Ibarra Corretgé
    sip:saul@ag-projects.com;gr=6d7920636f6d7075746572
83 43 Saúl Ibarra Corretgé
</pre>
84 7 Saúl Ibarra Corretgé
85 7 Saúl Ibarra Corretgé
h4. Device information
86 7 Saúl Ibarra Corretgé
87 7 Saúl Ibarra Corretgé
PIDF defines a _device_ element which should contain information about the physical device. This information needs to be linked with the _tuple_ element of the PIDF by way of the _deviceid_ element. More than one _deviceid_ elements are allowed in a _tuple_.
88 7 Saúl Ibarra Corretgé
89 44 Adrian Georgescu
In order to make it simpler to identify the device the _device-info_ extension was added to "SIP SIMPLE Client SDK":http://sipsimpleclient.com/projects/sipsimpleclient/repository/entry/sipsimple/payloads/pidf.py, which can only be present once. The _device-info_ element contains the device ID (encoded resource) and a description:
90 7 Saúl Ibarra Corretgé
91 7 Saúl Ibarra Corretgé
<pre>
92 7 Saúl Ibarra Corretgé
    <device-info id="ID-6d61696e20636f6d7075746572" description="main computer"/>
93 7 Saúl Ibarra Corretgé
</pre>
94 7 Saúl Ibarra Corretgé
95 7 Saúl Ibarra Corretgé
h4. Notes
96 7 Saúl Ibarra Corretgé
97 7 Saúl Ibarra Corretgé
Status notes are translated directly as the meaning maps one-to-one and added as notes in the _tuple_ element.