Hi list,
I'm sorry to ask this to the list, as I'm sure I've seen the information before but after some googling I can't really find it. Can anyone shed some light on the status of the presence module at the moment? How far developed is it? Which methods does it now support? Can people subscribe with their regular ser username? I know there's been some work on it recently, and any info would be gratefully received.
Many thanks :-)
Dave
------------------------------------- Dave Bath dave@fuuz.com www.fuuz.com 07736 232085
NOTE: The information contained in this email is intended for the named recipients only, it may be privileged and confidential. If you are not the intended recipient, you must not copy distribute or take any action in reliance upon it. No warranties or assurances are made in relation to the safety and content of this email and any attachments. No liability is accepted for any consequences arising from it
Dave Bath wrote:
Hi list,
I’m sorry to ask this to the list, as I’m sure I’ve seen the information before but after some googling I can’t really find it. Can anyone shed some light on the status of the presence module at the moment? How far developed is it? Which methods does it now support? Can people subscribe with their regular ser username? I know there’s been some work on it recently, and any info would be gratefully received.
The PA module is still a work in progress, partly because the specs I've been implementing against are internet-drafts that are updated at least every 6 months, though "A Presence Event Package for the Session Initiation Protocol (SIP)" has been published as RFC3865.
PA handles subscribes on behalf of users registered against ser and generates notifies when their presence information changes. One source of presence information is usrloc/registrar but PA also handles PUBLISH messages from UAs. PA is able to composite event state from multiple user agents. For presence information, PA generates NOTIFY messages with lpidf, xpidf, or the preferred pidf format. For authentication of subscribers, PA generates watcherinfo notifications so that the UA can use XCAP to fetch and update watcher authentication documents. I have written a rudimentary XCAP server in python that I believe is available from pals.internet2.edu.
In addition to PIDF, it supports extended status, prescaps, and geographic or civil location.
PA does not subscribe to presence information -- it only uses the local registrar and incoming PUBLISH messages as a source of presence state.
We've been using it in the Internet2 Presence Integrated Communication working group since last January. It mostly works but is not as stable as it should be. Jan Janak found and fixed a race condition but that code has not been tested extensively and is not yet in CVS.
Jamey
Hi,
I read your status report on PA with great interest, as I'm trying to debug presence problems with Windows Messenger 5. All my test users have WM 5 and directly logon onto ser, i.e. no jabber gateway or other clients.
If I start off with two users, and each login, they can see each other. If one logs off, the second notices. If the first logs back on again, it *does not* notice (often it does notice later). I've also had situations where a user has logged off, but not all WM clients have noticed.
I have searched through all available Ser online docs, and googled "serusers" (there is no searchable archive online I think?).. and finding detailed info on WMs behaviour is not easy. It works most of the time, I have the feeling its almost there..
I've tried following NOTIFY/SUBSCRIBE and they would seem to come when expected...
Could you tell me what the status is regarding pure WM5 presence? Am I banging my head on a wall here or is there hope/workarounds? :-)
Thanks in advance,
Sean Boran
Sean Boran wrote:
Hi,
I read your status report on PA with great interest, as I'm trying to debug presence problems with Windows Messenger 5. All my test users have WM 5 and directly logon onto ser, i.e. no jabber gateway or other clients.
If I start off with two users, and each login, they can see each other. If one logs off, the second notices. If the first logs back on again, it *does not* notice (often it does notice later). I've also had situations where a user has logged off, but not all WM clients have noticed.
It sounds like PA is neglecting to send a NOTIFY when the first re-registers but is probably sending the NOTIFY when the second re-subscribes. There are quite a few places in the usrloc code where it invokes the PA callback to indicate a change in state. My guess is that one of them is missing or incorrect. Are you using recent code from CVS?
Jamey
I've using stable from CVS, dated sep 6th.
Sean
It sounds like PA is neglecting to send a NOTIFY when the first re-registers but is probably sending the NOTIFY when the second re-subscribes. There are quite a few places in the usrloc code where it invokes the PA callback to indicate a change in state. My guess is that one of them is missing or incorrect. Are you using recent code from CVS?
Jamey
jamey,
thanks for working on the pa module.
PA handles subscribes on behalf of users registered against ser and generates notifies when their presence information changes.
i have a general question on this one. how does the pa module know if the user is willing to let someone to subscribe to its presence information? is there now some standard way for the presence server to ask about it from the user or how it is done?
-- juha
Juha Heinanen wrote:
jamey,
thanks for working on the pa module.
PA handles subscribes on behalf of users registered against ser and generates notifies when their presence information changes.
i have a general question on this one. how does the pa module know if the user is willing to let someone to subscribe to its presence information? is there now some standard way for the presence server to ask about it from the user or how it is done?
When I first wrote the code, it would allow subscription from anyone. Later I added a parameter to control whether it does that or uses watcherinfo to manage subscriptions. In this mode, a new watcher is initially unauthorized and PA adds a new entry to the watcherinfo table in the database. PA then sends a watcherinfo event NOTIFY to whoever is subscribed to that event package and adds an entry to the watcherinfo table in the database.
A UA subscribes to its the user's watcherinfo. When it receives a watcherinfo NOTIFY, it uses XCAP (HTTP GET) to fetch the user's watcherinfo from the XCAP server, which is reading from ser's database. The UA asks user whether to authenticate new users and then PUTs back an updated watcherinfo document to the XCAP server. The XCAP server writes to the database and notifies PA via a ser FIFO command. At that point, if a watcher has been authorized and has an active subscription, PA should send a NOTIFY.
I hope that is a useful overview of how it is supposed to work. There are few UA's that support XCAP -- sipc from Columbia is one of them but it's not generally available.
Jamey
-
Dave Bath -
Jamey Hicks -
Juha Heinanen -
Sean Boran