Presence
Version 59 (Adrian Georgescu, 02/20/2013 12:04 pm) → Version 60/63 (Adrian Georgescu, 02/20/2013 12:05 pm)
h1. Presence
Presence This functionality is available starting with "Blink Pro":http://itunes.apple.com/us/app/blink-pro/id404360415?mt=12&ls=1 2.0.2 and "Blink Lite":https://itunes.apple.com/us/app/blink-pro/id431473881?mt=12&ls=1 2.0.2 for MacOSX and is scheduled for Blink-Qt for Windows and Linux future releases.
h2. Live Service
Presence is a complex issue and the mechanisms used internally by Blink may not necessarily work with your own SIP server. If you want to troubleshot when things do not work as expected, first use the built-in Blink accounts provided by http://SIP2SIP.info that is known to be working to work with Blink.
h2. Server Compatibility Cocoa 2.1.0.
Presence is a complex issue and the mechanisms used internally by Blink may not necessarily work under any SIP server environment. This document was written to provide a better understanding of these mechanisms. Presence require proper infrastructure that many SIP service providers simply lack today, so do not complain to us when Presence does not work with your SIP service provider.
OpenSIPS 1.9.0 and OpenXCAP 2.1.0 server software has been tested and is 100% compatible with Blink:
h2. Design Principles
Blink should work with any SIP and XCAP servers that supports all related SIP SIMPLE standards, but only a subset of them are being used. They are described below:
* Blink uses only TCP or TLS transports for signaling
* Blink presence payload is based on "RPID schema":http://tools.ietf.org/html/rfc4480 with its extensions for "media capabilities":http://tools.ietf.org/html/rfc5196 and "person information":http://tools.ietf.org/html/rfc4480
* Blink relies on a Presence Agent collocated with the SIP Registrar that supports PUBLISH method, RLS subscriptions method and XCAP storage
* Blink uses only TCP or TLS transports for signaling, Presence Agent must use TCP/TLS
* Presence Agent must support RLS subscriptions and "RLMI notifications":http://tools.ietf.org/html/rfc4662
* Presence Agent must support handling of presence rules using org.openmobilealliance.pres-rules XCAP document
* Presence Agent must support external references from rls-services to resource-lists XCAP documents
* Presence Agent must support external references from rls-services to org.openmobilealliance.pres-rules XCAP document
* Presence Agent must support presence and presence.winfo event packages
* Presence Agent may support xcap-diff event package for XCAP documents replication between clients
* Presence Agent must support RLS subscriptions and "RLMI notifications":http://tools.ietf.org/html/rfc4662
* SIP Registrar may support GRUU
* XCAP server must support rls-services, resource-lists, xcap-caps, org.openmobilealliance.pres-content, org.openmobilealliance.pres-rules, org.openmobilealliance.xcap-directory
* XCAP server may support serving the user icon from org.openmobilealliance.pres-content document
* XCAP server must support the following XCAP applications: rls-services, resource-lists, xcap-caps, org.openmobilealliance.pres-content, org.openmobilealliance.pres-rules, org.openmobilealliance.xcap-directory
* XCAP server may support pidf-manipulation for offline status
h3. Standards
Blink presence payload is based on "RPID schema":http://tools.ietf.org/html/rfc4480 with its extensions for "media capabilities":http://tools.ietf.org/html/rfc5196 and "person information":http://tools.ietf.org/html/rfc4480 http://sipsimpleclient.org/projects/sipsimpleclient/wiki/SipFeatures#Presence
In the GUI, presence has been indicated as 'Availability'.
h3. Standards Disclaimer
Blink presence functionality should interoperate without any issues with any other SIP client or SIP server implementing presence as far as the SIP signaling There is concerned (PUBLISH, SUBSCRIBE and NOTFY methods). no guaranty Blink Presence functionality would however not interoperate for contacts storage level with other SIP clients under the same account due to the freedom allowed by the standards in modeling the data used for contacts storage.
h3. Interoperability
Presence is a complex issue and the mechanisms used internally by Blink may not necessarily work under your own server environment. If you want to troubleshot when things do not work as expected, first use the built-in Blink accounts that are designed to work with SIP2SIP domain. As protocol traces for signaling and storage are logged to file, you can easily access such debug information and analyze Blink behavior.
We can provide support, if you encounter interoperability issues with any the following products and services against which Blink has been fully tested:
* SIP2SIP.info (a public free SIP service)
* Interoperability with XMPP domains (using SylkServer SIP/XMPP gateway)
* OpenSIPS/OpenXCAP combination (server software you can run on your premisses)
There is nothing that should prevent Blink interoperate with any other SIP end-points as far as SIP signaling is concerned (PUBLISH, SUBSCRIBE and NOTIFY methods). Blink will preserve contacts related information that it did not create itself in XCAP documents. Unfortunately, we have not found other clients that behave in the same way. Sharing the same XCAP documents with other SIP clients is therefore strongly discouraged. discouraged as is guaranteed to cause failures.
"List of implemented standards":http://sipsimpleclient.org/projects/sipsimpleclient/wiki/SipFeatures#Presence You can also enable one SIP2SIP account in your Blink instance to perform presence and contact storage operations while using your preferred SIP provider to make phone calls.
h3. Support
As presence require proper infrastructure that many SIP service providers simply lack today, do not complain to us when Presence does not work with your SIP service provider.
h2. Contacts Storage
Contacts are stored on the XCAP server in the [[XCAP-samples#Resource-lists|resource-lists]] resource-lists document under a proprietary name space to avoid conflicts with other end-points that might use the same document as there is no common standard way for how to store a rich address book on a server. This means that different SIP user agents from different vendors cannot read or modify this data in a deterministic way. The contacts in the address-book document are then used by [[XCAP-samples#RLS-services|rls-services]] standard OMA rls-services and [[XCAP-samples#Presence-rules|pres-rules]] pres-rules XCAP documents standardized by OMA. Each contacts documents. Contacts have two presence Presence related properties that can changed in Edit Contact Panel Subscriptions section:
* Subscribe to Contact's Availability Presence Information
* Allow Contact to see my Availability Presence Information
* If a SIP an URI part of the Contact contact is labelled as XMPP, when using a SIP2SIP.info account, new account the session requests request will be automatically forwarded to the an XMPP domain using the built-in SIP to XMPP gateway provided by SIP2SIP service. gateway.
h3. Subscribe To Presence
Using SIP SUBSCRIBE for RLS, Bink subscribes to the SIP addresses stored in rls-services document uploaded on the XCAP server by contacts management actions in the GUI (add/update/delete contacts).
h2. Policy Management Watcher Information
Policy is used to express user preference about whether somebody that subscribed to our presence information is entitled to receive such information or not.
Using SUBSCRIBE for presence.winfo event package, Blink keeps track of presence watchers subscribed to our presence. and their status.
* New watchers Contacts that have subscribed to our presence are rendered in the 'New Contact Requests' group that is rendered on top of the contacts list
* list. Right clicking on a new request entry, provides a contextual menu to block click or add dragging the contacts contact can be used to allow or deny the contacts list
* Dragging the request entry to an existing contact will merge the address of the request entry with the destination contact
* request. Blocked contacts are displayed in the Blocked group group.
* Active watchers are shown in system menu Blink Status -> Subscribers for People Watching My Availability Presence Activity menu
h2. Published Presence
Blink user can publish a status and a note. Sometimes, Blink itself can change the status automatically, in situations when we do not perform any computer activity for a longer period or we start a phone call.
Presence status can be changed manually from the main GUI window and Status menu. Last combination of Presence state and note are saved in the history build at the end of the menu.
Status and note are automatically synchronized between multiple Blink instances under the same account.
Using PUBLISH method for the presence event package, the following information is published in a [[XCAP-samples#PIDF|PIDF]] document by Blink:
*
h3. Basic Status: Status
Open or closed
* closed.
h3. Extended Status: Status
Blink uses a proprietary extension for indicating the extented status compatible with XMPP end-points
* Location: end-points.
h3. Location
Location is based on CIPID map extension. Location can be disabled per account in Presence section of account preferences. Location is available only for accounts provided by sip2sip.info account. The format is a string Country/City.
* Homepage:
h3. Homepage
A home page can be entered in Presence section of account preferences. Homepage is based on CIPID homepage extension
* Note: extension.
h3. Note
Presence note can be typed in the text area right to own icon in the main GUI window. Note is attached to the service
* Icon: service.
h3. Status
Presence status can be changed from the main GUI window and Status menu. Last combination of Presence state and note are saved in the history build at the end of the menu.
h3. Icon
User own icon is uploaded to XCAP server using OMA pres-content application, replicated among multiple Blink instances and location of icon icons storage URL on XCAP server is published in the PIDF
* PIDF.
h3. Offline Presence: Presence
In status menu, one can change its presence state and also an offline state when Blink is offline. This is done using pidf-manipulation XCAP application, if supported by the XCAP server
* application.
h3. Media Capabilities: Capabilities
Type of media supported by the end-point
* end-point.
h3. Device Information: Information
The following information is published: Hostname,
* Hostname
* Time offset, offset
* Idle status and
* GRUU contact address
h3. Payload Example
<pre>
Content-Type: application/pidf+xml
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:ag@test.sip2sip.info">
<tuple xmlns="urn:ietf:params:xml:ns:pidf" xmlns:agp-pidf="urn:ag-projects:xml:ns:pidf" xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" xmlns:caps="urn:ietf:params:xml:ns:pidf:caps" xmlns:agp-caps="urn:ag-projects:xml:ns:pidf:caps" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" id="SID-f4649f87-1aa3-44ec-ab49-d0464528d706">
<status>
<basic>open</basic>
<agp-pidf:extended>away</agp-pidf:extended>
</status>
<c:display-name>Adrian Georgescu</c:display-name>
<c:map>Netherlands/Haarlem</c:map>
<c:icon>https%3A//xcap.test.sipthor.net/xcap-root/org.openmobilealliance.pres-content/users/sip%3Aag%40test.sip2sip.info/oma_status-icon/index</c:icon>
<c:homepage>http%3A//georgescu.info</c:homepage>
<agp-pidf:device-info id="f4649f87-1aa3-44ec-ab49-d0464528d706">
<agp-pidf:description>imac3-2</agp-pidf:description>
<agp-pidf:user-agent>Blink Pro 2.0.0 (MacOSX)</agp-pidf:user-agent>
<agp-pidf:time-offset>120</agp-pidf:time-offset>
</agp-pidf:device-info>
<caps:servcaps>
<caps:audio>true</caps:audio>
<caps:message>true</caps:message>
<caps:text>true</caps:text>
<agp-caps:file-transfer>true</agp-caps:file-transfer>
<agp-caps:screen-sharing>true</agp-caps:screen-sharing>
</caps:servcaps>
<rpid:user-input idle-threshold="600">active</rpid:user-input>
<dm:deviceID>f4649f87-1aa3-44ec-ab49-d0464528d706</dm:deviceID>
<contact>sip%3Aag%40test.sip2sip.info</contact>
<note/>
<timestamp>2012-09-21T12:53:57.802353+02:00</timestamp>
</tuple>
<dm:person xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" id="PID-5c82e1b170c9aa1a670c4388052657f2">
<rpid:time-offset>120</rpid:time-offset>
<dm:timestamp>2012-09-21T12:53:57.802353+02:00</dm:timestamp>
</dm:person>
<dm:device xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" id="DID-f4649f87-1aa3-44ec-ab49-d0464528d706">
<dm:deviceID>f4649f87-1aa3-44ec-ab49-d0464528d706</dm:deviceID>
<dm:note>Blink Pro 2.0.0 (MacOSX) at imac3-2</dm:note>
<dm:timestamp>2012-09-21T12:53:57.802353+02:00</dm:timestamp>
</dm:device>
</presence>
</pre>
h2. Subscribe To Presence
Using SIP SUBSCRIBE for RLS, Bink subscribes to the SIP addresses stored in rls-services document uploaded on the XCAP server by contacts management actions in the GUI (add/update/delete contacts).
h3. Presence Notifications
Presence information received from the SIP URIs as RLMI notifications from the RLS server is used to update each contact in the contacts list with:
* Icon is fetched from the icon URL published by the user
* Status icon overlaid on botton right of user icon, indicating away, busy, extended-away or available
* Rectangular presence indicator on right side of the tile to provide a quick overview about availability
* Presence note is rendered on second line, multiple notes and pending authorizations are rotated every 10 seconds
* Icon is fetched from the icon URL published by the user
* User icon is retrieved and updated when necessary from URL advertised by user
Selecting Show Presence Information menu item from contextual contact menu show a panel with detailed information, not all information may have been rendered in the GUI.
h2. Sessions
* When subscribed to Presence, if information is received, the contextual menu of each contact is updated with the possibility of starting a session to a specific device if the remote server and device uses GRUU.
Presence This functionality is available starting with "Blink Pro":http://itunes.apple.com/us/app/blink-pro/id404360415?mt=12&ls=1 2.0.2 and "Blink Lite":https://itunes.apple.com/us/app/blink-pro/id431473881?mt=12&ls=1 2.0.2 for MacOSX and is scheduled for Blink-Qt for Windows and Linux future releases.
h2. Live Service
Presence is a complex issue and the mechanisms used internally by Blink may not necessarily work with your own SIP server. If you want to troubleshot when things do not work as expected, first use the built-in Blink accounts provided by http://SIP2SIP.info that is known to be working to work with Blink.
h2. Server Compatibility Cocoa 2.1.0.
Presence is a complex issue and the mechanisms used internally by Blink may not necessarily work under any SIP server environment. This document was written to provide a better understanding of these mechanisms. Presence require proper infrastructure that many SIP service providers simply lack today, so do not complain to us when Presence does not work with your SIP service provider.
OpenSIPS 1.9.0 and OpenXCAP 2.1.0 server software has been tested and is 100% compatible with Blink:
h2. Design Principles
Blink should work with any SIP and XCAP servers that supports all related SIP SIMPLE standards, but only a subset of them are being used. They are described below:
* Blink uses only TCP or TLS transports for signaling
* Blink presence payload is based on "RPID schema":http://tools.ietf.org/html/rfc4480 with its extensions for "media capabilities":http://tools.ietf.org/html/rfc5196 and "person information":http://tools.ietf.org/html/rfc4480
* Blink relies on a Presence Agent collocated with the SIP Registrar that supports PUBLISH method, RLS subscriptions method and XCAP storage
* Blink uses only TCP or TLS transports for signaling, Presence Agent must use TCP/TLS
* Presence Agent must support RLS subscriptions and "RLMI notifications":http://tools.ietf.org/html/rfc4662
* Presence Agent must support handling of presence rules using org.openmobilealliance.pres-rules XCAP document
* Presence Agent must support external references from rls-services to resource-lists XCAP documents
* Presence Agent must support external references from rls-services to org.openmobilealliance.pres-rules XCAP document
* Presence Agent must support presence and presence.winfo event packages
* Presence Agent may support xcap-diff event package for XCAP documents replication between clients
* Presence Agent must support RLS subscriptions and "RLMI notifications":http://tools.ietf.org/html/rfc4662
* SIP Registrar may support GRUU
* XCAP server must support rls-services, resource-lists, xcap-caps, org.openmobilealliance.pres-content, org.openmobilealliance.pres-rules, org.openmobilealliance.xcap-directory
* XCAP server may support serving the user icon from org.openmobilealliance.pres-content document
* XCAP server must support the following XCAP applications: rls-services, resource-lists, xcap-caps, org.openmobilealliance.pres-content, org.openmobilealliance.pres-rules, org.openmobilealliance.xcap-directory
* XCAP server may support pidf-manipulation for offline status
h3. Standards
Blink presence payload is based on "RPID schema":http://tools.ietf.org/html/rfc4480 with its extensions for "media capabilities":http://tools.ietf.org/html/rfc5196 and "person information":http://tools.ietf.org/html/rfc4480 http://sipsimpleclient.org/projects/sipsimpleclient/wiki/SipFeatures#Presence
In the GUI, presence has been indicated as 'Availability'.
h3. Standards Disclaimer
Blink presence functionality should interoperate without any issues with any other SIP client or SIP server implementing presence as far as the SIP signaling There is concerned (PUBLISH, SUBSCRIBE and NOTFY methods). no guaranty Blink Presence functionality would however not interoperate for contacts storage level with other SIP clients under the same account due to the freedom allowed by the standards in modeling the data used for contacts storage.
h3. Interoperability
Presence is a complex issue and the mechanisms used internally by Blink may not necessarily work under your own server environment. If you want to troubleshot when things do not work as expected, first use the built-in Blink accounts that are designed to work with SIP2SIP domain. As protocol traces for signaling and storage are logged to file, you can easily access such debug information and analyze Blink behavior.
We can provide support, if you encounter interoperability issues with any the following products and services against which Blink has been fully tested:
* SIP2SIP.info (a public free SIP service)
* Interoperability with XMPP domains (using SylkServer SIP/XMPP gateway)
* OpenSIPS/OpenXCAP combination (server software you can run on your premisses)
There is nothing that should prevent Blink interoperate with any other SIP end-points as far as SIP signaling is concerned (PUBLISH, SUBSCRIBE and NOTIFY methods). Blink will preserve contacts related information that it did not create itself in XCAP documents. Unfortunately, we have not found other clients that behave in the same way. Sharing the same XCAP documents with other SIP clients is therefore strongly discouraged. discouraged as is guaranteed to cause failures.
"List of implemented standards":http://sipsimpleclient.org/projects/sipsimpleclient/wiki/SipFeatures#Presence You can also enable one SIP2SIP account in your Blink instance to perform presence and contact storage operations while using your preferred SIP provider to make phone calls.
h3. Support
As presence require proper infrastructure that many SIP service providers simply lack today, do not complain to us when Presence does not work with your SIP service provider.
h2. Contacts Storage
Contacts are stored on the XCAP server in the [[XCAP-samples#Resource-lists|resource-lists]] resource-lists document under a proprietary name space to avoid conflicts with other end-points that might use the same document as there is no common standard way for how to store a rich address book on a server. This means that different SIP user agents from different vendors cannot read or modify this data in a deterministic way. The contacts in the address-book document are then used by [[XCAP-samples#RLS-services|rls-services]] standard OMA rls-services and [[XCAP-samples#Presence-rules|pres-rules]] pres-rules XCAP documents standardized by OMA. Each contacts documents. Contacts have two presence Presence related properties that can changed in Edit Contact Panel Subscriptions section:
* Subscribe to Contact's Availability Presence Information
* Allow Contact to see my Availability Presence Information
* If a SIP an URI part of the Contact contact is labelled as XMPP, when using a SIP2SIP.info account, new account the session requests request will be automatically forwarded to the an XMPP domain using the built-in SIP to XMPP gateway provided by SIP2SIP service. gateway.
h3. Subscribe To Presence
Using SIP SUBSCRIBE for RLS, Bink subscribes to the SIP addresses stored in rls-services document uploaded on the XCAP server by contacts management actions in the GUI (add/update/delete contacts).
h2. Policy Management Watcher Information
Policy is used to express user preference about whether somebody that subscribed to our presence information is entitled to receive such information or not.
Using SUBSCRIBE for presence.winfo event package, Blink keeps track of presence watchers subscribed to our presence. and their status.
* New watchers Contacts that have subscribed to our presence are rendered in the 'New Contact Requests' group that is rendered on top of the contacts list
* list. Right clicking on a new request entry, provides a contextual menu to block click or add dragging the contacts contact can be used to allow or deny the contacts list
* Dragging the request entry to an existing contact will merge the address of the request entry with the destination contact
* request. Blocked contacts are displayed in the Blocked group group.
* Active watchers are shown in system menu Blink Status -> Subscribers for People Watching My Availability Presence Activity menu
h2. Published Presence
Blink user can publish a status and a note. Sometimes, Blink itself can change the status automatically, in situations when we do not perform any computer activity for a longer period or we start a phone call.
Presence status can be changed manually from the main GUI window and Status menu. Last combination of Presence state and note are saved in the history build at the end of the menu.
Status and note are automatically synchronized between multiple Blink instances under the same account.
Using PUBLISH method for the presence event package, the following information is published in a [[XCAP-samples#PIDF|PIDF]] document by Blink:
*
h3. Basic Status: Status
Open or closed
* closed.
h3. Extended Status: Status
Blink uses a proprietary extension for indicating the extented status compatible with XMPP end-points
* Location: end-points.
h3. Location
Location is based on CIPID map extension. Location can be disabled per account in Presence section of account preferences. Location is available only for accounts provided by sip2sip.info account. The format is a string Country/City.
* Homepage:
h3. Homepage
A home page can be entered in Presence section of account preferences. Homepage is based on CIPID homepage extension
* Note: extension.
h3. Note
Presence note can be typed in the text area right to own icon in the main GUI window. Note is attached to the service
* Icon: service.
h3. Status
Presence status can be changed from the main GUI window and Status menu. Last combination of Presence state and note are saved in the history build at the end of the menu.
h3. Icon
User own icon is uploaded to XCAP server using OMA pres-content application, replicated among multiple Blink instances and location of icon icons storage URL on XCAP server is published in the PIDF
* PIDF.
h3. Offline Presence: Presence
In status menu, one can change its presence state and also an offline state when Blink is offline. This is done using pidf-manipulation XCAP application, if supported by the XCAP server
* application.
h3. Media Capabilities: Capabilities
Type of media supported by the end-point
* end-point.
h3. Device Information: Information
The following information is published: Hostname,
* Hostname
* Time offset, offset
* Idle status and
* GRUU contact address
h3. Payload Example
<pre>
Content-Type: application/pidf+xml
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:ag@test.sip2sip.info">
<tuple xmlns="urn:ietf:params:xml:ns:pidf" xmlns:agp-pidf="urn:ag-projects:xml:ns:pidf" xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" xmlns:caps="urn:ietf:params:xml:ns:pidf:caps" xmlns:agp-caps="urn:ag-projects:xml:ns:pidf:caps" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" id="SID-f4649f87-1aa3-44ec-ab49-d0464528d706">
<status>
<basic>open</basic>
<agp-pidf:extended>away</agp-pidf:extended>
</status>
<c:display-name>Adrian Georgescu</c:display-name>
<c:map>Netherlands/Haarlem</c:map>
<c:icon>https%3A//xcap.test.sipthor.net/xcap-root/org.openmobilealliance.pres-content/users/sip%3Aag%40test.sip2sip.info/oma_status-icon/index</c:icon>
<c:homepage>http%3A//georgescu.info</c:homepage>
<agp-pidf:device-info id="f4649f87-1aa3-44ec-ab49-d0464528d706">
<agp-pidf:description>imac3-2</agp-pidf:description>
<agp-pidf:user-agent>Blink Pro 2.0.0 (MacOSX)</agp-pidf:user-agent>
<agp-pidf:time-offset>120</agp-pidf:time-offset>
</agp-pidf:device-info>
<caps:servcaps>
<caps:audio>true</caps:audio>
<caps:message>true</caps:message>
<caps:text>true</caps:text>
<agp-caps:file-transfer>true</agp-caps:file-transfer>
<agp-caps:screen-sharing>true</agp-caps:screen-sharing>
</caps:servcaps>
<rpid:user-input idle-threshold="600">active</rpid:user-input>
<dm:deviceID>f4649f87-1aa3-44ec-ab49-d0464528d706</dm:deviceID>
<contact>sip%3Aag%40test.sip2sip.info</contact>
<note/>
<timestamp>2012-09-21T12:53:57.802353+02:00</timestamp>
</tuple>
<dm:person xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" id="PID-5c82e1b170c9aa1a670c4388052657f2">
<rpid:time-offset>120</rpid:time-offset>
<dm:timestamp>2012-09-21T12:53:57.802353+02:00</dm:timestamp>
</dm:person>
<dm:device xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" id="DID-f4649f87-1aa3-44ec-ab49-d0464528d706">
<dm:deviceID>f4649f87-1aa3-44ec-ab49-d0464528d706</dm:deviceID>
<dm:note>Blink Pro 2.0.0 (MacOSX) at imac3-2</dm:note>
<dm:timestamp>2012-09-21T12:53:57.802353+02:00</dm:timestamp>
</dm:device>
</presence>
</pre>
h2. Subscribe To Presence
Using SIP SUBSCRIBE for RLS, Bink subscribes to the SIP addresses stored in rls-services document uploaded on the XCAP server by contacts management actions in the GUI (add/update/delete contacts).
h3. Presence Notifications
Presence information received from the SIP URIs as RLMI notifications from the RLS server is used to update each contact in the contacts list with:
* Icon is fetched from the icon URL published by the user
* Status icon overlaid on botton right of user icon, indicating away, busy, extended-away or available
* Rectangular presence indicator on right side of the tile to provide a quick overview about availability
* Presence note is rendered on second line, multiple notes and pending authorizations are rotated every 10 seconds
* Icon is fetched from the icon URL published by the user
* User icon is retrieved and updated when necessary from URL advertised by user
Selecting Show Presence Information menu item from contextual contact menu show a panel with detailed information, not all information may have been rendered in the GUI.
h2. Sessions
* When subscribed to Presence, if information is received, the contextual menu of each contact is updated with the possibility of starting a session to a specific device if the remote server and device uses GRUU.