14 Sep
2004
14 Sep
'04
10:08 a.m.
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(a)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
15 Sep
15 Sep
8:37 a.m.
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
9:46 a.m.
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
9:38 a.m.
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
9:59 a.m.
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
9:50 a.m.
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
10:56 a.m.
Juha Heinanen wrote:
jamey,
thanks for working on the pa module.
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
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?
7231
days inactive
7232
days old
6 comments
4 participants
participants (4)
-
Dave Bath -
Jamey Hicks -
Juha Heinanen -
Sean Boran