Presence
Version 15 (Adrian Georgescu, 09/18/2012 03:20 pm) → Version 16/63 (Adrian Georgescu, 09/18/2012 03:23 pm)
h1. Presence
h2. Design Principles
Blink should work with any server that supports the same standards as Blink. There is nothing proprietary that would stop interoperability between two Blink clients using any properly configured SIP and XCAP server. There is however no guaranty that this would work with other clients.
h3. Interoperability
Presence is a complex issue and the mechanism used internally by Blink may not necessarily work under your own environment. If you want to troubleshot when things do not work, first use the built-in Blink accounts that are designed to work with SIP2SIP domain. As full traces are available in the client you can easily access debug information.
We can provide support if you encounter interoperability issues with the following products and services:
* SIP2SIP.info accounts
* Interoperability with any XMPP domain supported by SIP2SIP.info
* OpenSIPS + OpenXCAP combinations
h3. Support
As presence require proper infrastructure that many SIP service providers simply lack today, do not complain to use when Presence does not work. Use a SIP2SIP account instead or use OpenSIPS+ OpenXCAP server combination thatr has been used to develop all Blink features.
Contacts are stored on the XCAP server in the 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 are then used by standard OMA rls-services and pres-rules XCAP documents. The SIP and XCAP servers need to support OMA style XCAP documents in order to interoperate with Blink.
h2. Contacts
Contacts have two Presence related properties that can changed in Edit Contact Panel Subscriptions section:
* Subscribe to Contact's Presence Information
* Allow Contact to see my Presence Information
h2. Watcher Information
Using SUBSCRIBE for presence.winfo event package, Blink keeps track of presence watchers and their status.
* Contacts that have subscribed to our presence are rendered in the 'New Contact Requests' group that is rendered on top of the contacts list. Right click or dragging the contact can be used to allow or deny the request. Blocked contacts are displayed in the Blocked group.
* Active watchers are shown in Status -> People Watching My Presence Activity menu
h2. Published Presence
Using PUBLISH method for presence event package, the following information is published by Blink:
h3. Basic Status
Open or closed.
h3. Extended Status
Blink uses a proprietary extension for indicating the extented status compatible with XMPP end-points.
h3. Location
Location is based on CIPID map extension. Location can be disabled per account in Presence section of account preferences.
h3. Homepage
A home page can be entered in Presence section of account preferences. Homepage is based on CIPID homepage 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.
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 icon is uploaded to XCAP server using OMA pres-content application, replicated among multiple Blink instances and location of icons storage URL on XCAP server is published in PIDF.
h3. Offline 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.
h3. Media Capabilities
Type of media supported by the end-point.
h3. Device Information
The following information is published:
* Hostname
* Time offset
* Idle status
* GRUU contact address
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:
* 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
* 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. This requires the remote device to use GRUU.
h2. Design Principles
Blink should work with any server that supports the same standards as Blink. There is nothing proprietary that would stop interoperability between two Blink clients using any properly configured SIP and XCAP server. There is however no guaranty that this would work with other clients.
h3. Interoperability
Presence is a complex issue and the mechanism used internally by Blink may not necessarily work under your own environment. If you want to troubleshot when things do not work, first use the built-in Blink accounts that are designed to work with SIP2SIP domain. As full traces are available in the client you can easily access debug information.
We can provide support if you encounter interoperability issues with the following products and services:
* SIP2SIP.info accounts
* Interoperability with any XMPP domain supported by SIP2SIP.info
* OpenSIPS + OpenXCAP combinations
h3. Support
As presence require proper infrastructure that many SIP service providers simply lack today, do not complain to use when Presence does not work. Use a SIP2SIP account instead or use OpenSIPS+ OpenXCAP server combination thatr has been used to develop all Blink features.
Contacts are stored on the XCAP server in the 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 are then used by standard OMA rls-services and pres-rules XCAP documents. The SIP and XCAP servers need to support OMA style XCAP documents in order to interoperate with Blink.
h2. Contacts
Contacts have two Presence related properties that can changed in Edit Contact Panel Subscriptions section:
* Subscribe to Contact's Presence Information
* Allow Contact to see my Presence Information
h2. Watcher Information
Using SUBSCRIBE for presence.winfo event package, Blink keeps track of presence watchers and their status.
* Contacts that have subscribed to our presence are rendered in the 'New Contact Requests' group that is rendered on top of the contacts list. Right click or dragging the contact can be used to allow or deny the request. Blocked contacts are displayed in the Blocked group.
* Active watchers are shown in Status -> People Watching My Presence Activity menu
h2. Published Presence
Using PUBLISH method for presence event package, the following information is published by Blink:
h3. Basic Status
Open or closed.
h3. Extended Status
Blink uses a proprietary extension for indicating the extented status compatible with XMPP end-points.
h3. Location
Location is based on CIPID map extension. Location can be disabled per account in Presence section of account preferences.
h3. Homepage
A home page can be entered in Presence section of account preferences. Homepage is based on CIPID homepage 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.
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 icon is uploaded to XCAP server using OMA pres-content application, replicated among multiple Blink instances and location of icons storage URL on XCAP server is published in PIDF.
h3. Offline 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.
h3. Media Capabilities
Type of media supported by the end-point.
h3. Device Information
The following information is published:
* Hostname
* Time offset
* Idle status
* GRUU contact address
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:
* 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
* 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. This requires the remote device to use GRUU.